Open josephmturner opened 1 year 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
?
if browserify specifically doesn't work we could use whatever other bundler :)
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?
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.
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.
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.
I think https://orga.js.org/playground/ could work well.