Paragraph Spacing?

V1 had paragraph spacing - which I liked to bump up a bit and not have to insert lines between paragraphs for readability.

I see editor settings in the latest B2, but no paragraph spacing! Is that coming back?


I do not have the bear versions of mac distributed over test flight. Nevertheless my comment:

Paragraph spacing is essential for typography. I hope that setting will be implemented


Agreed - this is sorely missed in the beta. I was hoping would go even further than before and let us have different vertical spacing for bullets vs. regular paragraphs (I like big spacing for paragraphs, but that made bullets look pretty weird.) But I’d gladly keep the old model to get at least some adjustability for paragraph spacing vs standard line spacing. Most of my notes are pretty hard to read now with this all flowing with the same spacing.


Hello folks,

we didn’t include paragraph spacing by design.

It doesn’t work well with Markdown, as you have to manually include a empty new line to create a new paragraph. So artificially adding it in Bear wouldn’t translate in a real paragraph inside other tools.

It’s not a trivial feature, and we don’t want to add multiple settings for it as it won’t benefit the majority of our user base.

We could bring it back, but there are still a lot of question marks about how it should work, for example:

  • headers and normal text paragraphs should always apply it
  • lists are weird, because each list item is a paragraph, and those can contain multiple paragraphs as well, how that should work?
  • how about code blocks?
  • footnotes?

We can use this thread to discuss the paragraph spacing, but finding a simple solution that works for everyone (without adding a lot of different settings) is not a trivial task.


it is not really clear for me what it has to do with markdown. In raw markdown you would see two hard line breaks wheras in bear editor the spacing between two paragraphs are a little bit greater than between two lines of the same paragraph. Isn’t that just a matter of visual presentation?

  • headers and normal text: yes, it should apply
  • lists: no, they should not. They are paragraphs in a technical sense but not in terms of content. The most regard a whole list as one paragraph
  • code blocks: i do not use them and i do not write code so i cannot say nothing to them
  • footnotes: no, it should not apply. same reasoning like for lists. in terms of content they are a unit

Actually spacing is important for normal text and headings for one reason: if you have longer text the readibility is suffering without spaces incredibly. I am everyday in bear and are reading text: to sacrifize one option just to worsen readibility is not a good idea. Actually i was satisfied with bear 1 solution


I understand the issue, but some of these questions had answers in the previous version of Bear. And a user wanting the current beta behavior could simply leave paragraph and line spacing the same. So customization here doesn’t seem too harmful.

I definitely understand the impact of not having new line paragraph breaks if you plan to live entirely in Markdown tools. When doing software development, you learn pretty quickly to do manual paragraph breaks since Markdown in coding tools is minimally formatted (e.g. rendered Readme on GitHub.) Someone using Bear to publish in this way could easily add their paragraph breaks by hand, and leave paragraph spacing as its default.

However, that’s not really how I use Bear (e.g. for notes, not code), and is not the writing experience for Bear 2 as it intentionally hides the Markdown characters most of the time. It seems the theme of V2 is to give maximum attention to nice presentation, while allowing the writer to use their Markdown muscle memory (and backing data format). It’s my greatest appeal for using Bear, frankly.

So to answer the questions, a simple answer is to mimic Bear 1. However, these are indeed great questions, and I would offer a couple new answers in v2 if that’s possible. This would be my personal preference (noting that people can get today’s behavior by tweaking these values pretty easily):

  • headers and normal text paragraphs should always apply it

Yes, extra paragraph padding applies to headings and CRs within standard text bodies.

  • Lists are weird because each list item is a paragraph, and those can contain multiple paragraphs as well, how that should work?

Awesome if lists would be a separate setting, e.g. “Paragraph spacing” and “List item spacing”. However, if I had to choose all or nothing would probably keep the old Bear 1 approach of treating lists as paragraphs. But I could live with either options.

  • how about code blocks?

Same as any other “paragraph”. You hit RETURN before the code block most likely, so there would be paragraph spacing before/after the code block.

  • footnotes?

Not as familiar with how these are handled, so nothing to suggest.

Cheers, and thanks for listening!

1 Like

Yes I totally agree that it’s a matter of visual presentation, just like why Bear designed Bear Sans font and decided how the default editor UI looks.

It will be a different story in other markdown apps because they can control how it looks in their app, who knows maybe they only allow Comic Sans in their apps and it’s totally their choice! :smiley:

