-----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. > >[...] >> 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 virtcol() does accept lists (line and column pairs). >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 virtcol([linenr, col]) will do. The opposite conversion (screen column to byte index) is much more complicated. >calculation, why on Earth should I care where the cursor and / or the >marks are? You should not care. You should read documentation. > >[...] >> > 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 iQI1BAEBCgAfBQJTsvpiGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvsIxD/9epkAOLmd7uYuuZoFu72i9904UjwMdRhPRUzXh6M2UQlEKB1MWxVNZ HlgELFYX70g8fFrVrxZgWm77UCq8ON7SzUyZf11z4hxygUFoOm3Fr2F1WBvrB0jn 292G0N4F1nIpcqWvdnLbcS0PHPL9Ykv00wuAGt/hLRIO1jDjCUExlaumIotOxzW5 x0TmGrD54coe+e1CEugnnu80W/yoFHOymlBlfXPm+373cO1BB2zYSZMts8ZJxo9p R8c7TQHyQ7fGYGU8guUIwLsWkele0h5LGJ8+h8+u53hqlGqx5pQfrZpGoG4AMFZQ +s96UE21w78L0dDjaFnYAo75Ehx0FL66z/eDxgVPhu8FUJMb/UmcpWUACv3xIR8J pYsGNvobbP7Wx807TKzgsOVA0fdtjkTRasjnqfIKZc/6E6GVS56SrnsB02EEO+xv //NczJdBNTcOzRv1HqKmpynVczGqsYX/FEAWQOxZ+X8NvqDQwM9phhHy6Q0DvCrv 3AU8jHjUwwnt1gJ4FlOBnv+iTDdq30zXU4SKC7fWgP3FmOxPGWUBgQoTXckDWAj7 NJvR2f7Z/sVOe7oGqcFFLexmzqRjbUxfWquqCeL/iDcHfb89mZypkuZtxIhn/pnq Be5Ot5DxrgK5NHgydta2AbpCtrQSM7Zzcsfas/SrX5HKP5j+MY5iAQ== =+pXF -----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.
