One thing I noticed since early versions: When making a bullet list, and I hit ‘Enter’ after an empty bullet in order to write ‘normal text’ after the list, an empty line gets inserted between the last bullet and the ‘normal text’. If I delete the empty line, the ‘normal text’ will be indented to the position of the text of the bullet. If the cursor is before the ‘normal text’ and I then hit ‘tab’, the ‘normal text’ will be transformed into something that looks like a code block without being a code block. Here is a video: https://youtu.be/YBRIj4CM1qc
if I make a bullet, write something, and hit ‘tab’, the bullet won’t indent
similarly, I make a bullet, write something, place the cursor before the bullet point, and hit ‘tab’, the bullet transforms into the ‘code thingy’ you saw in the last seconds of the video
not sure if this is true, but folding seems to be a tiny bit slower than before. Unfolding happens near instantly
I would like if ‘normal text’ could fold bullets that are underneath (visually it would make sense), but that’s probably and understandably not suitable for the markdown code. Anyway, the folding will be the biggest highlight for me
Thanks for the kind words, let me answer some of your questions:
Aside from the tab thing (that’s a bug), the rest is how lists should behave in Markdown. Ending a list requires a white line, so the editor is adding that for you when you hit Enter in a root empty bullet. Text that’s not separated by a while line is considered part of the previous list item, this allows splitting paragraphs inside a list item.
If the bullet is at the first level, that’s correct. You can’t indent the first item of a list (anything indented in Markdown will become a code block).
Same as before, anything indented will become a code block.
I think this could be a “display” issue, the unfolding is fast, but the editor is not displaying it instantly. There are few optimizations to avoid over-drawing, but in this case, it might be not needed.
That could make sense, but atm we’re limiting folding to “block” elements (headers, lists). Most likely we’re going to expand the folding capabilities, but we want to see how people use it before doing that
Oh, this is bad. 99% of the time if I’m making a bulleted list, it’s meant to be indented from the ¶ above it, NOT at the same level as the ¶ above it. (See screenshot below.) It should be up to the user how deeply their first bullets are indented. There are myriad reasons for wanting bullets to start further in.
I have hundreds of Bear documents with this kind of formatting, and I’m dependent on it for several projects in Bear. I hope this can be fixed, because it will render Bear unusable for me.
I don’t know if this is new to (992), but folding seems to hide things that it shouldn’t. For example, in the Welcome Note, if you fold “Important Links,” it hides with it the footnote at the bottom of the page, which should be recognized as a separate entity.
The upshot: If you then follow the link to the footnote (under “What’s New”), instead of being taken to the footnote (because it’s hidden), a NEW footnote is created.
At the moment header folds until the next header with level <=, but it make sense to stop at footnotes (but keep in mind that those can be anywhere, not only at the end of the document). I’ll add this to our list to thing to discuss.
Creating a new footnote when there is already one hidden is a bug, thank you for reporting it
I’m very sorry if this makes Bear unusable for you, but having the editor following a standard is something that we consider a good thing.
I’ll have to find a work-around somehow. I have way, way too many in-text, multi-word tags, and I’ve yet to find another app that can do that. But it’s going to seriously gank hundreds of notes.
Ironically, this does “fix” a previous issue I had with Bear, which was that hitting TAB within a bulleted item further indented the item rather than adding a wide space within the text. In Panda, I can now get that wide space in the text, since it’s no longer up to the user how indented their bullets are. Although, if I remember that discussion correctly, several users pushed back against my suggestion, saying TAB within a bullet should always increase the indent — so I think those people aren’t going to be happy either.
Can you briefly explain YAML front matter, and why it matters or can do for us? Will you implement variables in the notes? That seems really cool, especially if they feed to other notes.
I must re-iterate my insistence on better search. The other day I searched for a term on iOS, and had to literally scroll through actually looking for the highlighted search term in the long note that contained it. This is what computers are supposed to do. The macOS version is not much better, having to Search again, and click through the highlighted terms. There should be a new column with the search results for within the note, displaying the nearest header to indicate the context in the document the search term is.