Tomm wrote:
> 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.
Any progress on this?
--
On the other hand, you have different fingers.
-- Steven Wright
/// 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.
