Extra line after last list item when adding a paragraph below

Testing version: Versión 2.0 (11015)

What were you doing: Trying to make the next paragraph to start just after the last list item, without indentation at the list level.

What feature did you use: list and paragraph

What happened:Trying to make the next paragraph to start just after the last list item, without indentation at the list level.

What did you expect to happen: I expect I can start the next paragraph just after the last item of the list without an extra line and without indentation to the list level. That’s hoy Bear 1 worked.

That is markdown specification

1 Like

So that’s why I couldn’t do that!

This seems to be a common question.

I don’t get this to be in accordance with markdown spec since it doesn’t happen when the next text line after the list is a Header.
In that case no extra line is added.
I’ve never liked to have to add extra lines to separate paragraphs in Word or any other text editor. That should be an style implementation detail (line spacing rendering after a paragraph end)

Maybe this should be an option that you can toggle on and off in settings?

I am a new user and had this exact same issue. Bear is a great app - this is the one thing that stands out to me as being wrong. Are there any plans to fix it? To me this is a bug - I’d be surprised if this was standard Markdown behaviour, and if it is there should be a way around it. The result looks rather odd.

I would regard that commonmark compliance even as a useful feature: we can create paragraphs inside one bullet. Actually i don’t want to miss it.

It is not a bug, but part of the the specification, and it is only when having a paragraph inside a list or block quote, and you want to write another paragraph below. Then you need this extra line. That being said, we know that it is confusing and we are making som adjustments to nudge people to understand what is going on.


Hello, is it a markdown specification, or a commonmark one ? It wasn’t the case with Bear 1, and it’s not the case with other markdown note editors. In any case it’s a doubtful specification : it prevents the user from getting what he/she exactly wants.

It is part of the CommonMark specification. To my knowledge, that is the only proper specification with a comprehensive test suite. Following the standard makes it easier to share the markdown with other tools that follow the standard, but it also gives you less flexibility on how you want things to work. Outside of CommonMark, there are a plethora of dialects that often share some features but diverge on others.

We want to follow CommonMark to benefit from the standard, but we diverge from it where it causes more problems than benefits. This is a balancing act, and we are learning and improving from user feedback.

Bear 1 had a fully custom markdown, and Bear 2 has moved closer to the CommonMark standard. We are aware of the blank line issue and looking at solutions…