> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
