Editor breaks old links when adding new ones with Ctrl+L, if existing link text has square brackets ([])

Question

When adding a link with Ctrl+L or the link toolbar button, it can break other links elsewhere in the text, which is obviously quite a problem as the person adding the new link will probably only check their new link, not the old ones.

To replicate:

1. Paste this text into a question without the pre:

   `for-in` loops iterate according to `[[Enumerate]]`, which returns an Iterator object (§25.1.1.2) whose `next` method...

2. Highlight "[[Enumerate]]" and link it to http://example.com?1

   So far, so good.

3. Highlight "§25.1.1.2" and link it to http://example.com?2.

You'll find that "[[Enumerate]]" is now linked to http://example.com?2 (as is "§25.1.1.2"), instead of its original link to http://example.com?1

E.g., you end up with this:

`for-in` loops iterate according to [`\[\[Enumerate\]\]`][1], which returns an Iterator object ([§25.1.1.2][1]) whose `next` method...

  [1]: http://example.com?2

Probably not browser-specific. I've replicated in recent Chrome and Firefox (haven't tried others), Bergi replicated it in Opera 12.

Doesn't matter whether [[Enumerate]] is in backticks or not (no reason it should, just saying it doesn't).

Possibly related to this bug with images.

Answer 1

Fixed in the next build, thanks for the bug report. When modifying links, the editor used a pretty ugly regex – this one, to be precise:

(\[)((?:\[[^\]]*\]|[^\[\]])*)(\][ ]?(?:\n[ ]*)?\[)(\d+)(\])

– to look for things that mostly look like they should possibly maybe pretty please be [foo][42] style link references. It broke on your markdown because it got utterly confused by the fact that your link text itself also contains square brackets.

Fortunately I recently made a change where we no longer have to hope that the regex catches only valid links, because for everything it finds we can now actually make sure that it's really a link.

With that, the regex doesn't have to be complicated anymore – it can be very liberal, and anything it finds that is not actually a link will be filtered out later. So I've changed it to look for everything that is a number between square brackets, and with that, your markdown would've worked just fine.

Answer 2

This is weird. While the bug is being fixed, you can use an inline link as a workaround:

[`for-in`][1] loops iterate according to [`\[\[Enumerate\]\]`](http://example.com?2),
                                                              ^^^^^^^^^^^^^^^^^^^^^^
which returns an Iterator object ([§25.1.1.2][2]) whose `next` method...

  [1]: http://example.com?1
  [2]: http://example.com?3