On 1 July 2014, Bram Moolenaar <[email protected]> wrote:
> lcd wrote:
[...]
> > 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.
True -- unless the column number comes from somewhere else, such as
a compiler's error message. Sometimes you don't get to choose.
[...]
> 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.
So what? Once part of Vim, matchaddpos() is just another function,
two weeks from now nobody will remember why it was added. Sooner or
later somebody will find a creative way to abuse it, and will find
himself banging his head against the desk because of this limitation.
And in this particular case it's a limitation that could have been
avoided basically for free. *shrug*
> > 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.
The problem with virtcol() (and most similar functions, for that
matter) is that it isn't independent of the surrounding context.
It requires either the cursor, or a mark to be set to the position
you care about. In a script this is horribly intrusive: I have to
save either the cursor or a mark, set things up for virtcol(), find
out the position, then restore the cursor or mark. I just want to
convert between screen columns and byte offsets, dammit! It's a length
calculation, why on Earth should I care where the cursor and / or the
marks are?
[...]
> > 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.
It's simpler in simple contexts. In more complicated contexts it's
less useful, because it plays by very different rules than matchadd().
/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.
