On Tuesday, November 27, 2018 at 9:46:48 PM UTC+1, Christian Brabandt wrote: > Hi, > as somebody who has contributed a bit to the screen displaying logic I > figured, I should probably comment. > > I believe, the mentioned test has been written by me and I have in the > past quite often tried to fix various bugs around the block editing and > display of characters in combination of various settings that influence > the display. > > On Di, 27 Nov 2018, Tom M wrote: > > [...] > > Currently (as the test case suggests), the buffer ends up with line 1 > > containing "this not" and line 2 containig the "aaaaaaaaaaaaa". So the > > real space in line 2 got deleted together with the rest of the screen > > line - with the fictious padding spaces. > > Yes, I believe this is correct. Everything that was highlighted, was > deleted. The fictious padding space is only visible and is not really in > the buffer, so it "disappears" when the line is not wrapped anymore. > > [...] > > selection. So how come the external part of our linebreaked space got > > deleted too? And if this is really a feature and not something > > undesired then why the visual block highlighting (just before the > > deleting) does not correspond exactly to what gets deletedt? Why this > > differs from another situation, when the cursor stands on a tab > > character and 'v' is pressed to begin selection and the *whole* length > > of the tab char is highlighted, not only the firs (or last) space? > > > The padding from the linebreak space is not really there. It is just a > visual appearance and I believe this can be seen by how the line is > colored e.g. when cursorline is on. Those areas (as well as e.g. the > spaces introduced by 'sbr' in wrapped lines) won't be affected by the > cursorline setting since it is not there. > > > > > The most important thing for me is to be able to programatically > > figure when (in general) a space should be deleted together with it's > > lbr-padding and when the corresponding external part od padding should > > stay in the buffer. > > Well, it is complicated. One has to be very careful not to introduce any > more bugs. I know for sure, as I think I am responsible for quite some > of those bugs which I think I have also most often fixed :) > > So the only way I know of is to try to recalculate the screen wrapping > logic. Which is a bit unfortunate, since one has to kind of replicate > the logic of the win_line() function which is long and ugly and not easy > to follow.
Thanks for the insight. I'll try to look into the suggested places and perhaps I'll figure something. Regards, Tom -- -- 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.
