Wrong link recognition about wiki.vim

[lervag]

So something like [a-zA-Z][-_.a-zA-Z0-9]* for the non-digit part of your regexp.

Agreed, this looks good! I'll get to work!

[lervag]

Ok, I think this is fixed and works as expected now.

[lervag]

Ah, yes. I'm not quite sure how to actually solve this, though. The same syntax is used for "bottom style" links, e.g.

# Some section

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod
tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At
vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd
gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. [0]

[0]: https://en.wikipedia.org/wiki/Lorem_ipsum

Or also [this] type of link.

[this]: url

So, how can we properly know that [o] is not a link?

Personally I've just come to ignore this, but I agree it is annoying, and I'll be glad to implement a fix if I/anyone can come up with a good way to do it.

[jabirali]

I think the following might be a good enough heuristic for most users.

If using a bottom-style link in a list, I think most users would either use descriptive labels:

- [Interesting]
- [Look at this]

Or use numeric links that are situated deeper into the text:

- This was one interesting link [0];
- So was this [1], and this [2].

However, I think few people would use bottom links like this:

- [1] This was interesting;
- [x] So was this.

Conversely, MarkDown checkboxes always appear at the beginning and consists of one character:

- [o] This is one item
- [x] This is another
- [ ] This is not done
- [-] Partially done.

So if you match for an extended regexp like ^[-+*]\s*\[.\]\s+ to declare something a checkbox, I think that would capture basically all MarkDown checkboxes, while almost never interfering with links.

EDIT:
I think we should include some initial space as well (for indented sublists). It's also possible to restrict the bracketed characters to non-numeric ones, so list items like - [1] Here is text would interpret [1] as a link not a checkbox. Updated heuristic: ^\s*[-+*]\s*\[[^0-9]\]\s.

I think this should capture almost all use cases...

[lervag]

I think this is actually quite simple. Currently, the [....] is recognized as a reference style link (see :help wiki-links-reference) with a very greedy regular expression. It matches almost anything that looks like [...] or [...][...]. This issue could probably be solved if we simplified things extensively. For instance, perhaps it would suffice to use a regex where the target part only matches:

• \d\+ (numbers)
• [a-zA-Z ]\{2,} (words and text, minimum 2 characters to avoid collision with the todo lists)

What do you think? It would mean to change the target regex into something like: \[\(\d\+\|[a-zA-Z ]\{2,}\)\] (slightly more complicated to handle edge cases, but you get the idea).

[jabirali]

That sounds like a good solution! However, perhaps adding slightly more characters to the revised regexp would be helpful? I don't know about you, but I can often call a link something that contains number in the text (say something that contains i3wm or CO2). I think that hyphens and underscores may perhaps also be quite common in such reference labels.

Quickly checking the original MarkDown documentation, it seems like the "official" definition is:

Link definition names may consist of letters, numbers, spaces,
and punctuation — but they are not case sensitive.

It's not really clear what "punctuation" is allowed here, but I would guess that underscores and hyphens in reference labels could be quite common. Perhaps allowing general combinations of minimum 2x letters, numbers, spaces, hyphens, and underscores is a good general rule? Possibly also periods?

EDIT:
Not sure [ ], [--], and [__] should count as valid reference targets though. I think perhaps the link format should require that at least the first character of a reference name is alphabetic or alphanumeric, while subsequent characters can include whitespace and punctuation. (So something like [a-zA-Z][-_.a-zA-Z0-9]* for the non-digit part of your regexp.)

[jabirali]

Quick correction: I think I forgot whitespace in the [-_. a-zA-Z0-9], and probably the * at the end should be a + (in extended regexp) to avoid zero-character matches. The logic should still stand :).