What were you doing:
Making a note that consists of some headers, text, and list items
What feature did you use:
markdown headers, lists
What happened:
I have a small note something like this:
### Foo
Look at this list of foos
* Foo1
* Foo2
### Bar
Look at this list of bars
* Bar1
* Bar2
When you copy/paste this into Bear it all renders great. However, when you are manually typing this into bear you hit this very awkward interaction after you hit enter after * Foo2
Bear very reasonably assumes you want another list item. That isn’t what I want, as I want to start a new top-level header that is aligned to the left margin. So, I hit backspace, and the list item is deleted. Cool…closer. But, if I started adding the header here it will be indented under the list item. That isn’t what I want. So, my intuition is to hit backspace again to get all the way back to the left margin. But, hitting backspace again takes up back up to editing the prior list item. You are left with a couple of funky options to get what you want:
Hit backspace to remove the new list item, hit enter to get to a new line all the way to the left margin, add the header, delete the extra newline that was added so your new header directly follows the prior list item.
or
Hit backspace to remove the new list item, add the header (which is now indented under the prior
list item), move your cursor to the left of both the new header and the three line header icon (as shown in the below picture) and hit delete to force the header to move back to the left gutter.
What did you expect to happen:
Some more intuitive way to add a new header after a list item that didn’t feel so quirky. Using each of the samples above, I might have expected:
Maybe hitting the backspace would first remove the presumed new list item. Hitting backspace again would take me back to the left-most margin. And, if I really wanted to get back to the list item I can hit backspace a third time to go back up a line.
Maybe “outdenting” with shift-tab could could intuit that I’m trying to get rid of this indentation under the list item and move the header to the left.
I agree. I’ve run into this “end of list” behavior and agree it’s unintuitive. I end up struggling to get Bear 2 to behave as expected. I think part of the problem is that Markdown expects an empty line after a list. Headers may override it, but any text on the line immediately following a list is presumed to be text on a new line that is part of the last list item. You can see the same behavior in an online markdown editor like stackedit.io.
I think part of the problem is that Bear 2 is rendering these two cases (empty line following list present or absent) differently:
* Foo1
* Foo2
### Bar
* Foo1
* Foo2
### Bar
In other markdown editors (like stackspace.io), these two cases render identically (i.e., the spaces between the list and header is the same in both cases, whether or not an empty line follows the list in the markdown); however, Bear 2 renders the first case without an empty line and the second with one.
In the end, you could get the behavior you’re expecting by pressing return instead of backspace. That is, pressing return on the line following Foo2, then type ### Bar and you’ll get your unindented header with an intervening empty line.
But, I agree with you. Personally, I’d like to be able to avoid the extra empty line between lists. But it could add to confusion when the text you’re trying to put after a list isn’t a header.
I 100% noticed that as well. Where I notice it even more is when you want a non-header following a list item. I used a header in my original example since that one is at least a situation where Markdown/Bear permits the content to be placed immediately after the list item (i.e. no extra newline is required). But, when you are dealing with non-headers that isn’t the case. For example:
Foo:
* foo 1
* foo 2
This is some text
This kind of thing requires that a newline is added, or else the text is attached/indented along with the list item. That behavior seems consistent with other places I use markdown (ex. GitHub). However, that forced extra newline seems like it affects overall spacing the same way you demonstrated above with headers. Here is the same markdown as above rendered in Bear vs on GitHub:
The Bear one looks awkward, with the text having this extra bit of unintended whitespace. I don’t want that extra whitespace, but you can’t avoid it since the extra newline is required to get that text to not be associated with the list. The GitHub one seems to acknowledge that the extra newline is there just to detach the content from the list, and renders it such that the text before/after the list all “looks right”.
@trix180 I was just about to post something similar to this. When trying to “get out of, or leave a bullet list” I struggle trying to do something different from a formatting standpoint. I created a video that shows the problem.
This is a very tricky issue and I don’t have a good solution at the moment. You can overcome the header issue by using the header shortcut instead of typing # Bar but right now we can’t solve the other cases without breaking the list rendering for other test cases.
