Longform writing in Logseq

This seems like a beautiful solution to me.

Maybe also there could be a toggle (keyboard shortcut) to make the entire current page longform, so you wouldn’t have to type “::longform:on” or the like in your page, when you know you want everything in that page to be longform.

Why do you guys think that some special syntax would be needed instead of just using Markdown like in my reply?

1 Like

Yes I don’t see the need for special syntax. Markdown can already handle both.

This is really a question for the developers. There is a lot of magic that goes on behind the scenes to convert markdown documents in our folders to what appears in the database and on the screen. If it wasn’t for that one could just work in Markdown directly and wouldn’t need an app like Logseq. So it really isn’t clear to me what the technical limitations are, but I’m sure if there really weren’t any we’d already have something like this.

I think this is a big assumption. I myself don’t see the need for this “long form writing” but being able to handle arbitrary Markdown file is very important to me.

Edit: also, I doubt that some special syntax like long-form-writing:: would make a difference against technical limitations.


I doubt that some special syntax like long-form-writing:: would make a difference against technical limitations.

Why? It would tell the software that this document should be processed differently. Logseq was designed primarily as an outliner, not like Obsidian which was designed primarily to handle arbitrary Markdown files. Having a flag to tell the processor to handle the documents differently makes sense to me. But as neither of us are programmers, I don’t see much point in continuing to debate the topic.

1 Like

Another big assumption here, I’m an Information Engineer, I may not know how Logseq works internally but it already handles a lot of complex stuff when it comes to syntax. It’s not really a line that makes a difference.

The reason I thought this made sense is because right now starting a line in a md file with - makes a bullet and thus a block in logseq. But when writing in logseq, we don’t type the dashes. We don’t want to have to stick a dash in front of every block of text, and fortunately because we are using logseq we don’t have to. But if, in order to differentiate long form from outline-formatted text, we had to type a - (or not type one, depending on what we wanted) that would be a pain.

So, you stick a marker in there with the special syntax (e.g., ::longform:on or whatever) to tell logseq that everything you type next shouldn’t have a - at the beginning of the paragraphs in the md files, and shouldn’t have a bullet in front of it when viewed in logseq.

As huy said, markdown can already handle both. The problem is that we aren’t using the markdown for bullet points when we use logseq–it’s doing that for us, behind the scenes, and does it all the time without letting us go without it.

I don’t think having a special syntax is that important, as long as there is some way to let logseq know that now I want outlining, or now I want long-form writing.

What do you guys think?

What I meant is that we really shouldn’t be debating how to implement this - the developers (of Logseq) will know best. The important thing is to discuss the workflow. I personally do want to be able to tell the app to handle certain pages as plaintext and let other pages continue to operate as they currently do. I don’t want a more Notion style app where there are different kinds of blocks on the same page, each operating in a different way. I personally do not like how this approach works in Notion, in Wordpress, or any other app that has tried to implement it.

I think we are mixing different things here:

  • the syntax used in the Markdown files
  • the UI/UX of Logseq

What’s important with the former is ambiguity i.e. is the syntax able to represent all the use cases we need? For me yes, no special syntax other than Markdown needed.

A totally different matter is how Logseq present this in its UI:

  • there could be a slash / command to switch the mode where the cursor is
  • it could be an option in the right-click-on-bullet menu to turn some blocks into a paragraphs
  • if you press Shift+Tab (default for outdenting) when the block is already level-one it could display a dialog with something like “Outdenting one more time will turn this block into a normal paragraph, you won’t be able to do X, do you want to continue? Yes/No”
  • if you are in a normal paragraph and start a list with - it could automatically turn it into a block and escape the “long-form writing mode”
  • and so on whatever makes sense for you in terms of UX

It’s fairly common in UIs to support hitting ENTER to outdent a list item (in fact logseq supports this part) and then, once you’re run out of indentation levels, the next ENTER simply removes the bullet (i.e., turns the list item into simple text).
Right now, hitting that ENTER key will make logseq leave an empty list item (i.e. akin to a line with a bullet and nothing else), which isn’t very useful anyway.

So a simple solution could be to convert the current block into a simple markdown text node when you next hit ENTER and you’re already all the way outdented. And then you’re in “long-form mode”. (This could even work if the block already has text and the cursor is at the very left of the text; but this might be counter-intuitive for people, so this would need to be tested.)

