Longform writing in Logseq

Feedback Feature Requests
,
25

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

10 Likes
26

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:

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 :wink: - would be appreciated:

This would also be key for long form writing:

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

2 Likes
27

What are your thoughts on Gingko Writer for longform writing?

1 Like
28

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.

17 Likes
29

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?

4 Likes
30

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

1 Like
31

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.

13 Likes
33

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.

2 Likes
34

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

3 Likes
35

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

36

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.

2 Likes
37

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.

2 Likes
38

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
39

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.

40

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?

1 Like
41

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.

3 Likes
42

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
6 Likes
43

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.
3 Likes
44

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.

1 Like
45

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.

1 Like