Paragraph Spacing?

Ulysses just has a paragraph spacing option, same as Bear 1, not what I suggested in my above post.

edit: I get you what you mean about lists though. It could prove problematic for them. Ah well, it was just a thought.

1 Like

As I wrote: then the note is exported to docx there IS a paragraph. So what is the problem at all? I want to understand the problem that exists now but didnā€˜t exist in bear 1.

What does that Problem have to do with paragraph spacing just visible in bears editor? I didnā€˜t care if that feature is called ā€žline height after line breakā€œ. Is that a joke that bear 1 told us all the time there is a paragraph (by the name of that option and by placing a paragraph between line breaks on export) and actually never there was NEVER one but just a line break. Sorry, thatā€™s not funny anymore to be mislead and then to be told about the holy rules of markdown

I donā€˜t see a problem. Just do not show a spacing as they are considered as an unit. If I can fold them then they are not separated elements which require spacing

Your problem with that is easy solvable: just donā€™t use the option and use two enters to create a paragraph. But how should i solve my problem? Either i had to live with unreadable text or after decades of writing with the unnatural usage of two enters to create a paragraph or with deleting each empty paragraph in exported docx.

The most absurde thing about this discussion is that actually only the tech safe markdown guys really are concerned about paragraph spacing although they definitely know how to solve that problem and whereas the rest of us normal people donā€™t care about the dogmatism of markdown

1 Like

I meant in relation to my thoughts about having two options for ā€œEnterā€, not an option for paragraph spacing. Anyway, at the end of the day, I agree with you. Iā€™d like to see the option of paragraph spacing added back into Bear.

1 Like

The last thing Iā€™m going to say here.

Bear should be a tool capable of all sorts of writing. Itā€™s impossible for the devs, or anyone else, to imagine all the different kinds of writing that it will be used for. Itā€™s by far the safest and most reliable solution to make what you see in the editor as close as possible to what is actually in the underlying document, following a clear standard: commonmark. Thereā€™s no ambiguity over showing bold text as bold and italics as italic or headings as different sizes instead of showing the underlying markdown syntax.

Paragraph spacing is different. Is there space below a paragraph because I pressed the return key twice, or because I pressed it once and space was added? Itā€™s ambiguous. Is there no space after items in a list because I used single return presses or because the editor removes white space for list items and I have pressed return twice? What about documents where I have used single return presses and double ones deliberately (e.g. for lyrics). Does the editor preserve what I have typed or does it add space to single returns and does not for double returns? When I take that document as a file to another app, I canā€™t be sure what will happen and I might end up having to edit rather than being able to know I can produce what I wanted by typing it.

As Matteo said, this stuff is complex. You can program an editor to display text in a wide variety of ways, but there are so many possibilities for the spacing people might want, for all kinds of
valid reasons, that it is much easier, and semantically much less ambiguous, to follow the commonmark standard and let people add what space they want as blank lines, manually. Doing anything else privileges some kinds of writing above others and I think thereā€™s little justification for that.

Iā€™m quite happy for the Bear team to do what they think is right. Itā€™s their app. As I said, though, on balance, I think it would be better not to add paragraph spacing. It ends up causing more problems than it solves, and I say that as someone who was a professional writer and directly involved in publishing for many years (now retired). Keeping it simple, unambiguous and to a published standard is always better. I lost count years ago of the number of hours Iā€™ve wasted having to do things like correct all the line breaks in an authorā€™s book manuscript into proper paragraph breaks etcā€¦ etcā€¦ (And thereā€™s a special place in hell for authors who put hard line breaks at the end of every line theyā€™ve typed or insist on two spaces after a period)

I understand why people want to preserve their habitual work flows but if devs canā€™t change things that caused problems, thereā€™s no point in developing a new version.

It doesnā€™t break any standard of common mark to add that spacing, as it doesnā€™t break a standard to remove markups or to show some marked elements of the text in different colours. These are additions just visible in the editor

I and others are not talking about abstruse kind of writings. Just normal simple writing of text larger than an atomic note and such stuff. Your argument gives the appearance as that kind of writing is a extravagant niche scenario. It is not.

Definitely there is NO ambiguity because in no good typography the paragraph spacing is the double of line height. You can easily distinguish between two enters and one enter.
Because of that just a checkbox as an option is better than a slider


