Hey, I love Logseq! I also love exporting from Logseq, but think it could be better than it currently is. Here are my 2 proposals:
Unifying page and graph export
We currently have “export page” and “export graph”. These have their own partly overlapping functionalities.
While it is possible to
- export a single page into Text, HTML or OPML with a bunch of customization
- export all Pages as standard Markdown, OPML, EDN or Roam JSON*
- export all public pages to the web
It is not possible to
- export the current page as EDN
- export all public pages to text with customization
- export a selection of pages (“All pages tagged ‘blog’”)
Both for UX (fewer options with semantic overlap) and for functionality I think it makes sense to unify these to allow operations like exporting pages by a manual selection or a query.
Move export out into plugins
I have made a modification to Logseq that allows export to the transit format to simplify web publishing by separating code and content. It is tremendously useful for me, but probably not very useful for most others (as long as the idea isn’t fleshed-out, anyway), so there would be very good reasons to reject a pull request for it (it’s an internal format, after all).
I would much rather be able to distribute it as a plugin instead of as a fork.
I plan to toy more with exporting (custom formats, static HTML pages with back-links included) and of course the funkier the ideas, the less it is fit for integration into the Logseq core. There seem to be quite a few other ideas for export formats floating around and it would not make much sense to integrate them all.
Export plugins could ingest an arbitrary selection of pages.
Mockup
Here’s what it could look like. The selection for what to export is in the core application’s hands while everything after that is in the hands of export plugins.
Once invoked an export plugin can show an arbitrary view with all of its options and actions.
