Allow non-outline (freeform) text

[sabre23t]

@cannibalox

# H2
## H2.2 xxx
### H2.2.1 yyy

Logseq v0.1.x treated these '#` headings as hierarchy with H2 parent of H2.2 parent of H2.2.1, displays them indented to show hierarchy, and when folding H2 all the childs blocks are folded too. @pihentagy example in reply to my question request the same.

The visual display indentations of these parent-child hierarchy is a side/display issue. The fundamentals of markdown Headings is that they are a hierarchy, more often displayed without overt indentations, but reflected by size of the headings instead. Such headings hierarchy are more clearly seen when automatic heading numbering are shown (like I used in the example, H2.1 is a child of H2).

However, current Logseq v0.2.x treats these # headings all as top level siblings.

I’m for what @pihentagy proposes.

[cannibalox]

I agree on the general idea but I choke on specific details, given your example :

# H1
# H2
## H2.1
## H2.2 xxx
- D1
	- D1.1
	- D1.2
		- D1.2.1
- D2
	- D2.1
### H2.2.1 yyy
		- D2.1.1 xxx  <-- why two tabs btw ?
# H3

1. I think this relationship is wrong :
   

### H2.2.1 yyy should NOT be a sibling of ## H2.2. xxx, it should be a child node of ## H2.2 xxx and a sibling of - D1 and - D2.

this is how it’s rendered in typora

and obsidian (note the folded H2.2 xxx showing that ### H2.2.a yyy is a child node)

2. I think the problem is easy to solve when a user is pasting raw text from an external editor into logseq, but when we input text in logseq, this rise a lot of ux questions :

• within Logseq, when I’m in a sub level (indented) and type ### , should this level automatically outdent or stay at the same level ?

• if it stays at the same level, then what happens if the current indentation level is lower than other sub bullets ? in this case:

  ```
  ## parent
      - 1
          - 2
              - ### new heading <-- typing headings at this level
  ```
  

  here it seems we want ### new hading to be a child of ## parent, but should it be a sibling of - 1 (weird as we explicitly type in sub level 3) ? or - 2 (again, weird as we are explicitly in a sublevel of - 2 ? or become a child of - 2 only when we explicitly type (dash) ### ??

• how should we differenciate between ### heading and - ### heading or (tab)- ### heading) since we do not explicitly type - in ls markdown, but only use indent/outdent ?

[sabre23t]

@cannibalox

### H2.2.1 yyy
		- D2.1.1 xxx  <-- why two tabs btw ?

Why two tabs? Because that defines a 3rd level “-” block in Logseq. Also I wanted to see what Logseq do with it after a # block, and what @pihentagy thought it should do. I’ve tested in Logseq v0.2.5 and found that it treats ### H2.2.1 as top-level, and make - D2.2.1 as 2nd level (not 3rd). May be because Logseq doesn’t allow a two level jump between blocks. Logseq tab command UI/UX does enforce that too.

Also because GFM Markdown specs specifically allow such markup and describe how it should be rendered.

@cannibalox

### H2.2.1 yyy should NOT be a sibling of ## H2.2. xxx, it should be a child node of ## H2.2 xxx and a sibling of - D1 and - D2.

Good catch. You’re right. I think @pihentagy made a mistake in his example there.

@cannibalox

when we input text in logseq, this rise a lot of ux questions

I wasn’t going to touch that (yet). I was concentrating mainly on Logseq interpretation of # and - blocks within a markdown file.

There are a few ways to take care of the UX for this. The simplest is just literally enter all those markdown formatting on input, just storing them as is. That seems to be what current Logseq do.

@cannibalox

how should we differenciate between ### heading and - ### heading or (tab)- ### heading) since we do not explicitly type - in ls markdown, but only use indent/outdent ?

Current Logseq UX defaults to creating - block. It also provide /h1 command to turn those block into # block if needed. To go the other way just delete the #. Seems reasonable UX to me.

[ChrisVn]

There are so many interesting thoughts here that it seems important to me to sort them out a bit.

• LOGseq is an outliner and I am very happy about that.
• The appearance can be customised via custom.css
• It’s not about keyboard shortcuts either - those can be customised via config.edn.
• Import and export text can also be considered separately. They may result in new, interesting feature requests but are quite independent of the “Outline or Freeform” topic.
• We can find all these points here in the thread - it’s a good mixture of different aspects.
• Outliner has more to do with behaviour and less to do with appearance let me quote pihentagy …

@pihentagy

I am not concerned about the style of the headers, but the behaviour.

• And by the behaviour of an outliner I mean …
  • indenting paragraphs in different levels
  • collapsing and expanding outlines
  • moving outline blocks (also up and down, taking sub-elements into account)
  • to focus outline blocks (zoom, hoist)
• It makes a significant difference in the discussion whether we are only talking about visual adjustments (e.g. not rendering a bullet point in some situations) OR whether we are discussing the behaviour of outliners.
• It becomes problematic when we try to render an outline in such a way, that it is no longer obvious which blocks are on which level.
• I understand the contributions so far that we are talking most of the time about mixing either text blocks OR outline blocks within a page.
• So we would need a “way” to determine if we want to create a block as an outline block or as a text block.
• Then we would have the behaviour of outliners in the outline blocks and a pure Markdown behaviour in the text blocks.

What I don’t want is for Logseq to lose its outline capabilities in favour of free text. But a clever combination of both capabilities would be interesting.

[cannibalox]

Good catch. You’re right. I think @pihentagy made a mistake in his example there.

ok : ) this solves part of my initial confusion as you both seemed to agree on the output.