It is easy to see the difference. No ambiguity. Should i mention that anyway you wonā€™t see these two different spacings in one note because each of them is related to a different setting of the option?

Only people who know better not to use paragraph spacing see problems - problems they do not have. It is techie dogmatism that separates them from the dumb ones. I am dumb in regard to such stuff. Do you know what confuses me? I hit two times enter and when i place the caret back into the real paragraph spacing i see a bigger caret that tells me: ā€œHi, i am a real paragraphā€ And thatā€™s absurd: if i can place a caret between two paragraphs then there is a third (blank) paragraph. Therefore after export i see two paragraphs. THIS is confusing and against expectations of normal human beings. Bear is treating a line break as paragraph - why at all? Probably because the app assumes that almost all users mean ā€œparagraphā€ when they hit one enter-key. I do not see any good reason from an users point of view not to add paragraph spacing AND on export to remove empty paragraphs if someone uses double enter for paragraphs

1 Like

My working process is that I export from Bear as a word file, then import that word file into Vellum. If I hit enter twice every time to create a new paragraph, that means I have a load of blank lines in my word document which I need to remove before importing into Vellum.

With paragraph spacing, I donā€™t have to hit enter twice, making my novel more readable, and I also donā€™t have any blank lines when I export which Vellum happily imports and turns into an ebook and paperback in three seconds flat. Unless there is a way to somehow remove blank lines as part of the export from Bear?

Anyway, Iā€™ve reduced paragraph spacing to zero in Bear 1. Itā€™s not ideal, but if I zoom in on the page using command+, itā€™s readable. I can live with it, albeit reluctantly.

Search and replace two blank lines for one in any text editor (including Bear and Word) takes at most a few seconds ā€¦

1 Like

Why is there at all blank space, means: a blank paragraph, in exported notes between two other paragraphs, although you was meant to add just ONE new paragraph by two times enter? The export apparently bases on what the general users expect when he hits one time enter: a paragraph - he gets what he meant! That is totally confusing and unintuitive.

Why save an option in editor settings just to create an other one at a different place? :wink: If someone can tell me what problems you run in IF paragraph spacing is NOT enabled I would rethink .

A blank line as indicator for a new paragraph is web style. In typography outside of web, blogs and so on nobody would use such a high spacing for paragraphs.

Doesnā€™t matter. As I mentioned earlier in the thread, hitting enter twice when writing a long form piece of creative writing breaks my flow, especially if itā€™s quick flowing dialogue, and Iā€™m doing it every two seconds. So Iā€™ll take the visual hit in the editor (visually Bear gets everything else right, so weighed against that, I can live without paragraph spacing) and just press enter once after each line. Then I donā€™t have any messing about when I export either.

Hello folks,

the conversation here is becoming a little unruly, please be kind to each other :slight_smile:

Everyone has different ideas and needs, and this is one of the biggest challenges in building a good app. Paragraph spacing is a tiny feature that still generates a lot of discussions, try to think about the effort needed to build the whole app.

Back on the topic: we can reintroduce paragraph spacing (and probably will), but there will be trade-offs, due to how Markdown works.

We can apply paragraph spacing based on the syntax or based on the semantics of the text.

  • Syntax: would make every text followed by a newline (\n) a paragraph, this will add the spacing after every title, line of text, list item, etcā€¦ (code will be the only notable exclusion).
  • Semantic: would add the spacing only after what Markdown considers a paragraph.

Iā€™m inclined to use the syntax approach, as the notes are more often read inside Bear even if this is going to be a little weird/inconsistent on some exports.

The feature will be off by default, so it wonā€™t cause any issues for people who donā€™t want it. Weā€™re usually wary of adding settings for a small subset of users, but weā€™ll probably make an exception to this just because we had it in v1.

Let me know what you think.

1 Like

I do not really understand what is meant with the semantic path. Do you mean that two ā€œenterā€ would not lead to a blank line but to the spacing defined in editor settings? That would be indeed a confusing feature in my eyes. I must admit that there must be a point which i do not understand really and that lets my comprehension suffering. In bear 1 it was that i got what i meant when i exported a note to docx. Or another point that confuses me: on export i do not see the line break if i create a linebreak in bear with ā€œshift + enterā€. I think i do not understand really the difference between a hard and soft line break - i considered the first one as paragraph because it was interpreted as on on export

