Longform writing in Logseq

[gestaltist]

@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.

[Dor]

@Leslie_P

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.

@gestaltist

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

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.

[Dor]

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

[ouwouhou]

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.

[Aryan]

Created a quick video on my long form writing setup in Logseq.

[menelic]

Thanks @Aryan for a great and helpful video, together with your pdf plugin this addresses many of the key functionality @Luhmann mentions in his comprehensive first post. You have covered and implemented two of four:

@Luhmann

• [x] 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.).

• [x partly done through your pdf plugin] Output to standard formats such as PDF or ODT/DOCX.

I think outlining where text sections (eg everything under a specific H1, H2 heading or any block can be moved around and reordered in an interactive TOC is a key functionality esp for actual long-form writing, any hints - or plugins - would be appreciated:

@Luhmann

Document management that allows one to break up larger writing projects into smaller chunks (“sheets”) and to manipulate those chucks (split, merge, etc.)

This would also be key for long form writing:

@Luhmann

In-text citations, as well as footnotes/endnotes

If in addition citation management could be tackled through an implementation of citeproc-js in Logseq

Link to external pdfs in local Zotero folder and Better BibTex support - #4 by menelic

this would truly put Logseq over the top in terms of writing tools, as it would combine key writing functionality with knowledge and task management.

Overall, reducing the number pf plugins needed to achieve long form writing would also be very helpful, as it would make for a more stable experience with longer term feature stability

[BetterVessel]

@Luhmann

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]

What are your thoughts on Gingko Writer for longform writing?

[alex0]

I think implementing longform writing should be taken as an opportunity to make Logseq able to read generic Markdown files, not only the ones made by lists with dashes:

- Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet.

    - Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet.

- Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. 

Logseq should be able to read/write Markdown files containing both normal paragraphs and lists (blocks):

Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet.

 - Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet.

Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. 

The user should be able to insert new content as block (list element in Markdown) or not (normal paragraphs in Markdown) and be able to turn one type into the other.

Normal paragraphs would have all Logseq features minus the block ones i.e. they couldn’t be indented, block-referenced somewhere else etc.

[fivestones]

Normal paragraphs should have the ability to be block-referenced somewhere else too. Why not? This would make them more useful and it shouldn’t be hard to do. If it’s one paragraph, it’s one block. Right?

[alex0]

But then one could be confused by “why paragraphs in blocks can’t be referenced independently?”

[TonyMarone]

Longform would be an option on each page the idea is for it to be triggered by the author using a string to toggle it on and off.
Consequently it would be an opt-in function, so that users would already know why paragraphs in blocks can’t be referenced independently.

e.g.:

• Proin mollis erat eget cursus consequat. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. In ornare faucibus ipsum, rutrum ultricies tortor sodales in. Nam quis elit orci.

• Etiam erat ante, feugiat quis scelerisque nec, fringilla sed purus. Vestibulum id quam orci. Mauris quis vestibulum augue. Sed id diam non ante accumsan commodo sed non tellus.

::longform:on

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi maximus lorem nec nunc laoreet sagittis. Maecenas eu neque laoreet, aliquam arcu non, rhoncus lacus. Mauris eu venenatis ex, ut cursus lorem.

Proin mollis erat eget cursus consequat. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. In ornare faucibus ipsum, rutrum ultricies tortor sodales in. Nam quis elit orci.

Etiam erat ante, feugiat quis scelerisque nec, fringilla sed purus. Vestibulum id quam orci. Mauris quis vestibulum augue. Sed id diam non ante accumsan commodo sed non tellus.

Donec tempor venenatis dapibus. Donec quam odio, luctus sit amet pulvinar quis, posuere quis mi. Nunc ac blandit dui. In condimentum eros augue, vitae luctus odio vulputate vel.

::longform:off

• Etiam erat ante, feugiat quis scelerisque nec, fringilla sed purus. Vestibulum id quam orci. Mauris quis vestibulum augue. Sed id diam non ante accumsan commodo sed non tellus.

• Donec tempor venenatis dapibus. Donec quam odio, luctus sit amet pulvinar quis, posuere quis mi. Nunc ac blandit dui. In condimentum eros augue, vitae luctus odio vulputate vel.

[fivestones]

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.

[alex0]

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

[huy]

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

[Luhmann]

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.

[alex0]

@Luhmann

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.

[Luhmann]

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.

[alex0]

@Luhmann

But as neither of us are programmers

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.

[fivestones]

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?

[Luhmann]

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.