AgregoreWeb / extension-agregore-renderer

A generalized Markdown/Gemini/ETC content renderer for Agregore. Replaces the old Markdown/Gemini renderers
GNU Affero General Public License v3.0
1 stars 4 forks source link

Add org-mode renderer #8

Open josephmturner opened 1 year ago

josephmturner commented 1 year ago

I think https://orga.js.org/playground/ could work well.

josephmturner commented 9 months ago

Like Orga, uniorg is also compatible with unified, but is more reliable. Here is a playground.

As of https://github.com/rasendubi/uniorg/pull/29, uniorg is ESM-only.

@RangerMauve does that mean that it won't work with browserify in extension-agregore-renderer?

RangerMauve commented 9 months ago

if browserify specifically doesn't work we could use whatever other bundler :)

josephmturner commented 3 months ago

IIUC, the current blocker is that .org files aren't rendered, but are treated as normal files for download. This is because mime doesn't map the .org file extension to a MIME type starting with text/, like text/org or text/x-org.

mime-db does map .org => text/x-org, but mime ignores it. Since mime-db also maps .org => application/vnd.lotus-organizer (long discontinued, but still mapped by IANA), mime returns that instead.

@RangerMauve would it be acceptable to add the .org => text/org mapping in hypercore-fetch like we already do for gemtext files?

maxnikulin commented 3 months ago

Perhaps this issue is more appropriate than the emacs-orgmode thread Re: Adding text/org MIME type to jshttp/mime-db. Sun, 04 Aug 2024 20:19:53 -0700

In the case of HTTP, the source of document.contentType is often the Content-Type header, so I expect that other side should be fixed as well: definitely HTTP server configuration, p2p protocols might have something similar.

I have no idea where list of media types that may be rendered internally is configured in the case of electron. This extension handles application/json and some JSON-based formats. Likely application/xml and application/pdf are examples of types that may be handled by the engine as well. A bullet proof client-side approach would be to mark application/vnd.lotus-organizer as suitable for the engine internal viewer and handle it in this extension along with text/org and text/x-org.

Finally check that servers do not send the Content-Disposition header forcing download dialog.

josephmturner commented 3 months ago

Another possibility that @rangermauve brought up was to add another Agregore extension which intercepts response headers, including Content-Type, and modifies them before Electron determines whether to render the file or download it.

maxnikulin commented 3 months ago

Another extension with <all_urls> permissions sounds like an ugly kludge. I still have a hope that Electron allows to extend list of media types that are handled internally.

Should "open file" for Org mode documents work as well?

Side note: I hope it will be impossible to inject JavaScript code from an Org mode file that is executed with extension privileges and in worst case it will be executed (if not suppressed by Content Security Policy or some other technique) in the context of document origin.