The thing is outliners are incredibly helpful tools, but in the end not all documents are written using purely bullet points.
Usual documents are written using a hierarchy of titles (Header 1, Header 2, Header 3…), then a “ground” level made of paragraphs and sentences, and then some “underground” levels made of bullet or number lists / sublists.
I think it would be wonderful to be able to select one of the blocks of a page and define it as ground level. Then, all higher level bullets would be considered by the software as headers, and all under levels would be considered by the software as bullet lists / sublists.
That would allow both for
A simplified Markdown export of each page
A great “Document view” where bullets would “fade” and each level be rendered according to its level in real time, just like the Typora markdown editing software for instance. That would be, IMHO, far superior from the Roam Research “Document view” that basically just removes the bullets.
I’ve tried to make mockups to explain better (sorry, Mockups made with Athens) :
This is a test page in, standard view, where a bullet could be defined as “ground level”
This is how that same page would look in “document mode”
As you see, there is some natural way of defining “higher than ground” bullets as H3, H2, H1. “ground” bullets as sentences, or paragraphs, and “lower than ground” bullets as lists and sub-lists.
With recent version of Logseq (currrent 0.2.5) you can mix # headings and - bullets within a Markdown file like the following example. It might do near enough to what you want. In this case “ground level” is the page, if I understand correctly what you meant. Raw markdown text below, Logseq screenshot further below.
# Heading 1
Unbulleted short text.
A long unbulleted paragraph part of the same heading. One more sentence in the paragraph. Second sentence in the paragraph. Third sentence in the paragraph.
This is a third paragraph in the same heading.
# Heading 2
More text in second heading.
* Bullets in second heading. Used `*` instead of `-`. Markdown allows either bullet. But Logseq made special use of `-` bullets.
* Indented bullets
* More indented bullets
* More bullets in second heading.
* All these bullets are part of second heading and its block. Note Loqseq markdown `*` bullets shows as hollow circles.
## Heading 2.1
Text in Heading 2.1 (second level heading). Each heading are treated as separate blocks by Logseq. But all blocks defined by headings are considered as top level block, regardless of heading level.
### Heading 2.1.1
Even this Heading 2.1.1 (third level heading) is considered as a top level block in Logseq.
This is another paragraph in Heading 2.1.1 with a markdown horizontal rule underneath it.
---
- You can mix `-` blocks with headings. This is top level block.
- This is second level block. Indented `-` block.
- This is third level block. The `-` block is intended twice
- Back to top level block. Note Logseq blocks have solid dots.
# Heading 3
Mixing in this Heading 3 (top level heading) with previous `-` blocks. Currently Logseq displays `#` heading blocks with solid bullets exactly the same as `-` blocks. But you can customize such appearance using Logseq `custom.css` or themes. So these headings can be displayed without bullets if you like.
Ending paragraph in the same Heading 3. ;-)
Using v0.2.5, it works on top level - blocks. Using /h1 command makes it # heading, and /h2 makes it ## heading.
If you use /h1 command on a second level (or lower) - blocks it won’t make it a heading block. It’ll make it a - # block that have the size formatting of the h1 heading. This - # markup is a markdown extension that works the same in stackoverflow or github (my goto test sites for “standard” markdown).
This is indeed expected behavior of Commonmark and (therefore) GFM (Checking those specs, you clearly see GFM is a superset of Commonmark, which I agree with you, represent the closest thing to ‘standard’ markdown)
This behavior obscures the raw text, and departs from markdown interpretation everywhere else. I re-read your explanation of how/why Logseq handles blocks the way it does. I appreciate it’s complicate thing Logseq is trying to do, and I realize I’m not putting forward any easy solutions
One way is to use a special bullet for # headings block. Perhaps something like ■ square bullet or similar. Logseq UI/UX does depend on the bullet for each block. I understand we could even do this ourselves using custom.css, just as we could make the bullets for # headings to be transparent.
[edit:] Seems I couldn’t (yet) find custom.css that could restyle # heading bullets to ■.
Just had a look in ‘dev tools’ ctrl + shift + i (which interestingly doesn’t appear in shortcuts, ‘customize shortcuts’ or here) and I couldn’t see any markup difference between the two
Indeed I couldn’t find <ul> or <li> anywhere on the page!
It works on a new-line/block, but doesn’t appear to revert a heading that’s already become hyphenated.
