Multiple adjacent blank spaces in and between paragraphs collapse to a single space when displaying a note in [Reading view]
But it’s INCONVENIENT. When I put carriage transfer (via simple ENTER) in preview mode, I want to see it in the document and in reading mode! This is a very inconvenient rule when I refer to a document via ![[]] - and my 3 carriage transfers collapsed into 1.
I know about special characters like <br> and etc., but IT’s NOT CONVENIENT. If I made 3 carriage transfers in preview mode by Enter - I expect to see 3 carriage transfers! Not 1! Not 0! 3!
My big asks:
n carriage transfers in preview mode = n carriage transfers in reading mode
In general, everything is optional. spaces in preview mode were also displayed in reading mode. I mean this:
First of all, try to turn OFF “Strict line breaks” in the “Editor” settings. If you turn that off, Obsidian will keep single line breaks.
But this is a Markdown editor, and this is how Markdown works. So unfortunately, you’ll have to find a workaround or a plugin if you want to display more line breaks.
Thank you for reminding me about the strict line break setting which I just turned on As noted Obsidian is a Markdown editor, not a rich text editor and I prefer to have it work the way its supposed to work. To me its inconvenient to not have it work per the spec
I am talking about obsidian - I expect the option to auto-increment <br>/<smth-else> “under the hood” at the end of each “raw” line at the compilation stage of the final document under reading-mode - and IT IS IMPORTANT to put this setting active by default!
This is an inconvenient crutch solution - to start a plugin, start a folder there, start another plugin, connect, eventually do carriage transfer not through enter, but through another plugin and catch potential bugs when working with callouts, rendering to pdf, etc.
This is not some supernatural request. A person puts a carriage transfer - so he wants to see it EVERYWHERE. Take pity on the user’s psyche, in obsidian and without such elementary things, you need to configure too many other things.
Look at the Word (for example) text editor - how do you imagine a lawyer who put carriage returns in a document, but does not see them in the printed state?
We are people and we make up the text with our hands, there is no need to appeal to some abstract technical concepts and shift it to the user. It should be done CONVENIENTLY and CLEARLY to the user, and not to the machine or the imagination of a programmer who once read something there about the philosophy of “technical something there” and therefore the user should sit and write with his hands in addition to enter or dig into the next 100500th plugin.
I understand what you are referring to. But in your screenshot, it looked like it was collapsing more than it should be if that “Strict” option is turned off, which is why I suggested it.
As for your last post (which was flagged), I understand you are frustrated, but you will keep it civil in our community.
Understood. No, everything is normal here, I’ve been scouring the forums and internet before I write. And I also saw the your recommended message before I wrote this post.
Everything was civil there, but OK, they deleted and deleted, I conveyed the main idea above.
I wrote that I know crutch solutions - but they are CRUTCH solutions.
Any solution that requires ANY action from the user so that a normal carriage transfer is considered a CARRIAGE TRANSFER is a crutch. Please don’t suggest such a thing in this topic.
It is needed a simple solution that will not bite the user’s brain - carriage transfer = carriage transfer. That’s the point. Everything is simple.
Any solution that requires ANY action from the user so that a normal carriage transfer is considered a CARRIAGE TRANSFER is a crutch.
This is how Markdown works and has always worked as far as I know, so it seems that your problem is with Markdown, not Obsidian or any other Markdown editor. There are some other possible solutions:
An Obsidian plugin which solves this solution for you, which may or may not already exist. You could make a feature request to a plugin like Linter to add a linting rule which preserves consecutive newlines. If moving away from Obsidian however, you would need to find a new solution.
You could create an AutoHotkey script to cause, for example, your Return key to send \\\n instead of \n when working in Obsidian (but this would likely have undesirable side-effects). If useable, this solution would work in other Markdown editors as well.
You could alternatively use a different tool for text, such Logseq or a traditional word processor. Both will retain consecutive newlines.
My point is very simple - carriage transfer = carriage transfer. All. To make it obvious, it worked, and did not require the user to install plugins and (that more worse) do a lot of unnecessary handle actions and etc.
I expected that the core team would just take the task to the backlog and someday do it when they can.
Crutch solutions - I know, I see, thank you. They’re all terrible, really, but I’ll choose something for myself. The topic is not about that.
You can come up with excuses for any crutch, take justifications from books, etc. - but the fact remains that IT is NOT CONVENIENT. NOT OBVIOUS. NOT USEFULL.
And in general, it is would be very nice to strive to bring the corresponding preview of the mode with read mode to 100%, then everything will be fine.
If there is no desire to take it and do it normally, don’t do it, I can’t force it. Thank you all.
I figured out that I can bind a template to a hotkey either via template+template-to-hotkeys or via templater. Got a folder, did everything according to the instructions, cool!
There is no difference: markdown, obsidian, even the Pope!
Let the application put these for me when rendering, and also removes them if I just delete the line.
There is a lot of workaround. After all, they have already turned off the “strict line breaks” - for which thank you VERY much! But it’s clearly worth finishing, why not just take it to the backlog? I’m not yelling “DO IT RIGHT NOW”
All the crutches presented above:
They require additional actions from me in using the type of prescribing with hands, slashes or ```br ```, etc., which means that I will have to turn over at least a lot of my current notes and look back at reading-mode in the future, and this is UNACCEPTABLE
Have pitfalls like the above - when one special space generates an inadequate space (too large/small)
Why the user should be blamed for the problems of carriage placement is not clear at all.
To me, a markdown outside the obsidian ecosystem has no any value
The problem is that in Obsidian you’re writing code, not plain text, and just like in other coding languages you sometimes must do “inconvenient” things like end the line with a semicolon before pressing Return for the computer to understand it. It’s just how it works. When I’ve used a language which I think has annoying syntax, I adapt, or I choose another language.
There is no perfect tool. There are nuances everywhere. While obsidian is optimal. And I spent my time, figured out the problem, described it here and proposed a solution (with an upper-level view).
Then it’s up to the developers to listen and take a backlog and do it someday, or left this issue.
It can be better. If devs will do it - cool. If devs don’t - not cool. I’ll survive.
As noted Obsidian is a Markdown editor, not a rich text editor and I prefer to have it work the way its supposed to work. To me its inconvenient to not have it work per the spec 