Logseq is great for ingesting organizing and processing notes. It also seems that there are both plans to make Logseq core better for this as well as new plugins on the horizon (such as Readwise) that will further improve these strengths. However, Logseq is not currently optimized for longform writing. This post is an attempt to sketch out what might be needed to change that. As such, it isn’t a standard feature request. Some of the ideas here might be spun off as feature requests on their own, but that isn’t the point. Rather, it is intended to start a discussion about what the best way might be for Logseq to achieve these overarching goals.
To put it simply, it is currently easy to envision a workflow where one could easily take notes while reading on one’s Kindle, or a PDF, pull those notes into Logseq, organize them into project notes, use the extract plugin to refine those notes, and plan out a long form article or book based on that research. Some of that is already built in, others (such as a Readwise plugin) are coming soon. But then what? The next stage of an academic workflow would be to start drafting a paper or book chapter, adding citations and notes, and then exporting to a PDF or word processor such as Word, Open Office, etc.
Currently for these last few stages of the writing process one is best off moving out of Logseq to more specialized apps such as Zettlr, Ulysses, and Scrivener. So the first question is whether there is any reason for Logseq to move in this direction, or if it should just perhaps make it easier to move your work into one of these longform writing apps? Maybe, but to answer that question it is helpful to first understand what the alternative would look like. What would it take to make Logseq as good as these apps for longform writing? Only when we can answer that can we decide if that is a goal that the Logseq team should consider, or whether it might make more sense to meet such apps half way?
As I see it, there are basically four features that logseq would need to add to be optimized for longform writing:
- Handle plain text files without any bullet points
- In-text citations, as well as footnotes/endnotes
- Document management that allows one to break up larger writing projects into smaller chunks (“sheets”) and to manipulate those chucks (split, merge, etc.).
- Output to standard formats such as PDF or ODT/DOCX.
Let’s talk about each of these features one-by-one:
1 Plain text files
The way I see it working is that one would be able to add some front matter to a page that would tell Logseq to handle it as longform text rather than an outline. Something like: longform:: true. This would basically make the page behave like an Obsidian page rather than a Logseq page.
This could be implemented in two ways. One would be simpler: just leave these pages alone. Logseq could search them and query the front matter, but would otherwise not have many logseq like features within the page. The other would be more Obsidian-like, in that headers would be treated as blocks, and one could embed blocks from anywhere in Logseq within a page.
This would allow much more compatibility between Logseq files and markdown files used by other apps. Not just Obisidian, but pretty much any app that can handle ordinary markdown. This would make it easier for people to move between Logseq and other apps more smoothly in their workflows. (i.e. It wouldn’t be necessary to convert files before opening them up in any markdown text editor that has support for front matter.)
2 Notes and Citations
There is already Zotero support in Logseq, but to approach the smoothness with which Zettlr incorporates formatted citations into text would require some work. In Zettler you can add an in-text citation marker from Zotero and it automatically gets formatted in your preferred citations style. Such a feature would be nice to implement regardless of Logseq’s longform goals, because one could export the text with these “live” Zotero citation markers which could later be read by the Zotero plugin for Word or Libre Office, etc.
There is also already some support for markdown footnotes in logseq, and I think pandoc could possibly handle having those exported as endnotes instead… But if we are talking about documents that are divided up into individual “sheets” and then recombined on export, this might need some additional work.
3 Document Management
Currently Ulysses is my favorite app for this, and it is worth looking at how it handles grouping individual “sheets” into larger projects, dividing sheets up, and merging them, etc. Ulysses also does a great job with goals, such as minimum/maximum word counts, or estimated “reading aloud time” (which is useful for conference presentations).
Another feature one would like with such document management is the ability to save “versions” of each project and easily navigate back to earlier versions. Since this is project based, it is a bit different from the current git implementation in Logseq which is file based.
There is a decent plugin for some of these features in Obsidian called Longform, and it isn’t bad. It might give a sense of what something like this might look like in Logseq.
Finally, it would also be nice to be able to add Logseq style tasks anywhere in a document or document outline, such as TODO lookup the date that this happened or NOW write chapter 1, etc. so as to integrate writing goals into Logseq’s task management tools.
4 Output to standard formats
I might be over simplifying, but it seems to me that this might be fairly simple since Pandoc already provides open source libraries for doing much of this? In any case, this is a common feature request here , so probably something should be done along these lines no matter what.
I hope this discussion is helpful for thinking through the future of Logseq. With all of these pieces in place one could really move from reading and research, to taking notes, to writing, to publishing without leaving Logseq, but even if only some of them can be implemented it could help improve integration with existing longform writing apps that rely on plain text.
)