Christian Brabandt <[email protected]> wrote: > Hi Dominique! > > On Fr, 26 Dez 2014, Dominique Pellé wrote: > >> On Fri, Dec 26, 2014 at 2:37 PM, Christian Brabandt <[email protected]> >> wrote: >> > Hi Dominique! >> > >> > On Fr, 26 Dez 2014, Dominique Pellé wrote: >> > >> >> Sorry for the noise. My latest patch does not fix it. >> >> I had been testing vim small, which does not have >> >> showbreak so it did not show the bug <sigh> >> >> The bug is still present in vim huge with my patch >> >> or with your latest patch, at least when doing: >> >> >> >> $ vim -u NONE -c 'set nu cpo= sbr=: co=49' bug-vim.txt >> >> >> >> And press A in command mode to append >> >> char at the end of the line and see that cursor is >> >> incorrectly positionned. >> > >> > Oh, that happens because the last TAB char at the previous line is drawn >> > too long. Here is an updated patch. >> >> It's not an easy bug to fix :-( > > Yes, the screen drawing code is complex and I think you have now found > another problem, that is actually not caused by that but by the > win_lbr_chartabsize function. > >> It's still broken with your latest patch using... > > I come to the conclusion, this is a different problem, that is > independent of the problem you reported initially. The problem with the > screen size of 49 is actually, that Vim does not consider, the > numberwidth option and thinks the second last tab would not wrap, while > it does. > > The screen drawing code is independent of this, and does take this into > account (and therefore my previous patch was wrong, because the screen > drawing code does in fact take the length of the 'sbr' into account and > adjusts the length of a tab correctly, and therefore, my last attempt > fixed this special case, but the general case was broken, as you pointed > out in your last message) > > Therefore I think we have observed two different problems that need to > be fixed. Part one is the wrong drawing of the length of a tab as > pointed in your initial mail (patch sbr_buf_new.diff), part two is the > wrong calculation of the column position and therefore not taking into > account that wrapping will actually happen. This is fixed by the patch > win_lbr_chartabsize_numberwidth.diff. That function is unfortunately > called a lot and I hope, this patch does not brake at other parts of the > code). > >> >> $ vim -u NONE -c 'set nu cpo= sbr=: co=90' bug-vim.txt >> >> It's also broken with: >> >> $ vim -u NONE -c 'set sbr=: co=84' bug-vim.txt >> >> Then press A in command mode and cursor gets beyond >> the end of line. > > That is the general case and should now again work as expected again. > > I have checked will all your 4 provided test cases and it looks good so > far. However you have successfully found many different problems with > different screen sizes so you might want to check, that this works as > well. > > I'll copy vim-dev. Once you verified, that it works for you correctly, > I'll try to create some test cases that catch at least those two > problems. > > Best, > Christian
Hi Christian I installed your 2 latest patches. But I still see the bug :-( A good way to test manually is to press A or $ to move cursor the the end of line, and then resize the terminal with the mouse to various horizontal sizes and check that the cursor remains at the end of line for various sizes. I see the bug at least with: $ vim -u NONE -c 'set nu cpo= sbr=: co=88' bug-vim.txt or $ vim -u NONE -c 'set nu cpo= sbr=: co=49' bug-vim.txt Then press A to append at end of line and observe the cursor at the wrong location. Regards Dominique -- -- 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.