So… is it possible to just make add a tiny little bit spacing between paragraphs (just headers and normal text), which doesnt look like a whole new line in between, and make paragraphs more readable? That being said, I assume the spacing will also change depending on the font size and other settings and it can be way more complex than we imagined.

This is helpful. I would say, on balance, that it would be better NOT to provide “paragraph spacing”. I have been using various markdown based tools for years and in my experience it causes more problems than it solves and the attempts by different developers to solve the problems you list make it worse. You set up one app to work as you wish, but files it exports or shares don’t work as expected in other apps. Much better to stick with commonmark:

A paragraph is consecutive lines of text with one or more blank lines between them.
For a line break, add either a backslash \or two blank spaces at the end of the line.

It’s perfectly easy to read text that separates paragraphs with blank lines but adding additional, configurable white space after some line breaks but not others and then trying to define universally which ones, is a recipe for confusion. Far better to have consistent, simple behaviour.

As I have learnt in many previous discussions, part of the issue is widespread disagreement over how to make a paragraph break. Is it one press of the enter/return key or two? There’s no philosophically correct answer, but markdown has always favoured the latter and coding markdown based apps to accept a single enter as a paragraph (and add space automatically) is what causes all the additional problems with rendering lists and the other problem cases.

I’d keep it simple. If you want to present your text with all the visual nuances, export it to desk top publishing and do it properly.


That maybe in web because everyone get used to that. In books or articles that would never be the case. When looking on my texts in bear i do not regard them as web content. I think here are two different point of views which are not wrong or right. The sense of options is to adress such cases

One further comment:

If i have to i could also live with a whole line as space between two paragraphs although i wouldn’t like it. But i do not know how to get used with pressing two times enter just to create a new paragraph (or space between two paragraphs). That is totally against all habits i created in the last decades.

Honestly i do not understand fully the markdown related problem. If you hit enter in bear then you get a new paragraph - does that mean in raw markdown you would see an additional line as space between these two paragraphs? In my mindset i just know “enter” for new paragraph and “shift enter” for new line in same paragraph.

I have to second. my writing experience in bear is not ruled by a techy access to markdown. I am just interested in not being distracted by richt text editing. I get known with ulysses and then with bear 1. Both showed the mark ups. The removal of them is one step further in progression: now even the markups of markdown syntax are not distracting. And that’s all what markdown means to me

Sorry to hijack this thread but somewhat related - headings seem to have pre padding (padding/margin on the top). Could we consider ridding of that (maybe with an option) to make the note content more consistent visually?

If you hit enter in bear then you get a new paragraph - does that mean in raw markdown you would see an additional line as space between these two paragraphs? In my mindset i just know “enter” for new paragraph and “shift enter” for new line in same paragraph

I’d say that a single enter is really making a line break and two makes a new paragraph. In some markdown editors you wouldn’t see ANY break in text from simply pressing enter once. In some, you would see a line break and in some you’d see a blank line. Some would give you TWO blank lines if you pressed enter twice to make a new paragraph. That’s all from different interpretations from different developers about how they want markdown to be rendered. Bear has adopted commonmark, which is the only attempt at a consistent standard. I think adopting commonmark is the right call and it defines a paragraph as separated by a blank line.

It’s nothing to do with a techy access to markdown, but keeping things simple to allow the widest possible range of uses for Bear. As Mateo explained above, adding white space is complex and breaks things for many uses, even if it can make it nicer and easier to read if you write in continuous prose. You can, of course, write continuous prose by pressing enter twice to make paragraphs.

I have dozens of printed books of many ages which use single blank lines to demarcate paragraphs, dozens that have no space at all between paragraphs, but indent the first line, and many which use white space of various sizes between paragraphs. They all work, as does reading on the web. There are no firm rules in any kind of design for writing or reading except that it works.

1 Like

One other idea (not sure I love it, but throwing it out there): Paragraphs could follow the spirit of “real” Markdown, with a nicer presentation used in Bear 2. The idea being that you could require a blank line (two CRs) for a paragraph break, but then give the option to display a vertically shorter break for the paragraph, rather than a full-height line. The user could place their cursor on that line and it would expand for them to type, much as headings or other blocks “expand” when you put the cursor inside to edit them.

This would preserve the muscle memory of typing in Markdown the text that is actually stored in the file, but not force a new paragraph to always look so dramatic. Nicer presentation, accurate Markdown.

