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?
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:
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?
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!
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!
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:
Paragraphs
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.
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.
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.
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