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 (§ whose `next` method...
  2. Highlight "[[Enumerate]]" and link it to http://example.com?1

    So far, so good.

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

You'll find that "[[Enumerate]]" is now linked to http://example.com?2 (as is "§"), 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 ([§][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.

  • Replicated in Opera 12 as well. Btw, you don't even need that first link, linking alone the thing in brackets and then linking something else (anywhere in the markup) will break it.
    – Bergi
    Dec 11, 2015 at 12:38

2 Answers 2


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.

  • Great, thanks. I'm not up on the update cycle on SE, when should we expect this to be live? Dec 11, 2015 at 13:35
  • Eh, it's the only pending change since the previous build. I'll just deploy it right now, should be live in about 5 minutes.
    – balpha StaffMod
    Dec 11, 2015 at 13:37
  • Works a treat, thanks! Dec 11, 2015 at 13:49
  • Any chance we could get some love on Stack Snippets, this issue in particular? I offered to help, gratis, via email but never got a reply from the SE team. Dec 11, 2015 at 13:50

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 ([§][2]) whose `next` method...

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .