Longform writing in Logseq

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:

  1. Handle plain text files without any bullet points
  2. In-text citations, as well as footnotes/endnotes
  3. Document management that allows one to break up larger writing projects into smaller chunks (“sheets”) and to manipulate those chucks (split, merge, etc.).
  4. 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.

This is an outstanding writeup and captures most of the ideas I would have asked for. It is high level enough to allow for finer details to be added later. I think capturing many of the “multi-page” functions that Scrivener and Ulysses do would make Logseq much more of a complete tool.


If this was implemented, it’s likely that I could eliminate 1 or 2 of the other tools that I currently need to use. I love Zettlr and would love Obsidian (if it were open source) but Logseq going in this direction would make my whole note-taking/thinking/writing process more complete and simple.


This is a brilliant idea.

1 Like

Plus 1 for this. It would be great if Logseq could handle folding headers with text below the the way Obsidian does.


Another interesting thought is that this expands the modularity of logseq. so it can be used as an outliner, a task manager, a markdown editor and a longform writing tool (with the ability to breakdown writing projects into chunks like Scrivener/Ulysses)…

Exciting stuff!


I’m a heavy-duty Logseq user; I use it all day, every day as Product Manager at a fintech company in the UK. It’s used to capture my ideas, record notes from interviews and conversations, correlate concepts and topics, document research notes, prepare product roadmaps, perform competitor analyses, plan my day ahead etc. The back/cross linking functionality works exactly like my mind works. Logseq is the only app that’s done this for me, and I’ve tried many over the decades.

It’s literally the only app I have open all the time. Everything of importance is recorded in Logseq (if it’s not in Logseq it didn’t happen :slight_smile: )

I came across this thread because I subscribe to the Logseq Weekly RSS feed (thanks @Ed_Nico ) and it struck a chord with me.

I have all these notes, with all the rich context provided through linked references, embedded blocks etc. but I then have to dick about getting that info into something that can be easily summarised and circulated to colleagues for comment, review etc.

I’ve tried workarounds like working with quote blocks, but that breaks really easily.

If Logseq were to go for an MVP in this area, I’d suggest

  • the ability to create a page where you can set Outliner-Mode-Off, which means I could write paragraphs of text that aren’t prefixed or automatically indented
  • retain the ability to embed blocks so that I can, for example, write my paragraphs of long form text at the top of the page and include embedded blocks of related content further down the page which only serve as transient notes/reminders of what needs to be included in the non-outlined text I’m writing about.

If I had the above, I’d be able to:

  • Set up a new page to compose a document that summarises my thoughts and research on a specific topic
  • have access to all the notes that I need to write the long form text about
  • copy and paste the final output of the long form text to whatever corporate system/app I need to use to share the information
  • … without breaking the integrity and linkages of my source material

@Luhmann Thanks for posting your suggestion, and your rationale. It inspired me to write this.


Thank you for this very interesting discussion. I would also be very very very interested in this functionality. It seems to me that there should be an integration with Pandoc via YAML headers like Zettlr does for example. That would allow to export and to parameterize the exports finely.

For the composition, we could imagine a block selector based on keywords that would allow to extract all the necessary pieces for a long document.

1 Like

Exactly what I would have ask ! Thank for this post !
The reply of RXA is also perfect !
Really hope that it will come to this soon!


Meantime, I discovered the pluging doc viewer that can let you manage a page in a approx long form format.

This could be used until getting a pure long form.

You may find the advanced command <verse to be useful. Allows the enter key to create new lines in a block.

This doesn’t provide a solution to everything, but until you find some plugins that work for you or the functionality is added to the beta, hopefully this is helpful.


Just type < and it should bring up a menu similar to the slash menu.

Sorry, I deleted my reply when I found out how to do it (the light bulb lit right after I typed my reply). Thank you very much!

Like most of you, I am mentally in outline mode the VAST majority of the time, so logseq is ideal. But there are times when I want to add a non-outline type of note to an item, but not for it to be an attachment of something “non-logseq”.

Workflowy seems to handle this intuitively, and I think logseq could use the concept as a starting point.

In Workflowy, shift-enter creates a note under the current bullet, that’s ENTIRELY intuitive.

  • ENTER for a new bullet item
  • SHIFT+ENTER for a new note under the bullet item

For the internal workings…that new note could be treated like a separate markdown document, no special outline treatment, just standard markdown so it could be a huge longform document, or just a little note that allows markdown styling.

Back many years ago, there was an app called The Outliner of Giants that did something similar. The note under a bullet item could even end up being an entire blog post, it was all handled quite beautifully via the interface, and made intuitive sense.


This already exists in logseq. You can enable it from config.edn

;; By default, pressingEnterin the document mode will create a new line. ;; Set this totrue so that it's the same behaviour as the usual outliner mode. :shortcut/doc-mode-enter-for-new-block? false

1 Like

I wasn’t clear, sorry. I was thinking more of an enhancement/alternative of that ability. To have shift+enter put us into “note mode” (if we want it to). Or maybe alt+enter would take us into “note mode”. Something different.

In logseq, it’s beautiful today that shift+enter is newline inside the same bullet item, and enter closes that item and takes us to the next one, that’s great and good for formatting that bullet item with intentional line length

In workflowy, shift+enter adds a note entity to the bullet item, which is a whole different thing entirely. It’s kind of confused me multiple times because it’s difficult to get out of that note item and back to the outline, but I appreciate the possibilities here as well. I would love for logseq to take the good/possible and leave out the bad/confusing.

Now that I’m thinking about it more:

  • I love the way logseq is now for the casual need to format the bullet item with intentional newline, shift+enter is perfect as is
  • I’d like to have “note mode” activated perhaps by alt+enter or some other key combo. “Note mode” would let us create non-outline typical markdown content that is contained within it’s parent. Kind of a code-fence with plain markdown content

@Leslie_P Notes are a feature of OPML so all classical outliners tend to support them. Logseq is not based on OPML but on text files and there’s no natural way of doing that. However, you could add notes as a special property if you want, something like note:: Whatever your note is.


Converting between OPML and markdown makes bullets equivalent to headers (with the h1-h6 hierarchy) and lines below the bullet into text. So there is a natural way of doing this, so long as you maintain awareness of the difference between paragraphs/bullets and lines.

My problem was with the shortcuts. I wanted to make the behaviour the same in document and outline mode, but changing shortcuts always gave the inverse action in the other mode. I found this very irritating because toggling document mode accurately switches bullets on in paragraphs, and not lines, but the keyboard behaviour was different. Now solved by editing config.edn as advised above.

Thank you for this. Solved my problem. Though I am a bit surprised that there wasn’t a more visible toggle.

1 Like

I don’t know if it’s worth a separate feature request, but without asking for a full freeform text mode, I also wish that headers at least behaved as everywhere else (i.e. as an outline). Right now, they are just a weird formatting option, as the indent level is the absolute outline level.
Headers could be useful as a loose structure that doesn’t waste screen space with indents.

1 Like