Square brackets incorrectly render as link

Beta Beta Bug Reports
1

Testing version: 0.1 (2595)

What were you doing: I was editing quotes from a book and using the common convention of square brackets to indicate text added/changed from the original. For example, “[Merry] loved mountains, or he had loved the thought of them marching on the edge of stories brought from far away”.

What feature did you use: Just writing.

What happened: The text in the square brackets (“Merry” in the above example) was rendered as a link (to nowhere).

What did you expect to happen: The text in brackets should have rendered as plain text with the brackets included. If I’m reading the CommonMark spec correctly, text in square brackets that is not followed by parentheses or square brackets should only render as a link if there is a matching link reference definition elsewhere in the document (this was not the case).

2 Likes
2

Hi Janne - I suspect this is a bug introduced into the latest version of Panda. Prior to this release, putting single square-brackets around text did not result in a link - it functioned exactly as you’d expect. It looks like this current version is interpreting [bracketed text] as something akin to a footnote. If you click the link, you’ll see a new footnote created at the end of your text. Proper markdown footnote syntax is [^1]. So as I say, I suspect what you are experiencing with [Merry] is a bug that will soon be fixed.

@TedwardBear ^

3

I’m seeing this as well.

4

If I understand the vision for Pandas correctly, then it will be a fully common-mark compliant editor with some Github flavour. The [foo] turning into a link is expected behaviour given the spec see (GitHub Flavored Markdown Spec). It is different from the [^foo] syntax because the former is a hyptertext link that will open a browser (or a the relative url-handler) whereas the latter is a footnote, it will navigate to the position where the footnote is specified.

If you want a simple bracketed you may do \[foo]. See GitHub Flavored Markdown Spec for reference.

1 Like
5

According to the spec, bracketed text should only render as a link if there is a matching reference link definition elsewhere in the document.

For example, try the following in the Commonmark reference implementation:


[This one] is a link because it has a reference definition below.

[This] is not a link because it doesn’t have a reference definition.

[This one]: https://community.bear.app
6

Good observation.
I would still argue that it is expected.

  1. Bear and Pandas are editors not a viewer.
  2. currently the [^foo] footnote syntax turns immediately into a link and upon clicking creates the corresponding [^foo]: footnote
  3. By analogy [foo] is rendered as a link, which has not yet been populated (as Panda is an editor).
  4. To make the two equivalent the current behaviour I would argue is expected. And makes the feature more discoverable.

I would argue that if is ok for [^foo] to autogenerate a footnote then so should [foo].

Note I am a random user on the Internet and not the Bear design team. :slight_smile:

7

I think you’re right that it comes down to expected UI behavior, rather than spec conformance. Personally, I would prefer square brackets to be left alone unless followed by parenthesis for two reasons:

  • By default, Bear does not use the reference link notation in its Markdown output, opting instead for inline link notation
  • Unlike footnote notation ([^…]), reference link notation ([…]) sees frequent legitimate use outside its use in links
1 Like
8

Hello there Janne,

I can see that this is your first time posting on here, so welcome to the community!

This falls under the age old question, is this a bug :bug: or a feature? :thinking:

@sitacuisses was correct, this is in fact expected behaviour and is a feature.

This is as it’s part of the CommonMark specification. A single word inside [] is a link reference, it should be paired with the link definition (which is usually at the end of the note).

Currently, we’re marking that as a link because clicking on it auto-creates the definition.

The current UX however is not ideal because it’s annoying if you just want text inside parenthesis.

Therefore, we’re working on changing it to highlight only if both reference and definition are present in the text.

Hoping this answer helps, but if you’ve any other queries or questions please do let me know!

1 Like
9

Sounds great. I like the proposed solution!

3 Likes
10

Glad to hear that Janne!

11

When will this UX improvement arrive with Bear 2.0 to advise this requirement to format differently? I have just encountered this issue with anything I put in a square brackets when exported to PDF or DOCX is converted to a Hyperlink with no reference. I have thousands of notes impacted by this issue. Also have posted amother issue where if you use [square brackets] within tags these don’t work either. Refer Upgrade to Bear 2.0 [Square Brackets] Don’t work in Tags - Bug Reports - Bear Beta. I broke the IT rule of not using special characters, however when you use bear as an editor without syntax correctly you often forget.

To assist with me correcting this Feature/Bug. AFAIK the search and replace only works within a single note with Bear, do you recommend an approach to searching and replacing thousands of notes that contain [text] within the note and also within the #tag#[sub-tag-with_square_brackets]#sub-sub-tag-without_square_brackets# :slight_smile: I have a support case open, but its been noisey crickets since Bear went GA. :pray: