Add org-mode renderer

[josephmturner]

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

[josephmturner]

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

As of rasendubi/uniorg#29, uniorg is ESM-only.

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

[RangerMauve]

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

[josephmturner]

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]

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]

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]

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.

[josephmturner]

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.

I'm not sure. I see electron builder.Interface.FileAssociation, but that's for associating a particular electron app with an extension.

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

I just tested opening a .org file in Agregore by entering file:///tmp/foo.org and both Chromium and Agregore display it as plain text. But a remote Org file like https://ushin.org/contact.org gets downloaded instead. (Firefox does not render even local Org files).

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.

I don't know. Perhaps @RangerMauve can chime in on this?

[maxnikulin]

I still have a hope that Electron allows to extend list of media types that are handled internally.

I'm not sure. I see electron builder.Interface.FileAssociation, but that's for associating a particular electron app with an extension.

At first glance it is to register media types at OS level, not within Electron applications. My expectation that it should be possible to define some hook that is similar to ChromeOS file_handlers. It should not be a unique feature. Perhaps there are e.g. Electron-based EPUB readers that handle zip container to render files inside it.

(Firefox does not render even local Org files).

It was an issue with old version of shared-mime-info. Chromium and Firefox ESR installed from Debian 12 bookworm repository render Org files as plain text. document.contentType is text/org in these tabs.