Loading ...
Sorry, an error occurred while loading the content.

matchaddpos(): a mini-review

Expand Messages
  • LCD 47
    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
    Message 1 of 17 , Jun 30, 2014
    • 0 Attachment
      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.

      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 }

      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.

      Then, the lengths is a byte count. This means that if the character
      at the beginning of a highlight happens to be multi-byte and the length
      is 1, the line is highlighted to the end. I believe this is a bug.
      Again, matchadd() handles this situation gracefully.

      Then, getmatches() returns both matchadd() patterns and
      matchaddpos() patterns, but setmatches() can only handle old-style
      matchadd() patterns. This means it's no longer possible to use
      getmatches() and setmatches() to save and restore patterns. I suppose
      this could be fixed, by making setmatches() look at patterns it has to
      restore: the ones that have a 'pattern' are matchadd() patterns, the
      ones that have 'pos1' and friends are matchaddpos() patterns.

      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.

      /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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/d/optout.
    • Bram Moolenaar
      ... I thought the original reason was to speed up highlighting matches with the matchparen plugin. But that doesn t matter. ... The main thing was to
      Message 2 of 17 , Jul 1, 2014
      • 0 Attachment
        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.

        > 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.

        > Then, the lengths is a byte count. This means that if the character
        > at the beginning of a highlight happens to be multi-byte and the length
        > is 1, the line is highlighted to the end. I believe this is a bug.
        > Again, matchadd() handles this situation gracefully.

        That's a bug.

        > Then, getmatches() returns both matchadd() patterns and
        > matchaddpos() patterns, but setmatches() can only handle old-style
        > matchadd() patterns. This means it's no longer possible to use
        > getmatches() and setmatches() to save and restore patterns. I suppose
        > this could be fixed, by making setmatches() look at patterns it has to
        > restore: the ones that have a 'pattern' are matchadd() patterns, the
        > ones that have 'pos1' and friends are matchaddpos() patterns.

        That should be fixed.

        > 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.

        --
        "Hegel was right when he said that we learn from history that man can
        never learn anything from history." (George Bernard Shaw)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/d/optout.
      • LCD 47
        ... [...] ... True -- unless the column number comes from somewhere else, such as a compiler s error message. Sometimes you don t get to choose. [...] ... So
        Message 3 of 17 , Jul 1, 2014
        • 0 Attachment
          On 1 July 2014, Bram Moolenaar <Bram@...> 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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/d/optout.
        • Christian Brabandt
          Hi Disclaimer: I haven t looked into matchaddpo() yet, but plan to use it in several plugins I maintain. ... It isn t. Off the top of my mind, I could think of
          Message 4 of 17 , Jul 1, 2014
          • 0 Attachment
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/d/optout.
          • Павлов Николай Алекса
            ... Hash: SHA512 ... virtcol() does accept lists (line and column pairs). ... virtcol([linenr, col]) will do. The opposite conversion (screen column to byte
            Message 5 of 17 , Jul 1, 2014
            • 0 Attachment
              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA512



              On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 <lcd047@...> wrote:
              >On 1 July 2014, Bram Moolenaar <Bram@...> 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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/d/optout.
            • LCD 47
              On 1 July 2014, Павлов Николай Александрович ... [...] ... Well, somehow I managed to overlook this for years. Thank you for
              Message 6 of 17 , Jul 1, 2014
              • 0 Attachment
                On 1 July 2014, Павлов Николай Александрович
                <zyx.vim@...> wrote:
                > On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 <lcd047@...> wrote:
                [...]
                > > 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).

                Well, somehow I managed to overlook this for years. Thank you for
                enlightening me, I suppose I'm too old to be allowed around Vim code
                these days.

                > >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.

                Of course, you're right: virtcol() is useless in the context of the
                initial discussion, you need to convert coordinates the other way around
                to translate a '\%...v' for matchaddpos().

                > >calculation, why on Earth should I care where the cursor and / or the
                > >marks are?
                >
                > You should not care. You should read documentation.

                You think so? After all, I managed to find out about the cursor and
                marks using my ESP abilities. ;)

                /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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/d/optout.
              • LCD 47
                On 1 July 2014, Christian Brabandt wrote: [...] ... As it is now, the highlight stays at line 5, column 5. I think there was a recent
                Message 7 of 17 , Jul 1, 2014
                • 0 Attachment
                  On 1 July 2014, Christian Brabandt <cblists@...> wrote:
                  [...]
                  > 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...

                  As it is now, the highlight stays at line 5, column 5. I think
                  there was a recent patch to make it move along with the text it
                  highlights (which would be a lot more useful, IMO).

                  /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 vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/d/optout.
                • Alexey Radkov
                  ... I wonder how could it be implemented (just thought to add this functionality to matchaddpos())? Imagine situation: you add a match at line 5, then delete
                  Message 8 of 17 , Jul 1, 2014
                  • 0 Attachment



                    2014-07-01 22:51 GMT+04:00 LCD 47 <lcd047@...>:
                    On 1 July 2014, Christian Brabandt <cblists@...> wrote:
                    [...]
                    > 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...

                        As it is now, the highlight stays at line 5, column 5.  I think
                    there was a recent patch to make it move along with the text it
                    highlights (which would be a lot more useful, IMO).

                    I wonder how could it be implemented (just thought to add this functionality to matchaddpos())?

                    Imagine situation: you add a match at line 5, then delete the whole line 5 (rdeletee this match now or store somewhere?), then make undo (returning back that line 5). Will the match be restored? If so then we should track all history of buffer change, in other words we have to implement semantical binding between match and buffer, whereas now its technically bound to a simple number.


                        /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 vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/d/optout.

                    --
                    --
                    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 vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/d/optout.
                  • LCD 47
                    ... Yes, I d say it should be restored. ... How about adding highlighting adds / removals to the undo list. That way, when you delete line 5, the highlights on
                    Message 9 of 17 , Jul 1, 2014
                    • 0 Attachment
                      On 1 July 2014, Alexey Radkov <alexey.radkov@...> wrote:
                      > 2014-07-01 22:51 GMT+04:00 LCD 47 <lcd047@...>:
                      > > On 1 July 2014, Christian Brabandt <cblists@...> wrote:
                      > [...]
                      > > > 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...
                      > >
                      > > As it is now, the highlight stays at line 5, column 5. I think
                      > > there was a recent patch to make it move along with the text it
                      > > highlights (which would be a lot more useful, IMO).
                      > >
                      >
                      > I wonder how could it be implemented (just thought to add this
                      > functionality to matchaddpos())?
                      >
                      > Imagine situation: you add a match at line 5, then delete the whole
                      > line 5 (rdeletee this match now or store somewhere?), then make undo
                      > (returning back that line 5). Will the match be restored?

                      Yes, I'd say it should be restored.

                      > If so then we should track all history of buffer change, in other
                      > words we have to implement semantical binding between match and
                      > buffer, whereas now its technically bound to a simple number.

                      How about adding highlighting adds / removals to the undo list.
                      That way, when you delete line 5, the highlights on line 5 would be
                      deleted and the operation written to undo stack, then line 5 would be
                      deleted, and the operation written to the undo stack. When you undo
                      the operation first the line would be restored from the stack, then the
                      highlights. No need to track anything.

                      /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 vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/d/optout.
                    • Alexey Radkov
                      Hi Christian. ... Number 8 is not a global limitation. This is limited number of positions that one call to matchaddpos() may use simultaneously. You can use
                      Message 10 of 17 , Jul 2, 2014
                      • 0 Attachment
                        Hi Christian.

                        2014-07-01 22:00 GMT+04:00 Christian Brabandt <cblists@...>:
                        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 vim_dev+unsubscribe@....
                        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 vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/d/optout.
                      • Bram Moolenaar
                        ... No, the position is fixed. I m not sure how useful it is to adjust the positions for inserted/deleted lines. First of all, if the text is changed, the
                        Message 11 of 17 , Jul 2, 2014
                        • 0 Attachment
                          Lcd wrote:

                          > On 1 July 2014, Christian Brabandt <cblists@...> wrote:
                          > [...]
                          > > 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...
                          >
                          > As it is now, the highlight stays at line 5, column 5. I think
                          > there was a recent patch to make it move along with the text it
                          > highlights (which would be a lot more useful, IMO).

                          No, the position is fixed.

                          I'm not sure how useful it is to adjust the positions for
                          inserted/deleted lines. First of all, if the text is changed, the
                          positions may be invalid anyway, e.g., when highlighting () pairs
                          inserting/deleting a ( or ) requires updating the positions.
                          And keeping the column updated when inserting/deleting characters is
                          very complicated, it's not even done for marks.

                          Better just make clear the position is fixed and the script writer will
                          have to handle text changes.

                          --
                          No letters of the alphabet were harmed in the creation of this message.

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ an exciting new programming language -- http://www.Zimbu.org ///
                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                          --
                          --
                          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 vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/d/optout.
                        • LCD 47
                          ... [...] Still, leaving phantom highlights behind is annoying, and definitely not useful. Can we at least have an option to remove the highlight when it
                          Message 12 of 17 , Jul 2, 2014
                          • 0 Attachment
                            On 2 July 2014, Bram Moolenaar <Bram@...> wrote:
                            >
                            > Lcd wrote:
                            >
                            > > On 1 July 2014, Christian Brabandt <cblists@...> wrote:
                            > > [...]
                            > > > 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...
                            > >
                            > > As it is now, the highlight stays at line 5, column 5. I think
                            > > there was a recent patch to make it move along with the text it
                            > > highlights (which would be a lot more useful, IMO).
                            >
                            > No, the position is fixed.
                            >
                            > I'm not sure how useful it is to adjust the positions for
                            > inserted/deleted lines.
                            [...]

                            Still, leaving phantom highlights behind is annoying, and definitely
                            not useful. Can we at least have an option to remove the highlight when
                            it becomes invalid? This situation is a pain to detect in a script, and
                            it should be much easier to deal with at the source.

                            /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 vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/d/optout.
                          • Павлов Николай Алекса
                            ... Hash: SHA512 ... *Virtual* column number? Compiler author must be crazy to write this, and as explained in the other thread (with a new patch for
                            Message 13 of 17 , Jul 4, 2014
                            • 0 Attachment
                              -----BEGIN PGP SIGNED MESSAGE-----
                              Hash: SHA512

                              On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 <lcd047@...> wrote:
                              >On 1 July 2014, Bram Moolenaar <Bram@...> 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 vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/d/optout.
                            • LCD 47
                              On 4 July 2014, Павлов Николай Александрович ... Yes. ... I agree 100% that it s broken. They still do it. For what it s worth, I
                              Message 14 of 17 , Jul 4, 2014
                              • 0 Attachment
                                On 4 July 2014, Павлов Николай Александрович
                                <zyx.vim@...> wrote:
                                > On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 <lcd047@...> wrote:
                                > >On 1 July 2014, Bram Moolenaar <Bram@...> wrote:
                                > >> 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?

                                Yes.

                                > 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.

                                I agree 100% that it's broken. They still do it.

                                For what it's worth, I had to look at the sources at many of said
                                compilers to get syntastic to understand their output, and using virtual
                                columns isn't *that* far fetched. Most of the time they just expand
                                tabs while parsing and don't bother keeping track of the original
                                offset. When they run into an error they just compute the column number
                                by adding the lengths of the whitespace and the tokens parsed so far.

                                Double width characters is a different story. Some compilers use
                                Unicode codepoints, others byte length, which is, again, broken. Still,
                                Vim's virtual columns is yet the best approximation of it.

                                > 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.

                                It might be needed because (1) some compilers *do* produce error
                                messages in virtual columns, and (2) if you get an offset in virtual
                                columns you *can't* translate it to a byte offset to feed matchaddpos(),
                                as you pointed out in a previous message (not with a reasonable effort
                                that is).

                                /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 vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/d/optout.
                              • ZyX
                                ... I think the best solution is proposed colnr() function: check out [that thread][1]. virtcol to byte offset transformation is useful not only for
                                Message 15 of 17 , Jul 4, 2014
                                • 0 Attachment
                                  > I agree 100% that it's broken. They still do it.
                                  >
                                  > For what it's worth, I had to look at the sources at many of said
                                  > compilers to get syntastic to understand their output, and using virtual
                                  > columns isn't *that* far fetched. Most of the time they just expand
                                  > tabs while parsing and don't bother keeping track of the original
                                  > offset. When they run into an error they just compute the column number
                                  > by adding the lengths of the whitespace and the tokens parsed so far.
                                  >
                                  > Double width characters is a different story. Some compilers use
                                  > Unicode codepoints, others byte length, which is, again, broken. Still,
                                  > Vim's virtual columns is yet the best approximation of it.

                                  I think the best solution is proposed colnr() function: check out [that thread][1]. virtcol to byte offset transformation is useful not only for matchaddpos(). I had to write it in [translit3][2] and that variant is rather slow. Your proposal will fix matchaddpos() for one given use-case and only matchaddpos() and only under very limited conditions. colnr() is not so limited.

                                  I say that you are seeking answer in a wrong direction.

                                  [1]: https://groups.google.com/forum/#!topic/vim_dev/2DYfyTuo7G0
                                  [2]: https://sourceforge.net/p/translit3/code/ci/040e92e8021320740109067dbe2fb43e50fbba94/tree/autoload/translit3.vim#l2262

                                  --
                                  --
                                  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 vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/d/optout.
                                • LCD 47
                                  ... Yes, a colnr() function would be useful, both in this situation and by itself. ... I m afraid you lost me here. I just pointed out a number of (what I
                                  Message 16 of 17 , Jul 6, 2014
                                  • 0 Attachment
                                    On 4 July 2014, ZyX <zyx.vim@...> wrote:
                                    > > I agree 100% that it's broken. They still do it.
                                    > >
                                    > > For what it's worth, I had to look at the sources at many of
                                    > > said compilers to get syntastic to understand their output, and
                                    > > using virtual columns isn't *that* far fetched. Most of the time
                                    > > they just expand tabs while parsing and don't bother keeping track
                                    > > of the original offset. When they run into an error they just
                                    > > compute the column number by adding the lengths of the whitespace
                                    > > and the tokens parsed so far.
                                    > >
                                    > > Double width characters is a different story. Some compilers
                                    > > use Unicode codepoints, others byte length, which is, again, broken.
                                    > > Still, Vim's virtual columns is yet the best approximation of it.
                                    >
                                    > I think the best solution is proposed colnr() function: check out
                                    > [that thread][1]. virtcol to byte offset transformation is useful not
                                    > only for matchaddpos().

                                    Yes, a colnr() function would be useful, both in this situation and
                                    by itself.

                                    > I had to write it in [translit3][2] and that variant is rather
                                    > slow. Your proposal will fix matchaddpos() for one given use-case and
                                    > only matchaddpos() and only under very limited conditions. colnr() is
                                    > not so limited.

                                    I'm afraid you lost me here. I just pointed out a number of (what I
                                    consider to be) problems with the design of matchaddpos(), which I found
                                    when I actually tried to use the function. I never attempetd to suggest
                                    any solutions.

                                    Your colnr() might be, IMO, a reasonable solution for one of the
                                    problems I noted. It doesn't address any of the others.

                                    > I say that you are seeking answer in a wrong direction.
                                    >
                                    > [1]: https://groups.google.com/forum/#!topic/vim_dev/2DYfyTuo7G0
                                    > [2]: https://sourceforge.net/p/translit3/code/ci/040e92e8021320740109067dbe2fb43e50fbba94/tree/autoload/translit3.vim#l2262

                                    /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 vim_dev+unsubscribe@....
                                    For more options, visit https://groups.google.com/d/optout.
                                  • Павлов Николай Алекса
                                    ... Hash: SHA512 ... Absence of some colnr() features is not only a matchaddpos() problem. It is helpful for one of matchaddpos() problems you pointed out, but
                                    Message 17 of 17 , Jul 6, 2014
                                    • 0 Attachment
                                      -----BEGIN PGP SIGNED MESSAGE-----
                                      Hash: SHA512

                                      On July 6, 2014 6:27:28 PM GMT+03:00, LCD 47 <lcd047@...> wrote:
                                      >On 4 July 2014, ZyX <zyx.vim@...> wrote:
                                      >> > I agree 100% that it's broken. They still do it.
                                      >> >
                                      >> > For what it's worth, I had to look at the sources at many of
                                      >> > said compilers to get syntastic to understand their output, and
                                      >> > using virtual columns isn't *that* far fetched. Most of the time
                                      >> > they just expand tabs while parsing and don't bother keeping track
                                      >> > of the original offset. When they run into an error they just
                                      >> > compute the column number by adding the lengths of the whitespace
                                      >> > and the tokens parsed so far.
                                      >> >
                                      >> > Double width characters is a different story. Some compilers
                                      >> > use Unicode codepoints, others byte length, which is, again,
                                      >broken.
                                      >> > Still, Vim's virtual columns is yet the best approximation of it.
                                      >>
                                      >> I think the best solution is proposed colnr() function: check out
                                      >> [that thread][1]. virtcol to byte offset transformation is useful not
                                      >> only for matchaddpos().
                                      >
                                      > Yes, a colnr() function would be useful, both in this situation and
                                      >by itself.
                                      >
                                      >> I had to write it in [translit3][2] and that variant is rather
                                      >> slow. Your proposal will fix matchaddpos() for one given use-case and
                                      >> only matchaddpos() and only under very limited conditions. colnr() is
                                      >> not so limited.
                                      >
                                      > I'm afraid you lost me here. I just pointed out a number of (what I
                                      >consider to be) problems with the design of matchaddpos(), which I
                                      >found
                                      >when I actually tried to use the function. I never attempetd to
                                      >suggest
                                      >any solutions.
                                      >
                                      > Your colnr() might be, IMO, a reasonable solution for one of the
                                      >problems I noted. It doesn't address any of the others.

                                      Absence of some colnr() features is not only a matchaddpos() problem. It is helpful for one of matchaddpos() problems you pointed out, but it is not the only scope where this function is useful. Fix to matchaddpos() to accept dictionary with vcol, on the other side, is only useful for matchaddpos().

                                      >
                                      >> I say that you are seeking answer in a wrong direction.
                                      >>
                                      >> [1]: https://groups.google.com/forum/#!topic/vim_dev/2DYfyTuo7G0
                                      >> [2]:
                                      >https://sourceforge.net/p/translit3/code/ci/040e92e8021320740109067dbe2fb43e50fbba94/tree/autoload/translit3.vim#l2262
                                      >
                                      > /lcd

                                      -----BEGIN PGP SIGNATURE-----
                                      Version: APG v1.1.1

                                      iQI1BAEBCgAfBQJTuarNGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
                                      HhHSvh1LD/wN4veq+vWKGR/XlGFqy03o9HEee2Zw807fv8/zBuhvfHFdXoNHb+FV
                                      B4ZtaUEeEofrWorr2RxLQQ8Z8N7rHfLyz9zjUbXzCBqF/KPYACKW2sdXYXKi5nTI
                                      lNHku1O6ohe3/WzrcXD5/vjiXNNhqIbzU9+Xoq5Kr43MzHphsQAp38CUgcni78Rd
                                      qXaOllrN/ep2I6gBKCeQ4xCjvoNBLT8+ef1eci9yaDR7W4ry+DybRpzx2P1n2BNl
                                      PwsSS+tDH45hjgr6huCMftYsZJRONM5te7FQRW+GEIhL3fmbeKL3imhCtsZAP+2M
                                      5TwrIzRGyg/9JzUawwDa0W1EJ6BUvL6h57tGb/hV605XU+z5/NdL2mEgpc1BNbtu
                                      7kPSDMKPxJJPD5NcGl2x6Syg7GxUrdXDXUfwrrx9wzEYoz0NsoBgI2QsCVZz7061
                                      qQRBpXkVEVcM1abEA7dMVuF5giN5U86IHW8w0Xd4mdOLY4yLisPgA1m0iFCDHatt
                                      ykOtm4sB6N9FTWP9QuFclvL0hyB/j9FyTl72fCduxfZPIR+PaJKrshcbNXslXE4e
                                      qgw5g7wH/yryEjidja3RAyWkVc7McUsEKjgz6Y+Gl1/Tenjibyo8LoP1nBhlhBDl
                                      cqcYvTOOtB5APUMMn4ZodsPxoT8qWGnGQGwZzfVHcb+mGeza82Vchw==
                                      =D961
                                      -----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 vim_dev+unsubscribe@....
                                      For more options, visit https://groups.google.com/d/optout.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.