Hi @matteo,
Currently there’s spacing for headings. In the following example, there’s more spacing above heading 1 than below it. Could we consider remove that spacing above as the other elements have no spacing (till we add the option proposed by this thread of course), so the headings look more visually consistent with the rest of the doc
paragraph 1
## heading
paragraph 2
Well, you guys went above and beyond with the new update. Paragraph indenting as well!!
Thank you for the paragraph settings!
I see the paragraph spacing in the latest update - and I kind of like it. Now that I see responses in this thread - I see how this is a more complex issue. For example, when I envision paragraph spacing, I think it would apply to written paragraphs and not lists.
Maybe a (longer term) solution is to remove these settings - in the name of simplicity, and then allow a user to edit their CSS for Bear? That could be an advanced setting (maybe a pro feature?). One reason I suggest this approach is because if we look at HTML/CSS - paragraph spacing/padding is usually very different for H1 vs a list item. A simple CSS edit tool would be a way for each user to tweek defaults.
Just an idea.
I just want to say that new paragraph spacing implementation is superb! Probably contrary to many people here in the discussion, I never had problem with hitting Enter twice, so space between two paragraph was always ok for me. But I always like some more space in lists (between list items) to denote, that it is not just continuous flow of text, but really - different points. Logseq and Roam and Workflowy always differed between their within-list-item line height and between-list-item line height.
With new Bear 2.0 settings I can accomplish exactly this. Thanks!!!
I have the same feeling about lists, but I actually only want to differentiate list item spacing, not all other normal text in my notes. Perhaps there can be a separate setting slider for “List item spacing”?
For my use case–creative writing–they’ve solved all of my issues with the new addition of paragraph indenting. So in Bear 1, I used paragraph spacing to make my stories more readable. Now, in Bear 2, I have that set at zero with paragraph indenting turned on instead. It works for me, as I prefer to have less spacing on things like lists.
That is very good idea, however I am pessimistic a little bit that developers would agree with such great level of freedom in settings 
That would be definitely the best, because I usually need smaller list item spacing (just to make individual list items noticeable by slightly more margin) but I like bigger space (± one full omitted line) between paragraphs. That’s not so big issue as I can still press enter twice and adjust to the fact that the between paragraph margin is even little more bigger (two enters + paragraph spacing) than it would be to my best liking. Your proposed solution is best IMO.
Thanks! Yeah, in practice, making lists and writing normal text each function differently in practice/purpose. It seems prudent to not roll those two things into one with the setting.
You might be right about the devs though 
Hopefully we hear back from them about it.
I’m actually realizing I’d gladly use the paragraph spacing feature as it is (folded in with list spacing), except that up until now I’ve exclusively been using two paragraph breaks (enter+enter) in all of my notes to simulate paragraph spacing.
So I can’t really start using it now, as I’d have to go through and update my 500+ notes.
This also made me realize that in a Markdown renderer (like this forum), two paragraph breaks convert to a single paragraph break with custom spacing.
So if this setting is turned on, shouldn’t two paragraph breaks in Bear actually render as a single paragraph break with the custom spacing? That’s not currently how it functions.
I actually would want the opposite. haha But I’m cool with separating paragraphs with a new line
That would be logical however it would further complicate the issue, as there will always be users who want to use and see their two paragraph spaces (two enters) and those who want to render paragraph space just after one enter press. I believe in Typora you have the possibility to choose (whether one or two enters denote end of paragraph). Maybe not a bad option but again - I do not believe that this is a direction towards which developers would want to go. Lets see.
(As for me now, I do not mind that I have quite a bigger space between paragraphs (I also use two enters + newly set paragraph space) but I am also considering that I would use both - (1) smaller space between paragraphs just by pressing enter once - which would denote closer relationships = continuous text usually. (2) And bigger space (two enters) for denoting that these are different or not continuing ideas/flowing text. I will test it and will see.)
I totally see your point. Here’s one possible solution:
If Paragraph Spacing is on, then pressing Enter once creates two line breaks in the underlying text, but always renders & functions as a single paragraph break.
If you want extra space between unrelated paragraphs, then after the usual paragraph break, add a single line break with Shift+Enter. That makes three line breaks in the underlying text.
In this solution, two line breaks always equal one paragraph break. That means for every single user who ever used two enters to separate text (probably almost everyone), all their existing notes retain their intended legibility whether the setting is on or off.
It’s also fully Markdown compatible, unlike the current implementation, where the underlying text is only a single line break yet shows up as a paragraph break.
I just want to gently bring this back up, in the hopes that the devs will really consider my suggestion there on how to implement paragraph spacing. I really don’t see how most people could otherwise use this feature, with all their existing notes having two breaks between paragraphs already.
I’m not sure I exactly follow the suggestion, but I agree that the merging of paragraph spacing for bullets (which I like) and display spacing for paragraphs, is broken for representing both valid Markdown and good presentation.
My personal preference is to treat a properly-typed paragraph break (e.g. a fully empty line per Markdown spec, where you hit RETURN twice) by rendering as double the paragraph spacing setting, rather than a fully empty paragraph. This is consistent with the way Bear displays Markdown with a more appealing look, while preserving the underlying Markdown.
So for instance, if my Typography > Paragraph Spacing is set to 0.4em, Bear would show 0.8 em for proper full double-return Markdown paragraphs.
This wouldn’t require a new preference, would look nice (without the HUGE paragraph breaks shown today), and yet would clearly indicate a proper Markdown two-CR paragraph.
I personally want to write proper Markdown with the double-CRs, but writing like this just takes up way too much vertical space, so I therefore am inclined to not use double-return paragraphs for aesthetic reasons, yet that creates not proper Markdown text.
Example as I have it set today with 0.4em for Paragraph spacing, to make bullets look nicer:
Just do not use the option 
I get it, but even leaving Paragraph Spacing to the default zero, a proper Markdown paragraph has a huge vertical space between paragraphs of text. It is a much bigger vertical break than you would see in any printed page, or on any website, just to accommodate the Markdown spec of two CRs.
Much like Bear sees the markers for bold, italic, or headers and instead shows something closer to what people would want to see rendered (except while typing), would like a similar treatment for the double CR needed for paragraph breaks.
If the user wants the break even bigger, can re-use the current Paragraph Spacing setting. No new setting needed. By default, Bear could just pick a vertical spacing for this Markdown style that looks good, less tall than a full paragraph line, as they do for all the other Markdown-isms.
I still find this to be an unusable feature unless you started using it the first time you used Bear. And if you are using it, it seems you wouldn’t be writing per the Markdown spec of two empty lines, opting for a single line break instead.
I did some further testing as well and realized that there is no difference between a line break and paragraph break in Bear.
Still seems like @shop’s solution or mine (two new lines render as the paragraph spacing setting) would be an improvement.
Side note, it looks like the Line Height setting from 1 em – 1.3 em doesn’t do anything (as of v2.1.4).
To me, Bear is a note taking application that accepts Markdown, but it is not a Markdown editor like Typora is, where the files are stored using Markdown and that is transparent.
Bear stores its data in a SQLite database. You can export to Markdown, this is different. You can also export to PDF.
So, whatever Bear uses to represent paragraphs in the interface, it is up to UX design in my view.
I also use paragraph spacing because two CRs look too tall for my taste as rendered today. If you look at LaTeX parskip package, that is the gap between paragraphs that I’d expect.
However, what should happen is that paragraphs in Bear get exported to paragraphs in Markdown, when exporting to Markdown. That is not happening, and I do believe this is not correct.
BTW, in Typora, which is truly Markdown, paragraphs are also entered with one ENTER in the UI.
The reason for this I suspect is convenience. In these applications, you do not hit ENTER for new lines, because the application wraps the text for you and a paragraph is entered as you’d enter a long line in a text editor.
So, what’s the point of two CRs at the interface level? You just hit ENTER to finish the paragraph, and the UI adds a gap that indicates that visually.
Then persistence or exports are responsible for Markdown correctness at the file level.
