Allow non-outline (freeform) text

it is just a way to “free write” when “enter” will be like “shift enter” and new blocks are created using “Alt Enter”

so if you usually write more “paragraphs” than simple ideas it might be ideal for you

from what I understood it is exactly what you need.

I might be wrong

sorry for the late reply… No, currently it’s not possible to target these blocks, as the .admonitionblock class is applied only to the tip block, not its bullet, so there is not way to select that bullet.
I’ve made a feature request here Propositions to empower css mods: , you can upvote, as this should help to solve your issue and more

1 Like

Hi cannibalox and thanks for the solution you already suggested a few months ago.

Do you see a chance for a css hack that fades out the bullet point if the block contains a ---
If that would be possible I would really appreciate any hint/help.

Thanks
Chris

Hi Chris. You should be able to press “t” “d” to activate document mode. Hopefully this is what you are after. The document mode is under development to improve it.

1 Like

Thanks for your reply.

I am used to outliners (used and still use Checkvist heavily) and like the bullet points. So I don’t want to get rid of all the bullet points but only for blocks that I use as a seperator ---

This way I could separate the “ideas” similar to the example scurra initially posted. It is simply an aesthetic attempt because I really find the bullet point in front of the horizontal line “ugly”.

I am very bad at hacking css and don’t know if this even would be possible.

3 Likes

I think @scurra says it best with:

‘Outline vs freefrom’ definitely feels like a false dichotomy, and I personally would love not to be forced to have everything as bullet points! For me, non-linearity (mentioned on first line of the README) is both inter-nodal and intra-nodal :globe_with_meridians:

I appreciate the the team have so far heavily invested into the outlining paradigm, and that it would bring complexity to satisfy our desire. But it’s seems we aren’t the only ones :busts_in_silhouette:

I can’t think of genius solution right now… I’ll sleep on it.

I’m thinking that there could be a document type that is marked by a document level property: type: text or something like that, which turns off outline features for that document. Wikilinks and embeds could still work, but other outlining features might be turned off for such documents. I feel that the t d mode isn’t very useful, but something like this might make long form writing in Logseq a little better? Just a thought…

2 Likes

So I slept on it :sleeping: and thought about it :thinking:

I believe the ‘issue’ can be broken down into two points:

  1. the editor does not display raw text
  2. outliner hyphens are automatically added

Subissue 1 prevents the user from seeing the ‘outliner hyphen’, used to indicate the block. (It also hides whitespace, but I’ll ignore that for now.) Not being able to access the raw text means one can’t directly remove the outliner hyphen, except for backspacing to the previous block then newlining (shift + enter). Not being able to see the raw text goes against the point of the markdown format in the first place, IMO.

Subissue 2 somehow feels easier, since the functionality already exists in Logseq. It could, for example, be solved with an option to switch the default behavior of enter (new block) and shift + enter (new line)

@Luhmann my issues with your proposal to add a document level property are: that I would have to set this for each document, and that it would introduce ‘Logseq-specific’ metadata to documents that otherwise wouldn’t need it. I do, however, like the proposal to use the existing t d document mode as a vessel for required changes! :smiley: (Also, is there a list where the ‘advanced’ t x shortcuts are listed? I couldn’t find one so far.)

1 Like

Subissue two can be achieved by adding

 :shortcuts 
 {:editor/new-block          "shift+enter"
  :editor/new-line           "enter"}

… to your logseq/config.edn ! :tada: (There is a shortcut section, starting for me at line 79, with examples) This successfully reverses the default behavior, to make enter perform a carriage-return/newline, and shift-enter to make a outliner block.

A new note still begins with an outliner block, but once manually removed, the document remains as freeform text, until a heading is added, at which point blocking is retroactively added. Still, closer!

1 Like

LIke @Ed_Nico said, you can press t d (non-editing mode) to toggle the document mode, which has some tweaks for freeform writing.

1 Like

Hi all!

I’d like to use logseq as an outliner, like one can use Word (in the good sense now).

So, if I have a file like this:

# This is h1

Some text

## This is h2

Text under h2

## Another h2

Some text

It should render as:
image
not as:
image

Note, that this rendering went through a great progress!

However, if I format the text in Logseq, the markdown file turns to this:

- # This is h1

  Some text
        - ## This is h2
          collapsed:: true

          Text under h2
        - ## Another h2
          collapsed:: true

          Some text

Could I somehow produce bulletless headers? Or at least could we have rendered the first markdown sample “right” (so h2s are under h1?)

You could render the above H2, H3, H4, etc with increasing indents using Logseq custom.css feature. You can have them even bulletless (actually transparent invisible bullets for UX reasons). I’m not expert in that, but the guys in Logseq Discourse #custom-themes are.

I am not concerned about the style of the headers, but the behaviour. If you fold h1, all content should be folded.

That was how Logseq treated # in versions 0.1.x. In those versions Logseq treats # headings as outline blocks.

However since version 0.2.x, Logseq use - list items as outline blocks. Folding top level - blocks will fold all sub-blocks.

Since then # headings are all treated as top level blocks, whether they are ##, ### etc all are considered top level blocks.

Mmm … How do you see Logseq should render indentations (and folding) of the following mix of # blocks and - blocks?

# 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
# H3

Like this.

On the writing side:
If you convert a bullet to header, all parents should be converted to corresponding headers. (h1, h2, h3, based on the actual structure)

1 Like

I would like to thank @sabre23t for this comment which shows it is possible, although fragile, to write ‘freeform’ markdown in Logseq right now.

# How to write free form in Logseq

It is possible, but fragile, to write 'freeform' in Logseq, right now.

Firstly, one must immediately start with a `#` style header. This acts as the first block, without hyphenation. 

Secondly, one should only use newlines, `shift+enter`. New blocks, `enter` will be hyphenated. One can make this easier by [swapping the keys](https://discuss.logseq.com/t/allow-non-outline-freeform-text/172/31?u=douginamug) for `new-line` and `new-block`.

You can also write other headings, which also won't get hyphenated, but this will lead to a fracturing of your editor experience in Logseq, since the next heading will count as another block. Additionally, new headings and lists using `-` require one to refresh the note to see them in view mode :/

## Look ma, no hyphens

One thing to note is that moving blocks _will_ lead to the introduction of hyphens on those blocks.
1 Like

That looks doable for Logseq to my non-developer eyes. In fact I think that is what the Markdown document standards specify [1]. The markdown - or * bullets list items are subservient to the headings hierarchy. The unordered or ordered list items restarts relative to every # heading.

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

Is it really doable @tienson ?

Mmm … @pihentagy perhaps your proposal on these # headings outline hierarchy deserve its own feature request thread.

[1] Ref Markdown specs such as GFM Specs

2 Likes

but this brings more questions :
should ### H2.2.1 yyy be a sibling of ## H2.2 xxx ?
when we write

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

do you expect the result to be

H2

H2.2 xxx

H2.2.1 yyy

or

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.

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 :
    image

### 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)

  1. 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 ?