I personally use pretty large text in Bear with tall spacing between lines. I think it looks really good. But combining that with a full line for a paragraph break looks pretty comical. So having a smaller paragraph break, but still noticeable above the standard line padding, would be a nice compromise.

Not sure that matches most folks requirements, but I could see the argument that this would be more “true” to the Markdown approach, while overcoming a visual annoyance. Feels similar to hiding the bold, italic, or heading markup characters.

Is that your assumption or do you know that a single enter doesn’t create a new paragraph? I think it is not clear what we mean: is enter creating a paragraph or not? If yes does a blank paragraph has to be created just to make a spacing visible?

Please don‘t speak for many users if you don‘t know how the expectations really are. Nobody of us has counted them. The most people I know come from rich text editor and the expectation is clear. That is exactly something that could and should be cleared by an option. That is the sense of an option. I do not know how big one group is, I just know that my big group is. And to be honest, sometimes it is not nevcessary that there is an relation of 50:50 to legitimit an option. Also the importance of what is ruled by an option is imported. And editor settings in an editor rule the core experience and are fundamental

Sorry, in earnest, i do not understand. What is broken for many users? How can it break something? In bear 1 it was possible to adjust spacing all the time

If there are no rules so that is another argument for an option

option to display a vertically shorter break for the paragraph, rather than a full-height line.

Continuing this idea (and liking it a bit better) - this would also solve the visual weirdness of requiring an empty line to end a series of bullets. The empty line after the bullets would be much nicer looking if it didn’t take up as much vertical space.

I am not capable of wrapping my head around that. I understand the logic that leads to the result of the preview. But on the other side: when i use just one “enter” for creating a paragraph in bear editor i also see a new line in text edit after exporting the note to txt.file. Is one “enter” a new paragraph or not?

I suggest adding Paragraph Spacing to Bear 2. Here are reasons.

  1. Ulysses provides Paragraph Spacing. And yes lines and headers are paragraphs.
  2. In Bear 2, Paragraph Spacing can be optional. Users who like to set space between paragraphs can set it manually and willingly. But those who believe it will destroy markdown can use default space.
1 Like

As far as I know, if you want use really real markdown then you use a simple text editor and convert it to html

I’d say that a single enter is really making a line break and two makes a new paragraph.

Is that your assumption or do you know that a single enter doesn’t create a new paragraph? I think it is not clear what we mean: is enter creating a paragraph or not? If yes does a blank paragraph has to be created just to make a spacing visible?

That’s how a paragraph is defined in the commonmark standard, which Bear 2 has adopted. A paragraph is lines of text followed by one or more blank lines. You can have line breaks within paragraphs, but you can only make a paragraph by making a blank line.

It’s a shame you misread my comment. I talked about “uses” which break if you insert paragraph spacing. I have no idea how users want to use Bear or how diverse the things they use it for are.

For example, suppose I want to write song lyrics interspersed with prose commentary (as I do occasionally). If I have paragraph spacing the lyrics won’t look right. If I don’t, the prose won’t look right. However, without paragraph spacing I can choose to insert blank lines after each prose paragraph so both work. There are many similar examples – as Mateo mentioned, people who write and comment on code have huge problems if there is paragraph spacing.

On top of that (just as I found with Ulysses) paragraph spacing is adding something that does not reflect the underlying markdown content, which can give unexpected results when you send that document to another app.

And I think Mateo is right to resist adding more options than are strictly necessary. One of Bear’s great strengths has been that it does not try to be everything to everyone: Bear 2 is an elegant, simple commonmark editor for notes. That means it can be used for an enormous range of purposes, but might require the user to adopt habits and workflows to achieve their desired results rather than (like MS Word, for example) having hundreds of options and menu items that try to do everything for them.

1 Like

Then just do not use the option to place spacing?

I think it indeed my very diverse but the main use case is note taking and writing. That`s the reason why options sometimes make sense: you are setting them for your own use case

He gave reasons why it is tricky but he didn’t resist but asked for some input for consideration

Sorry, but that argument i also could tell in your direction in regard to song lyrics which by far is not the usual case. But why should i? In regard to paragraph spacing we are not talking about a bizarre feature for an extravagant minority but about a fundamental element in typography. I really do not believe that the majority of bear users are markdown evangelists who wants to keep commonmark holy. Actually even no commonmarks standards are broken. The question is: How is the content in the editor presented. If someone is indeed interested in pure markdown then a - as said above - a barebone text editor might be the better choice than an editor that even hides the markdown syntax