Hi Christian.
2014-07-01 22:00 GMT+04:00 Christian Brabandt <[email protected]>:
> 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.
>
Number 8 is not a "global" limitation. This is limited number of positions
that one call to matchaddpos() may use simultaneously. You can use multiple
matchaddpos() to highlight as many positions as you want. This "compound"
multi-positions design was chosen to emulate old matchparens regexp for
3match that declared two positions combined with \|. In principle 2 max
"compound" positions were enough for that.
The whole matchaddpos() was implemented with matchparen plugin and fast
parens highlight in mind hence those "flaws" in its design which make its
using not convenient for other plugins. Probably it could 1. be renamed to
matchparen() to prevent from giving it too many hopes, or (better?) 2. keep
its current name but fix all those "flaws" in it.
> 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...
>
In principle it could be implemented, but ... It's not required by
matchparen plugin. If we chose 2nd way from my previous comment then
implementation of this would make sense and benefit.
> 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.
>
Cheers, Alexey.
--
--
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.
