Markdown URLs with parentheses incorrectly detected

[anjiro]

Markdown links containing parentheses as part of the URL get truncated by wiki#link#get(). For example:

Here is some useful [information](https://en.wikipedia.org/wiki/Capstan_(nautical)) about ships!

wiki#link#get() returns the URL as 'https://en.wikipedia.org/wiki/Capstan_(nautical' - losing the trailing ).

With mid-URL parentheses, the return value is cursor-position-dependent. Given

[A link](https://test.com/A_file_(stuff)_ok.html)

with the cursor in the bracketed text, the detected URL is https://test.com/A_file_(stuff', and with the cursor after the ) in (stuff), the URL is _ok.html.

Vim doesn’t seem to support recursive regex patterns, so one way to fix this is with this hideous construction (source) placed in autoload/wiki/rx.vim:

let wiki#rx#link_md = '\[[^\\\[\]]\{-}\]([^\\]\([^)(]\+\|(\([^)(]\+\|([^)(]*)\)*)\)*)'

and in autoload/wiki/link/md.vim:

 'rx_url': '\[[^\\\[\]]\{-}\](\zs[^\\]\([^)(]\+\|(\([^)(]\+\|([^)(]*)\)*)\)*\ze)',
 'rx_text': '\[\zs[^\\\[\]]\{-}\ze\]([^\\]\([^)(]\+\|(\([^)(]\+\|([^)(]*)\)*)\)*)',

and in wiki-ft.vim/syntax/wiki.vim:

syntax match wikiConcealLinkMd
    \ /\]([^\\]\([^)(]\+\|(\([^)(]\+\|([^)(]*)\)*)\)*)/
    \ contained transparent contains=NONE conceal

This all works—and I can submit PRs—but it’s dissatisfyingly ugly and repetitive. I’m not sure how to improve it, however, since between link detection and concealing, we have multiple pieces.

[lervag]

Ah, yes - good catch. I was aware of this and I avoid the problem by encoding the links. That is, when I have links with parantheses, I use the ]u and [u mappings from vim-unimpaired.

...
This all works—and I can submit PRs—but it’s dissatisfyingly ugly and repetitive. I’m not sure how to improve it, however, since between link detection and concealing, we have multiple pieces.

Well, I'm already quite dissatisfied with all the "ugly" regexes, so I'm not very happy to make/accept these suggested changes. If you feel strongly about this, then I would rather spend some time and look into a non-regex approach. Or, perhaps I'll let myself be convinced to choose the pragmatic solution, but not without some discussion... :)

[lervag]

I don't really plan to update with the ugly regexes. I am going to work on #147 at some time, and that will require some change sto how I parse the links. That might allow some improvements that would resolve this issue as well. Thus, I'll close this issue.