I wrote: > Christian Brabandt wrote: > > > Hi Axel! > > > > On Sa, 17 Jan 2015, Axel Bender wrote: > > > > > 1) Open the attached file "test.txt". > > > 2) set ts=80 > > > 3) /\%>80vGesamtausabe > > > > I apologize for causing this. > > > > Here is a fix (including a test). > > Thanks. It fixes the problem reported, but using vcol_prev won't work > properly. If the engine tries this state at another position, or > another state, it will have the wrong value. > > Not sure how to remove vcol_prev without making it slow again. > A rough guess is to multiply the column with 'tabstop'. > Let me do that for now.
Thinking about this again: It should be OK to store the column and the computed virtual column. These do not depend on the RE state. When trying several states at the same position the virtual column will be computed only once. And when the column is higher than the cached column, we know the virtual column is also higher than the cached virtual column. That should help avoid useless calls to win_linetabsize() while still being accurate, instead of the wild guess using 'tabsize'. Christian, do you think you could work on this? And write a test. -- >From "know your smileys": <|-) Chinese <|-( Chinese and doesn't like these kind of jokes /// Bram Moolenaar -- [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
