Logseq is fundamentally an outliner, but going from outlines to long form writing isn’t such a big stretch. My goal with Logseq is to have all my external knowledge in one place, so having to transition to another tool for the best long form experience creates friction.
Logseq already has a visual document mode, which you toggle with td. This toggle only hides the bullets — they still appear when you copy the content (my biggest issue) and when you open the document in another editor.
When I’m writing a long form document, there’s no reason for the bullets to remain there at all. I propose that Logseq add a page type property: the default “outline” type and also a “document” type.
The “document” type would have no bullets. It would be a page in the graph database, but it would have no block IDs associated with it (since the page itself is the only block). Honestly, I think this solution is pretty simple, and it would greatly streamline my workflow.
Maybe paragraphs could be considered in the graph/database just as blocks with no children and to switch between block and paragraph just let us delete the bullet point with Delete keyboard button at the beginning of a first-level block and press - to going back to block, just like in text editors.
Yes to all of this. I would love to see logseq use a standard markdown parser/model where headings create hierarchy, paragraphs are blocks, lists (bullet and numbered) are also blocks (of type “list”), etc. Of course such a standard model would have to be enhanced with logseq’s extensions, like property blocks.
I generally like this idea, but I think the bullets/blocks are too fundamental to Logseq’s purpose (outliner) to just allow for deleting them. Instead, it would be better if bullet-deletion was disabled by default and toggle-able per page.
so:
For Pages made in Logseq
bullet structure (current behavior) by default
shortcut/toggle (like td for document mode right now) allows for deleting the bullets
with that mode toggled on, you can create the below structure:
- block 1
- child of block 1
block 2
still block 2
still block 2
- block 3
if you delete the bullet of block 1:
block 1
- block 2
block 3
still block 3
still block 3
- block 4
If the user toggles outline mode back on after already deleting some bullets, all the bullets reappear:
either (every line break in a paragraph becomes a parent block)
To me it still seems like that behavior is too complex. Expanding the document mode will inevitably add complexity to Logseq, so the goal should be to make it as simple as possible.
In the current, visual-only document mode enabled with td, each empty line represents a block break, but the bullets are still there in the actual file. With the bullets completely gone in a true document mode, I think it makes more sense to put all content without a bullet in a single block, unless it’s interrupted by a bullet.
Also, in your first two examples, does the child block have 2 indentations even though it’s parent block (the paragraph) has 0? That seems odd, but it also can’t have just 1 indentation, or else the 2nd parent block that still has its bullet would be indistinguishable.
There is a problem indeed and mine is not standard Markdown neither.
Maybe add a button or a command in Logseq UI to insert Markdown paragraphs and give up on features only blocks can have (like children blocks)?
Personally Logseq being compatible with normal Markdown paragraphs and still being able to use [[wikilinks]] inside them would be a huge improvement for me.
I propose that Logseq add a page type property: the default “outline” type and also a “document” type.
The “document” type would have no bullets. It would be a page in the graph database, but it would have no block IDs associated with it (since the page itself is the only block). Honestly, I think this solution is pretty simple, and it would greatly streamline my workflow.
I like the simplicity of this idea. I wonder how would the graph respond to “bulleted lists” on a “document” type page?
For example, if I toggle that page back to the default ‘outliner’ type they become child blocks and are given block ids along with all the paragraphs and embedded audio, images, etc. So what happens to the graph if the page is changed back to a ‘document’ type?
Also, I love the outliner nature of Logseq and I think document type files for long form would be awesome. If the page was a single block when it has the document type then it could be copied, published, or shared without the additional bullets AND the page could still be embedded (or referenced?) in outliner typed pages, couldn’t it?
I think that has the potential to be a great way to leverage the outliner features of logseq to plan markdown content that will be published or rendered elsewhere without needing to leave the logseq graph.
Yes, love this idea. I’d prefer just being able to right-click a node and being able to turn Outliner off. I’m running into this issue trying to move my work notes from Apple Notes to Logseq and they don’t work well with an outline mode in term of easily viewing them after the fact.
The issue I see is if I’m using Logseq and then I need to turn a single node into a non-outline node, how would Logseq know when i was done?
It seems like to make this work fluidly, we would need to open nodes we want this option on to be opened into their own page. This would allow us to exit the page and have Logseq go back to default outliner mode.
I would like to second this, but from another point of view - I would like to have an option to enable document for some pages, so they always appear as documents, whereas others stay as outlines. For example, I have a one big “main” outline, kinda like in Workflowy, and then I have another page where I scribble a big document on some specific topic. I would like the main page to say as the outline and the other page to be a document every time I switch between them. Right now, as far as I can see, document mode is a single toggle for the whole UI, all pages.