Most likely it was not only, but above all, my tone that made everything a little unfriendly. It was a symptom of despair and frustration: i wouldnā€™t leave for missing paragraph spacing now but on the other side i would never have switched to bear 1 one and a half years ago if it hadnā€™t paragraph spacing

I am sure that the subset of users i belong to is not that small. Actually the expectations to typography vary depending on how old you are, from which country you come and which reading sources you are used. In my case if i read or write something in bear it is - for me - more like reading from paper than in web where the blank line is usual for seperating

Do you mind giving one or two examples? I just would like to understand the problem as it might be that i am biased because of my use case

What should i say? Hooray! :tada: And thanks for considering a feature that maybe is not important for the most, but for a quite few users is fundamental. I think the syntax path is the right way. I said in another post that spacing should not be applied to footnotes and lists but that could lead to confusion when the same key produces different results.

I would prefer the Syntax way, probably how B1 did it too right?

Can I ask about how it works with headings? Currently when I make e.g. a H1 heading followed by Return and then body text, like thisā€¦

# Heading 1
Some body text here.

ā€¦Bear applies, I think, a larger line height between the heading and the body text. It looks like thereā€™s more spacing after the heading than normal line height in a paragraph of text. Now if I increase the paragraph spacing from the default value, would this ā€œheading spacing multiplierā€ increase even more?

Letā€™s say a H1 heading has 1.5 Ɨ the normal line height, and I increase paragraph spacing by 20%, would the spacing after the heading be Ɨ 1.7?

No, it would mean that only 1 enter between two lines of text would not apply the paragraph spacing between those, as itā€™s not a paragraph in markdown.

A soft line break break a line of text without starting a new paragraph. Visually itā€™s the same, but the underlying text is different. This is a good explanation:

Hard returns are used to signify the end of a paragraph, whereas soft returns simply signify the end of a line

I usually suggest to not use soft line break unless youā€™re 100% certain that you want one :slight_smile:

Everyone is sure about something, I can only say that we donā€™t get a lot of questions or support request about the typography options.

1 Like

Correct.

Correct again, but we could disable the automatic paragraph spacing for headers if you enable the one in the preferences, I need to think about this.

1 Like

I think we mean the same: two enters would create a new paragraph and therefore you donā€˜t see a blank line between two paragraphs but space defined as paragraph spacing even if a little bit smaller as blank line?

Just to be sure that I got it: when I type ā€žshift + enterā€œ in bear or another markdown editor I get a soft line break whereas the same hotkey in MS Word leads to a hard line break? If so then following might be what complicated my comprehension: bears export to docx changes the underlying text and transforms a soft break to a hard break, a hard break to a paragraph and a paragraph to two paragraphs? Right? If not I will give up to understand :grin::wink:

Because everything went fine and without breaking expectations in bear 1 with paragraph spacing :stuck_out_tongue_winking_eye:

I still think it would be better not to reinstate paragraph spacing. If you do decide to do so, please keep it really simple - if an option is on, just add some white space whenever enter is pressed (your syntax approach), so it is displayed in the editor but does not interpret or alter the underlying markdown at all.

The issue of layout, typography and spacing in exports is much bigger and for after Bear 2.0, but Iā€™d vote for paragraph spacing NOT to be applied to at least markdown exports. Thatā€™s where the ambiguity can do the damage.

Maybe it was an misunderstanding. I didnā€˜t ask for changing of underlying text but just to add spacing which even cannot be confused with a blank line as the spacing would be smaller than a whole blank line (see screenshots). I even asked for a simple check-option rather than a slider. I think as long as the option is not enabled by default we all can be happy

1 Like

Unless Iā€™m mistaken, I donā€™t think anyone who wants paragraph spacing has argued against that. I would certainly want it to be only a visual thing in the editor itself. It would be like, say, altering the line height is purely visual.

If Iā€™ve said anything out of turn, I apologise. I donā€™t want to appear hyper critical over paragraph spacing, as I love everything else about Bear. All the new stuff youā€™ve added in Bear 2 is fantastic and makes it a really viable option for long form writing, maybe more than some people realise. I think youā€™ve moved beyond simple note taking and I would definitely recommend Bear above apps like Ulysses. I honestly canā€™t go back to anything that works with folders or groups now. Iā€™m a total tag junkie. :grinning:

1 Like