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 This would make it easier for people to move between Logseq and other apps more smoothly in their workflows. Not just Obisidian, but pretty much any app that can handle ordinary markdown. This would allow much more compatibility between Logseq files and markdown files used by other apps. 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. Logseq could search them and query the front matter, but would otherwise not have many logseq like features within the page. One would be simpler: just leave these pages alone. This would basically make the page behave like an Obsidian page rather than a Logseq page. 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. Let’s talk about each of these features one-by-one: 1 Plain text files Output to standard formats such as PDF or ODT/DOCX.Document management that allows one to break up larger writing projects into smaller chunks (“sheets”) and to manipulate those chucks (split, merge, etc.).In-text citations, as well as footnotes/endnotes.Handle plain text files without any bullet points.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?Īs I see it, there are basically four features that logseq would need to add to be optimized for longform writing: ![]() 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. 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.Ĭurrently 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. Some of that is already built in, others (such as a Readwise plugin) are coming soon. 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. Rather, it is intended to start a discussion about what the best way might be for Logseq to achieve these overarching goals. Some of the ideas here might be spun off as feature requests on their own, but that isn’t the point. As such, it isn’t a standard feature request. This post is an attempt to sketch out what might be needed to change that. However, Logseq is not currently optimized for longform writing. 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. ![]() Logseq is great for ingesting organizing and processing notes.
0 Comments
Leave a Reply. |