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
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.
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.
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”.
‘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 onlyones
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…
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.)
… 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!
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.
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)
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.
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.
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 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 ?