Why two tabs? Because that defines a 3rd level “-” block in Logseq. Also I wanted to see what Logseq do with it after a # block (…) Also because GFM Markdown specs specifically allow such markup and describe how it should be rendered.

thanks I was wondering what was the expected output, in fact this markup is working but it’s rendered as a code block in most md editors

. I’ve tested in Logseq v0.2.5 and found that it treats ### H2.2.1 as top-level, and make - D2.2.1 as 2nd level (not 3rd).

The simplest is just literally enter all those markdown formatting on input, just storing them as is. That seems to be what current Logseq do.
as you noted in current logseq, there are currently two behaviors for headings:

• top levels headings are treated as a new section (bullet), disregarding the actual number of #
• headings in sub levels are just a display style, they do not impact the hierarchy
• in current logseq, hierarchy is based on the absolute indentation : no tab = root level, 1 tab=level 1, 2 tabs = level 2, etc (I use tab for convenience, it can apply to 2 spaces or 4spaces too)

the request to have headings acting as hierarchical markers too (as in most markdown editors) would alter the paradigm as it implies that - dashes and tabs become relative indentations (relative tio their heading’s own indentation), as highlighted in your examples.
so in this case :

## H2.2 xxx        < lv1
- D1               < lv2
	- D1.1         < lv3
	- D1.2         < lv3
		- D1.2.1   < lv4

but if we add a new heading on top , all levels are offset

# new heading      < lv1
## H2.2 xxx        < lv2 , level is offset
- D1               < lv3,  level is offset
	- D1.1         < lv4,  level is offset
	- D1.2         < lv4,  level is offset
		- D1.2.1   < lv5,  level is offset

