lcd wrote:
> 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.
I thought the original reason was to speed up highlighting matches with
the matchparen plugin. But that doesn't 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 }
The main thing was to highlight one or a few characters at a fixed
position in the text. Such as a parenthesis. Text is usually located
by byte index, not character index, since it's quicker.
Being able to highlight a whole line was added by the implementor and
comes almost for free. Being able to highlight a column would be much
more difficult and also less efficient, since it requires updating many
screen lines when a change is made. Might as well keep using the old
way for that.
The syntax is a bit strange, that's true.
The limit of 8 makes the implementation simpler, and I can't think of a
reason why someone would want to highlight more than 2 or 3 matches,
thus 8 seems like it's sufficient.
> 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.
Is there a problem with using virtcol() before passing the position to
matchaddpos()? Passing the screen column makes things much more
complicatet, but it would be possible.
> 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.
That's a bug.
> 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.
That should be fixed.
> 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.
Parsing the pattern is difficult, and for a script writer creating the
pattern is a hassle. Passing the position with numbers is much simpler
on both sides.
--
"Hegel was right when he said that we learn from history that man can
never learn anything from history." (George Bernard Shaw)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
