-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 <[email protected]> wrote:
>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.
*Virtual* column number? Compiler author must be crazy to write this, and as
explained in the other thread (with a new patch for matchaddpos() to support
screen cells) it is incorrect to blindly use it without setting settings to
exactly those of the compiler.
Can you please read that thread and explain whether and why you needed screen
cells? I have a discussion there with an explanation why screen cells are
inappropriate for matchaddpos(). OP was saying that you requested it, but I do
not see why.
>
>[...]
>> 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
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQI1BAEBCgAfBQJTtsgLGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvvDAD/4hDK2LgDnx9E+Cdju2R9XlcGP8mofbBq6boOcrnEy/PrEfsINP5LkT
qXnmCqwDDXMxf9/YduaGfZAbMyVUSILFqDntN0LoM2kH/k0pIpXyKmoA9NzWz0RU
ZIpAqd5cPC1pnW2PH8j73l1Lb7JXorAVBnzGa2By2fZZQ0rirS+jnFcn+OaTz9c/
Sc/LuizcLIROLPYs6Rv2my9BfqkCfkByZDx+XBTgpYxr4W7w4E/NEI9sJDpr72Lp
4+YRSloXTSyrbqYFoa27Og4GXtGgjRl3YKbY0C45YssaJkpsTWt91P3VHBaLY6/h
u9P9t7XtaeToQyI6BJAFIKj9oXeM8FT/wKiDPEkmirkprf/ulEF0rYBKrymQP8WL
QGW5l6UjnwxkH2+cuT2gkf6S8R4mw8Mwds728idk9pOE+boG2eg+EO5kkTt64TXS
VwfGVtrvNEe3VpEbJlHRTAYLKPrfHOkXPcZgyApORM1G6za0Lt4elwC6ePECJ/Uh
LjXkXKX535xBvE8K0nv/k8cSntfSy+2gDEfZZhubU6SnUzKWwV0Ry5ylOZIXOIf7
yinw3hz7VAtKP+fsKuOjORn1EvCo1bA4uVhS0Khl6855zgT2/+RA3yhtEFmHHlT9
LdL62x8XnDj7q8ONUwt9cTWCPfIu2BmzL5xjdkHzmVrwKLIdNHvYwQ==
=ywVE
-----END PGP SIGNATURE-----
--
--
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.
