Multiply carriage returns/newlines/line breaks in preview and reading modes

It says the following here:

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:

  1. n carriage transfers in preview mode = n carriage transfers in reading mode
  2. In general, everything is optional. spaces in preview mode were also displayed in reading mode. I mean this:

Where does the space come from? What for? And the main thing in reading mode is that it is not there!! Why is this out of sync? It’s inconvenient!

Moved to Help.

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.

You can review this thread for additional ideas: How to add multi line breaks in preview mode - #7 by OlivierPS

1 Like

Thank you for reminding me about the strict line break setting which I just turned on :wink: 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 :wink:

Sorry, but it is off topic) I’m talking about MULTIPLY carriage transfers, not 1. This option is already disabled for me, everything is fine here.

No, not like that. Markdown is a vague concept.

  • there are many different parsers - you can look here Comparison Javascript Markdown Parsers
  • 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.

Although not as convenient as you would find pressing Return to be, Markdown allows you to use a single backslash \ on a line to produce a line break.

Line 1
Line 5

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.

As you are using a Markdown editor, I’d review:

Word is not a plain text editor:

There are important differences between plain text (created and edited by text editors) and rich text (such as that created by word processors or desktop publishing software editor.

Perhaps Word, etc., would be a better fit for you?

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

Please read through my documentation to see possible solutions and if possible, support my project


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.

And by the way, no, my fun does not even think of ending!

Let’s laugh together, gentlemen!

I take the first “kind of” solution that comes to hand: How to add multi line breaks in preview mode - #13 by chrsle

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!

Now look what I’m getting:


Gentlemen, isn’t it funny?

I wanted a small space between the line and the header, but I got an x3 space from the one I have in preview

And I just started this! And how many more bugs do you think I’ll find?

This is an incredibly user friendly solution! Wow!

And most importantly, all this torment for what? SO THAT I HAVE A CARRIAGE TRANSFER

What you’re asking has nothing to do with markdown.
There’s not such a thing like a normal double carriage return in markdown.

Markdown is not the same as rich text, try other software like macjournal if you’re on a mac. I don’t use windows, but there’s ms Word.

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:

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

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.