Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add org-mode renderer #8

Open
josephmturner opened this issue Sep 20, 2023 · 6 comments
Open

Add org-mode renderer #8

josephmturner opened this issue Sep 20, 2023 · 6 comments

Comments

@josephmturner
Copy link

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

@josephmturner
Copy link
Author

josephmturner commented Jan 21, 2024

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
Copy link
Member

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

telamon added a commit to telamon/extension-agregore-renderer that referenced this issue Jul 2, 2024
telamon added a commit to telamon/extension-agregore-renderer that referenced this issue Jul 26, 2024
Implemented Orgmode Rendering

Cleaned up for patch
@josephmturner
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants