Proper paste pages #23

New Issue

Jef Roosens · 2023-11-16T18:35:00+01:00

Jef Roosens commented

2023-11-16 18:35:00 +01:00

Pastes are currently just text files that get returned as plain text. I'd like to have a "proper" page for pastes, with syntax highlighting & the paste being rendered in some monospace font. For requests sent from a CLI, the plaintext version should still be returned.

For syntax highlighting, we could use highlight.js. The page should also look good/be functional with JavaScript disabled.

Pastes are currently just text files that get returned as plain text. I'd like to have a "proper" page for pastes, with syntax highlighting & the paste being rendered in some monospace font. For requests sent from a CLI, the plaintext version should still be returned. For syntax highlighting, we could use [`highlight.js`](https://highlightjs.org/). The page should also look good/be functional with JavaScript disabled.

Jef Roosens added the

feature

label 2023-11-16 18:35:00 +01:00

Jef Roosens commented

2023-12-14 10:00:06 +01:00

Poster

To keep the application self-contained, we'd need to serve at least the highlight.js file (and probably some css files later on) from the Lander server. For this, it might be good to add a /_/ route where these files are served other. This route could then serve any necessary static files for the server.

To keep the application self-contained, we'd need to serve at least the `highlight.js` file (and probably some css files later on) from the Lander server. For this, it might be good to add a `/_/` route where these files are served other. This route could then serve any necessary static files for the server.

Jef Roosens commented

2023-12-17 11:35:54 +01:00

Poster

While experimenting with the LTM I've encountered another annoying issue: < and > in pastes. If you add these into an HTML file (even inside <pre><code>), the browser will try to interpret these as tags, causing lines such as #include <stdio.h> to simply become #include. For pastes, this isn't acceptable imo as the whole point is to show a paste properly inside an HTML page.

Because pastes are suppposed be to relatively small text files, it might be acceptable to expand the LSM store to store multiple data objects. For pastes, we would then add an "html" data file that contains an HTML-escaped version of the paste, which gets served when requesting the HTML page. The default data file would then still be called [key].data, with other data files being called e.g. [key].html.data.

While experimenting with the LTM I've encountered another annoying issue: `<` and `>` in pastes. If you add these into an HTML file (even inside `<pre><code>`), the browser will try to interpret these as tags, causing lines such as `#include <stdio.h>` to simply become `#include`. For pastes, this isn't acceptable imo as the whole point is to show a paste properly inside an HTML page. Because pastes are suppposed be to relatively small text files, it might be acceptable to expand the LSM store to store multiple data objects. For pastes, we would then add an "html" data file that contains an HTML-escaped version of the paste, which gets served when requesting the HTML page. The default data file would then still be called `[key].data`, with other data files being called e.g. `[key].html.data`.

Jef Roosens added reference ltm

2023-12-17 14:50:01 +01:00

Sign in to join this conversation.