Bug: ruled line created instead of bullet item

Testing version: Panda 1.0 (2595)

What were you doing: Write a line. Hit return. Enter a hyphen and a space, which should trigger a bullet item.

What feature did you use: Editor

What happened: Instead of creating a bullet item, it created a ruled line, plus the paragraph above it became huge, like H1 level text, but without the characteristics of a heading.

What did you expect to happen: I expected to have a bullet item (for a list).

This problem does NOT happen if you hit Enter twice, so there’s a blank paragraph above your bullet item. This must be a bug, because going from standard paragraph to a bullet list without entering two paragraph breaks is NORMAL BEHAVIOUR and it seems insane that the expected bullet list item was replaced by RULED LINE AND GIANT TEXT. Please fix ASAP. I make lists frequently and I don’t want to have to remember to hit Enter twice before creating a list!

Update: the problem does NOT happen if you start a bullet list immediately after a heading. It only happens when you start a bullet list after a regular paragraph.

I’m a bit surprise there’s no reply to this. It’s a problem because creating bullet lists is really normal behaviour, and you don’t want to force the user to remember to go fishing through the formatting menu when “hyphen space” is pretty much a universal shortcut for starting a bullet list.

Here’s a GIF of this problem in action:


Hadn’t noticed but now I gave it a try it’s super annoying.

Making the link above bold is perhaps related to this bug: A Tag Followed by and Underscore Becomes a Header (I totally meant hyphen not underscore. :smiley: )

While in that thread I assumed it was related to to tags, but no it’s just anything above a hyphen, and now it breaks if you just do one hyphen. Looks like it’s still a bug in the updated editor.

Hello there,

this is not a bug, it’s an expected Markdown feature.

However, I agree that’s something not very intuitive and the experience is not great. As we’ve switched to our custom Markdown parser we can customize it as we want, so we’ll probably turn off this feature for Bear.

It will probably remain in Panda, as we want it to be as much as compatible as possible with other editors.

1 Like

I’m not sure I follow when you say “we’ll probably turn off this feature for Bear.” I’m a regular Bear user and have never had this problem in Bear, so it is not “on” there.

Also, that markdown specification makes my head spin, and I cannot follow it at all, and I don’t see how it’s relevant here. Simply following a line of unformatted text with a bullet list (triggered by a hyphen and space) does not seem to have anything to do with the description of setext headings you linked to.

I’ll be really sad if it stays like this. Bear is the best notes app I’ve ever used (it fits my needs perfectly and I really enjoy using it) but I make bullet lists ALL THE TIME and this is the kind of annoying thing (must remember to insert extra space, or must remember to start with a heading, or must remember to use the markdown menu instead of the otherwise universal “hyphen space”) that will totally ruin the experience for me in Panda. :frowning:

Could you also customize it such that putting a word or phrase in single brackets does not auto-create a link? In traditional writing, brackets are often used to provide additional context within a sentence - particularly within quotes. Or, if that were an optional user-setting, that would be great. Otherwise, needing to escape every one of those left brackets would be pretty frustrating.

Hi Blork - he’s referring to the case of when the Panda editor is incorporated into Bear proper (Bear 2.0). At which point, it sounds like the dash / hyphen will not cause the auto-H1 formatting that you’re seeing Panda today.

Ahh, OK. If that’s what he meant then great! Problem solved!

I think this is a bug since the OP has not put three dashes but instead one.

Yes! I suppose that’s why the spec wasn’t making any sense to me; it specifies THREE HYPHENS to create a ruled line (and I still don’t understand that kinda-sorta heading that appears above the ruled line; it looks like H1 but doesn’t behave like an H1) whereas the problem I’m reporting is a SINGLE HYPHEN triggering both the ruled line and that faux heading.

There’s no way that is expected behaviour. @matteo, please take another look at my bug report.

Hello again!

Please trust me when I say that’s an expected behavior :slight_smile:

I’ve already linked the markdown specification, but I understand that those are hard to read: the rule for a Setext heading says that any line of text followed by any number of - or = is a header. So yes, writing a - just after a paragraph is making the text before it a header → example.

We render Setext heading with a separator underneath to mimic the syntax (and to differentiate it from the other headings):

Setext heading

Even if that’s the correct way to implement the markdown specs we agree that’s not an idea user experience. The new editor inside Bear 2.0 will not render Setext heading.

Panda on the other hand will still have them as they are part of the standard.

Let me know if this make sense for you.

Yes! We’re working on that as I’m writing this.

We’re experimenting with a couple of different approaches:

  1. trying to render single brackets text as a link only if there is the counterpart definition (which is not trivial as it sounds).
  2. removing support to this feature completely

We’re still not sure what’s the best solution, but either way, this should solve your issue.

1 Like

The section of the CommonMark spec you’ve linked to seems to suggest that this is not the expected behavior:

If a line containing a single - can be interpreted as an empty list items, it should be interpreted this way and not as a setext heading underline.

(Found as the last line of the second paragraph under 4.3 Sextet Headings.)

Additionally, has the accessibility of adding a separator underneath the sextet heading been considered, most especially for folks using screen readers? Horizontal rules are semantically meaningful and, in HTML, come with the implicit ARIA role of separator for this reason (see <hr>: The Thematic Break (Horizontal Rule) element and the WAI-ARIA 1.2 definition of the separator role). I suspect this semantic significance is the reason why, in the CommonMark spec, sextet headings don’t include a separator when converted to HTML.

1 Like

Yes! See, that makes sense to me:

If a line containing a single - can be interpreted as an empty list items, it should be interpreted this way and not as a setext heading underline.

Interpreting a single hyphen as a heading and a ruled line just seems weird, and does not seem like something the spec would promote.