so the level of indentation of the raw file (tabs) doesn’t match the ‘actual’ level of of the tree structure (and this is disregarding more complex cases with ### h3 in the middle etc… which is one of the issue mentionned by @ChrisVn :

> It becomes problematic when we try to render an outline in such a way,
> that it is no longer obvious which blocks are on which level.

• there are a lot of difficult cases, like the one I highlighted above: what is the expectation in this case ?

   ## parent
    - 1
        - 2
            - ### new heading <-- typing headings at this level
   ```
  
  

• or here :

  ### h3
     - ## h2
         - would this become sibling of h3 ? 
     - would this line remain a sibling of h2 or should it remain a child of h3 ?
  

just to make it clear : I’m not trying to embarrass with trick questions, I’m genuinely wondering what is the expected behavior and how this should be solved.
is the heading structure more important than the indentation ? (which goes againsht the concept of an outliner imo) or what rules should apply ?

@ChrisVn

What I don’t want is for Logseq to lose its outline capabilities in favour of free text. But a clever combination of both capabilities would be interesting

my feelings exactly.

[sabre23t]

@cannibalox

the request to have headings acting as hierarchical markers too (as in most markdown editors) would alter the paradigm as it implies that - dashes and tabs become relative indentations (relative tio their heading’s own indentation)

True. Agreed. Hence my earlier statement …

@sabre23t

If Logseq implemented this fully, users can actually choose to use exclusively either (i) # heading outline hierarchy or (ii) - bullets outline hierarchy. Some hardcore users may venture to use the (iii) mixed outline hierarchy of # & - blocks.

(i) Users who want # Headings hierarchy can use that exclusively.
(ii) Existing users of - Bullets hierarchy can also stick to using that exclusively including - # bullet with headings blocks.
(iii) Hardy users, long document writers, experimenters can go the mixed # and - blocks ways. Including the intricasies of relative indentations of - bullets under # headings. Note relative indentations intricasies already applies now in v0.2.5; where all # headings are considered top level.

The following is raw results of my exploration in MD format. Cut&paste into a Logseq MD file. My main interest is to see how typical usage of headings in markdown files can be incorporated in current Logseq v0.2.5 and/or any needed modifications. Seems to me it’s already reasonably useable from the example below.

# H1
Having #H followed D hierarchy is okay
- D1
	- D1.1
		- D1.1.1
# H2
Having another #H followed by D hierarchy from top level also okay
- D2
	- D2.1
		- D2.1.1
# H3 
Having another #H followed by D hierarchy starting from second level **also okay**, Logseq treat #H heading as parent of level D3.1 block. This give folding capability for headings that @pihentagy requested, but using the folding capability makes it into a `- #` block.
	- D3.1
		- D3.1.1
# H4
Having another #H followed by D hierarchy starting from two levels down **not okay**,
		- D4.1.1 ... Logseq `tab` interface doesn't allow this skipping one level, it dislay wrong level. Editing any associated level will reformat/remove the extra level.
			- D4.1.1.1 ... display wrong level
- D4X ... can skip levels when jumping back up to top level.
- # DH5
Mixed `-` dash and `#` heading hierarchy.
	- ## DH5.1
		- ### DH5.1.1
		- # DH5-1
		- #### DH5-4

[sabre23t]

@ChrisVn

Then we would have the behaviour of outliners in the outline blocks and a pure Markdown behaviour in the text blocks.

Current Logseq v0.2.5 only recognizes two types of blocks in any Markdown files and I see it behaves as follows …
(1) Starting with - or - # are dash bullet or dash heading blocks.
(2) Starting with # are heading blocks.
(3) All other “text” blocks (list, paragraph, code blocks, tables, links etc) will be included in either above two preceding blocks.
(4) If there are any “front matter” before the first - or # block, it will be displayed as the first block in Logseq.
(4a) If it contains recognized front matter (--- or property:: etc) it will remain as front matter (displayed in black background) after edits.
(4b) If it doesn’t contain any recognized front matter, it will be converted into a - block.

So there are no “text blocks” as such. And may not be necessary to have so too, as per my example in previous reply. I’m interested to see any typical “non-outline (freeform) text” that is not easily accomodated by the above though.

Also it seems - # is a valid Markdown Markup according to GFM Example 278

A list item can contain a heading:

[cannibalox]

thanks for the tests, here’s some more thoughts :

(i) Users who want # Headings hierarchy can use that exclusively.

there is a current workaround for this :

• never mix # and - dashes, instead use * for unordered lists
• the content should start with a heading
• use soft line breaks (shift enter) inside a section, only use enter to create a new block that starts with a heading

this raw file:

# this is h1 followed by (shift enter)
type any content and use (shift enter) to create a soft line break
* use `*` to create unordered lists
* shift enter to make new lines
## a h2 heading
some more text
### h3 heading
so as long as we don't try to mix `-` dashes and `#` headings it's possible to write long-form documents following these rules :
* use shift enter to make new lines/paragraphs
* never add a dash, use `*` instead
* use `enter` only if you want to start the next block with a heading
* the raw file can be read in typora with correct folding
* limitations :
    * it's not possible to make a soft linebreak followed by a heading : the heading will not be rendered
## back to h2
logseq 0.2.5

is rendered like this in logseq:

and works in any external editor like typora

so in a way it’s already possible to do long-form writing in logseq as long as we replace - with *.
the limitation being that in logseq, the H1 will not fold the sub-sections in the example above, which is what @pihentagy requested.
but I wonder how useful that is : if the main use case is to create and view the doc inside logseq, then why not use classic bullets ? if the goal is to create in logseq and view elsewhere, than does it really matter to fold the h1 inside logseq ?

[sabre23t]

@cannibalox

? if the goal is to create in logseq and view elsewhere, than does it really matter to fold the h1 inside logseq ?

If the goal is to create in logseq and view elsewhere, then does it really matter that using a - will create a new block? The generated/stored MD file will have the - in the same place as if it hadn’t created a new block. Also Logseq enter & backspace key combo does transparently create block & merge it back together.

Logseq propensity of turning # into - # without any notice or visibilty is still an issue though. That - # is not recognized as a heading in some other Markdown editors even though Github GFM Example 278 does.

@cannibalox

H1 will not fold the sub-sections in the example above, which is what @pihentagy requested.

Actually it does (somewhat). You can click on the triangle next to the bullet for this is h1 followed by (shift enter) and Logseq will hide the rest of that block (text and * list items). Yes, it doesn’t automatically collapse subsidiary h2 and h3 headings (because Logseq 0.2.5 treats all # headings as being at the same top-level).

[ChrisVn]

@scurra

It would be very much like to be able to partition items that have a certain “mental distance” to each other with some spacing:

At least this use case is possible with the new version 0.2.7
Empty blocks no longer show the bullet point. For me this is a minimal but very useful change.

[sabre23t]

@ChrisVn

a minimal but very useful change

Yep, that v0.2.7 new feature for separating blocks with empty spacing is nice (no block bullets on emply blocks). I’ll likely use more of it. On making the empty block as child block instead of sibling block give different visual impact, also nice.

I was separating blocks using --- HR block with custom CSS to centre it on the block bullet, hr { margin: 0.8em; }.

[dcoales]

I have noticed some inconsistencies in how LogSeq is treating headers in recent releases and documented them here Headers rendered inconsistently in markdown.

Sometimes the bullet is being removed. Other times not. Even if the bullet is removed from the markdown, simply indenting and un-indenting puts it back. The problem with removing the bullet if there are indented children is that the indented children then appear in a code block in Typora or Obsidian which looks terrible.

I would suggest that the bullet is only removed from headers that are not indented AND do not have indented children. In all other cases the bullet should remain. That should satisfy users that want free format text and those that want to use the outline style.

[Fastidious]

What if bullets were only shown on mouse over/block tap? Wouldn’t that be a good compromise?

[dcoales]

It’s not about how the bullets appear in LogSeq but whether or not the dash representing the bullet is added/removed from the markdown file. If the dash is removed then nested bullets don’t render properly in other markdown readers.

[Bader]

Possibly a duplicate of Longform writing in Logseq - #8 by RXA

@moderators should these posts be merged?

[Dor]

One of the things I don’t understand is why Logseq doesn’t simply use typical OPML outliner-markdown conversion conventions as the basis for alternative views.

Here Bullets=Headers
Lines and paragraphs in a note under the bullet are converted to text under a header.

The only decision required is how to handle deeper hierarchies. H7 , 8 etc is not uncommon. Lines starting - are treated as bullets within bodytext.
There’s no obvious reason why Logseq couldn’t offer this as an alternative view as well as OPML import-export.

[acowegg1]

One thing you might find helpful which I don’t think has been mentioned is the advanced command <verse.
Using <verse, you can start a section within a block which respects new lines added with the enter key.

I use this frequently - any time I need to write more than 3 or 4 lines, and it works well so far with blocks containing over 100 lines.