Proper paste pages #23

Open
opened 2023-11-16 18:35:00 +01:00 by Jef Roosens · 2 comments

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
Kind/Feature
label 2023-11-16 18:35:00 +01:00

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.

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
Jef Roosens added the
Project/Lander
label 2024-08-26 10:42:18 +02:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Chewing_Bever/lander#23
There is no content yet.