Once you’re in “long-form mode”, there would be a difference between this mode and how long form mode works in other Markdown apps: after typing a paragraph, if the user hits ENTER once more, then the block would go back to the default of a list item. What if the user wanted to keep adding long-form paragraphs? There are two possibilities then:

  1. That’s just fine and everyone can get used to just hitting ENTER twice if they want another text block. That’s not bad; we’re all used to hitting ENTER twice in word processors to separate paragraphs. And logseq remains an “outline-first markdown app”.
  2. A page property could be added to change the default block type to text, just for this page. But in that case you’d need a way to easily create a list item? Well, that’s easy enough: - is the common way to start a list item in markdown text.
1 Like

Do you mean Delete? Enter is the button for a new line.

Anyway I’d prefer that once switched to a mode, pressing Enter for a new line keeps you in that mode.

Same for Delete to switch from block to normal paragraph, it is counterintuitive for me and too easy to trigger accidentally. Shift+Tab would be better for me.

No I mean Enter. Try it in any number of UIs: Microsoft Word, Google Docs, Apple Notes, Obsidian, (even Logseq with the exception of the top-level indentation), what have you. This is standard: start an outline with -, go nested, then trying hitting Enter in succession.

Anyway I’d prefer that once switched to a mode, pressing Enter for a new line keeps you in that mode.

Well then, starting a line with a - would have to switch you to outline mode, just as with any number of standard UIs.

But yes, Shift+Tab should work as well. But no need for a prompt because again Enter, Shift-Tab and starting an outline with - are standard operations in many, many document and note-taking apps.

I mentioned the Yes/No dialog because switching between blocks and normal paragraphs could be a destructive action… I don’t know how Logseq assigns IDs to blocks, but what happen if you accidentally turn a block into a paragraph and the ID is lost? This is just an example to explain what I mean.

Ah yes, good point. But it doesn’t have to be destructive–the ID could be preserved.

In this case of IDs for arbitrary Markdown blocks, I’m only aware of Obsidian having coming up with a design for block references (Link to blocks - Obsidian Help) and it could be re-used to a certain extent, thus encouraging a de-facto standard. (Anyone aware of any other Markdown apps that have block references for arbitrary parts of Markdown?)

So perhaps, doing something similar and writing out the block ID at the end of a block as ^62d61185-6094-4c39-9196-ba630963d03e (which logseq would hide in the UI, just as it does with IDs for list items) would be close enough to Obsidian’s style for Obsidian to immediately support it on some aspects of its UI: rendering in light-gray superscript (“half-hidden”) and references to it would work out of the box.
Obsidian has a somewhat different model of [[page#^local-uid]] rather than ((global-uid)), so Obsidian references created today would work and look like [[A Page#^62d61185-6094-4c39-9196-ba630963d03e]] which is a bit less user friendly but would still work.

And because this solution is sufficiently close to Obsidian’s, it could encourage the Obsidian core devs to tweak their implementation to further support the concept of globally-unique IDs. For example, to make autocompletion more user-friendly, Obsidian could do a little bit of work to recognize these global UIDs and avoid making the user first complete on the page name.)

Since Logseq does support long form writing mode (Document mode), then I’m wondering if it’s just a matter of creating a plugin that effectively switches between the modes.
A single page can be have both long form writing (no bullet points or paragraphs/blocks preceded by a “-”) and paragraphs with Enter or CR at the end.
A plug-in would switch between the two…however is this any better than the Esc+td?
One thing that should be an option is that when LS is in Document mode, each paragraph has an indent. I’d prefer not to have indents.

Another item I noticed that is problematic with Document mode is how to do headings. In the bullet mode, you can use the hashes to indicate level of heading, but that doesn’t seem to work in Document mode. Other font formating does seem to work (highlight, italic, bold).

1 Like

I imagine a plugin can’t change the underlying Markdown format that is used. Take a look: in your filesystem, go to the pages/ directory of your Logseq graph, and open a markdown file with a text editor and see how Logseq writes markdown (and stores block IDs).
So this would have to be changed in core.


But why if you use Obsidian with LongForm , really is possible, writing in logseq and save in the same obsidian folder?