Logseq uses Markdown syntax but not every Markdown file is a valid Logseq page, basically because of dashes: Logseq expects them to define blocks. This means Markdown files need to be converted to Logseq’s format and vice versa.
My question is: were dashes really needed? Couldn’t block be defined by new lines only? I mean “at least one empty new line” as a block delimiter:
This is the first block. Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation
ullamco laboris nisi ut aliquip ex ea commodo consequat.
This is the second block. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu
fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim
id est laborum.
This is a child block indented with a tab. Sed ut
perspiciatis unde omnis iste natus error sit voluptatem
accusantium doloremque laudantium, totam rem aperiam,
eaque ipsa quae ab illo inventore veritatis et quasi
architecto beatae vitae dicta sunt explicabo.
In my opinion if possible this would had been much better. So out of curiosity, is there a technical problem with this syntax?
At least as far as Markdown is concerned, indentation. Markdown itself is a spec for doing simple layout and formatting for linear to-be-published prose. It is natively hostile to indenting things (four spaces at the start of a block turn into a code block, any normal standalone line breaks get ignored unless you tell Markdown that yes, you really did want that line break you wrote into the file). The only things indentation is ok in Markdown are bulleted and numbered lists.
Something like .org or OPML would be a far more native format for Logseq’s content, but if we want to save it as Markdown, some kind of hack is necessary - either making the whole page a bulleted list (which means conversions between prose!Markdown and outlineHack!Markdown) or doing an Org-mode and using headers as the indentation structure.
First of all, Tabs and 4 spaces are different things and what I want doesn’t involve 4 spaces.
Let’s make it more clear:
Empty new line to define blocks doesn’t conflict with common Markdown
Tabs to indent blocks doesn’t conflict with common Markdown (at least it seems so to me)
I’m not looking for the concept of indentation in Markdown, that as you said exist for lists only
I was looking for a way to indicate the indentation of blocks that doesn’t conflict with common Markdown
At the moment Logseq syntax conflicts with common Markdown because dashes ( - ) are already used for lists in Markdown
I was curious why Logseq developers would break compatibility and introduce so much issues to us (at least for me…); I guess it’s a matter of parsing or avoiding ambiguities but I don’t see how.
If I understand it correctly you mean Logseq is concerned to produce valid Markdown files and translated its blocks indentation into lists indentation in Markdown.
But this means Logseq expects every file to have proper dashes for indentation and use only * for lists.
I get the reasoning for this choice but still it’s a big disadvantage to break Markdown → Logseq compatibility for the sake of translating a Logseq concept (block indentation) with a Markdown feature aimed at lists indentation.
To me, when to split into a new block depends on logic/preference instead of length, so I have lots of blocks that have more than one paragraph in it, with empty lines between paragraphs so they don’t look like daunting walls of text (I could probably define a space after paragraph in custom.css but I haven’t tried that yet and it makes the plain text file harder to read) This way of writing notes will be impossible if logseq treats every empty line as a cue for ‘new block’.
Yes, it seems to me the approach with the least disadvantages.
Paragraphs = blocks seems more natural than list elements = blocks.
If one is concerned that there couldn’t be two paragraphs in the same block, the obvious solution would be to use tabs in the new line. But I’m not sure if Markdown parsers consider a new line with only tabs as empty or not.
If this is problematic blocks could be defined by two empty lines.
Edit: this is what I mean and seems natural to me, the red arrows indicates where tabs are
I checked some Markdown parsers like Pandoc’s and they consider tabs as indicators for monospace/code text.
So basically the most natural extension to Markdown to support blocks and their indentation is broken by Markdown itself because of this weird syntax to define code blocks that is even redundant because there are `` for that.
