I don’t exactly know what it does but does seem to remove/disable outline completely, which is not what I want.
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 
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 
I can’t think of genius solution right now… I’ll sleep on it.
1 Like
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…
3 Likes
So I slept on it 
and thought about it 
I believe the ‘issue’ can be broken down into two points:
- the editor does not display raw text
- 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! 
(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 ! 
(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!
2 Likes
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:
not as:
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?)
1 Like
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
1 Like
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.