Description

Automatic http-links are not terminated on a right parenthesis if the parenthesis is followed by a comma, a full stop, a semicolon, a colon, or some other non-whitespace character.

Example

1. right parenthesis is included into the URL, but not the trailing character (,.;:?):

    Use the URLs specified in RfC 2606 (http://www.example.net), if you want to make examples.

   Use the URLs specified in RfC 2606 (http://www.example.net), if you want to make examples.

2. right parenthesis is included into the URL and the trailing character, too (alphanum+&@=$):

    Use the URLs specified in RfC 2606 (http://www.example.net)F if you want to make examples.

   Use the URLs specified in RfC 2606 (http://www.example.net)F if you want to make examples.

3. right parenthesis is not included into the URL (trailing whitespace):

    Use the URLs specified in RfC 2606 (http://www.example.net) if you want to make examples.

   Use the URLs specified in RfC 2606 (http://www.example.net) if you want to make examples.

Component selection

Details

Workaround

Add white space, or put the link into brackets (i.e. ([[http://www.example.net]]), ).

Discussion

Regression: This used to work in MoinMoin 1.5 (cf. WikiTippDesTages).

InterWiki links do not seem to be affected.

This issue should be solved until MoinMoin 1.6 stable release as it could lead to broken links in contents only by updating the wiki software.

Standards involved: RfC 2396.

See that other bug report / feature request complaining about links ending at ) ...

• Which one of the 500 pending bug reports and feature requests? And speaking of thoughtless comments: Did you notice that sometimes the right parenthesis is included, sometimes not, and sometimes the trailing character is included, too, and sometimes not? -- MartinBayer 2007-11-17 22:41:15

Should be merged with MoinMoinBugs/ParenthesesBeforeDot and a suggestion for solving this should be found. Maybe only dropping free urls in favour of double-brackets-only solves this.

• Not going to merge with a closed/fixed issue. However, instead of dropping free links syntax completely, which would be an other syntax change that potentially breaks the functionality of existing pages, the best thing to do would be to require that links containing certain characters—including parentheses—are put into brackets, or have these characters escaped.

Proposed behaviour

1. A right parenthesis terminates a free link. I.e.

    Use the URLs specified in RfC 2606 (http://www.example.net), if you want to make examples.

   is rendered (space included only for demonstration)
   Use the URLs specified in RfC 2606 (http://www.example.net ), if you want to make examples.
   (as it was in 1.5 - this fixes the regression).

2. A right parenthesis is included if the URL is put into double brackets. I.e.

    Use the URLs specified in RfC 2606 ([[http://www.example.net)]] if you want to make examples.

   is rendered (using the hypothetical TLD .net) for demonstration)
   Use the URLs specified in RfC 2606 (http://www.example.net) if you want to make examples.
   (already implemented)

3. Else, a right parenthesis is included if it is escaped in the URL. I.e.

    Use the URLs specified in RfC 2606 (http://www.example.net%29 if you want to make examples.

   is rendered (using the hypothetical TLD .net) for demonstration)
   Use the URLs specified in RfC 2606 (http://www.example.net%29 if you want to make examples.
   (already implemented)

Note this would solve the problems described above in the examples A and B, leading to conformity with InterWiki links, while still offering the possibility to use unreserved characters in links without too much trouble (with brackets). I think we have enough use cases for free links in parentheses, just think of all the cases where a user does not want to use a named link, e.g. the [[http://w3.org|W3C]], but an explicit link, e.g. the W3C (http://w3.org).

Plan

• Priority:

• Assigned to: ThomasWaldmann

• Status: fixed for the usual cases by changeset http://hg.moinmo.in/moin/1.6/rev/7dea2ec3a1fc, parsing interwiki links in the same way now. The problematic cases can be worked around easily by using [[...]] or surrounding with blanks.

CategoryMoinMoinBugFixed