Hi
Disclaimer: I haven't looked into matchaddpo() yet, but plan to use it in
several
plugins I maintain.
On Di, 01 Jul 2014, Bram Moolenaar wrote:
> 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.
It isn't. Off the top of my mind, I could think of those situations:
- Highlight marks
- Highlight quickfix items (the syntastic use case)
- highlight changes of the buffer (by keeping track of the '[ and ']
marks). This doesn't work perfectly, since those marks are way too
often reset when editing a buffer, but could still be useful.
Almost all of them could grow easily beyond 8, I think.
BTW: what happens to the highlighting after one changes the buffer? E.g.
if I add a matchaddpos() at line 5, column 5 and afterwards add a line
below 3, will then line 6, column 5 be highlighted or line 5? Both could
be useful, I suppose...
Best,
Christian
--
Wenn wir keine Fehler hätten, würden wir nicht mit so großem
Vergnügen Fehler bei anderen entdecken.
-- François de La Rochefoucauld
--
--
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.
