The initial motivation for adding the matchaddpos() function was
to speed up highlighting in syntastic, so I tried to make syntastic
actually use it where appropriate. As it turned out, that isn't really
feasible, partly because of the structure of syntastic (not relevant
on this list), but also partly because of what I claim to be a number
of flaws in the design of matchaddpos(). What follows are my (random)
thoughts on the matter.
First, the interface:
matchaddpos({group}, {pos}[, {priority}[, {id}]])
Here, {pos} is a list of lists. In principle this allows one to set a
number of highlight patterns at once; in practice, it means:
* call matchaddpos("group", [a]) - highlights line a
* call matchaddpos("group", [[a]]) - also highlights line a
* call matchaddpos("group", [a, b]) - highlights lines a and b
* call matchaddpos("group", [[a, b]]) - highlights one byte at position
(a, b)
* call matchaddpos("group", [[a, b, c]]) - highlights c bytes at position
(a, b)
This is (1) ugly, (2) inconsistent with matchadd(), which can only
handle one pattern at a time, (3) it adds an artificial limitation to
8 patterns per call, and (4) it doesn't offer any simple replacement
for matchadd("group", '\m\%5c') (that is highlighting columns, top
to bottom). Perhaps a better choice would have been to make {pos} a
dictionary (or a list of such, if you absolutely can't help it), with
all elements optional, like this:
{ 'line': 3, 'col': 5, 'len': 2 }
Back to {pos}: the column number is a byte offset. Since there
are no standard functions to convert between screen columns and
byte offsets, this means one gets the pleasure to deal with tabs,
multi-byte strings, concealed characters, and the like. If {pos} were a
dictionary, as suggested above, handling virtual columns could be added
with a 'vcol' field (again, optional). Please note that matchadd()
handles things like '\%5v' just fine.
Then, the lengths is a byte count. This means that if the character
at the beginning of a highlight happens to be multi-byte and the length
is 1, the line is highlighted to the end. I believe this is a bug.
Again, matchadd() handles this situation gracefully.
Then, getmatches() returns both matchadd() patterns and
matchaddpos() patterns, but setmatches() can only handle old-style
matchadd() patterns. This means it's no longer possible to use
getmatches() and setmatches() to save and restore patterns. I suppose
this could be fixed, by making setmatches() look at patterns it has to
restore: the ones that have a 'pattern' are matchadd() patterns, the
ones that have 'pos1' and friends are matchaddpos() patterns.
Last but not least: is there any reason why this is a separate
function, instead of an optimisation inside matchadd()? There are
a finite number of common fixed position patterns, so it should be
possible to just look at the patterns passed to matchadd(), and treat
them specially if they involve only fixed positions. It's really,
really much more of a pain to leave this to end the user.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
