What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 134 Stack Exchange communities.

I was editing a tag wiki, and I have noticed that in some cases, when I select text to make it a link, the text that is converted in a link includes characters that were not selected.

For example, if I try to convert [this inline link](http://example.com) in a link, I get the following result.

  • I delete the parenthesis, cut the URL, and delete all rest of the text to the right of the text I want to use as link text.

    screenshot

  • I select the text that will be the text link.

    screenshot

  • I click on the button to create a link; and paste the URL in the dialog box that appears. When the dialog box is closed, this is the result. The character to the left of the selected text is included.

    screenshot

if the character to the left is included to be escaped, that is not necessary, as I could have an open bracket to the left of the Markdown markup for the link, and it would be correctly parsed: [screenshot.

This happens also when you change in a link a word that is followed by a closed bracket, as in the following text:

[Reference: myself]

The expected result would be <sub>[Reference: [myself][5]]</sub>, while the actual result is <sub>[Reference: [myself\]][5]</sub>.

In this case, I highlighted "myself" and clicked the button to change it to a link.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Being 3 years old and only having 3 upvotes, I think it's unlikely that this issue affects many people many times. There's also an obvious workaround: "don't do that."

share|improve this answer

In the general case, the editor checks for surrounding brackets because if you select just text within a valid reference link syntax ([text][#]), clicking the button is meant to remove it.

It determines if this is the case by calling .findTags() on the chunk representing the selection, and then examines .startTag and .endTag to see if there was a match for both. When there's not, the code (perhaps mistakenly) decides that it should pre/append those values back into the selection text.

Since these values can come from the original selection and the end/beginning of the chunk's .before and .after content, respectively, that doesn't necessarily seem like the desired behaviour. As you've observed in your case, doing this expands your selection to include the leading [, even though it wasn't part of what you had highlighted.

Once the brackets become part of .selection, the later processing considers them the full link text and escapes them as would be appropriate had you intended for them to be included.

The chunk prototype could be modified easily enough to include a reset() method that would allow restoring the original property values in this scenario, but I'm not sure if it would have any other unintentional side effects. If there's more support for this use case I'm willing to mock something up and test it more thoroughly.

share|improve this answer
    
Old bug, but I'm going to hash out that this is not seen often enough to try to fix anything ;-) –  jcolebrand Jul 21 at 15:07

You must log in to answer this question.

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