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:
> I am wandering what is the logic behind deleting something using
> visual block. In particular, the case when the cursor which denotes
> the lower right-hand side corner of the block ends up on a space that
> got "expanded" up to the end of the screen line due to 'linebreak'
> setting. I am talking about an example from the test case in
> Test_virtual_block() func in test_listlbr.vim. The buffer consists of
> lines: "Remove: this not" and "remove: aaaaaaaaaaaaa". The window
> width is 20 and line 2 is one char longer so it is wrapped. Due to lbr
> setting, it is not split after the 20th char but after the space. So
> the screen layout is something like this:
>
> Remove: this not | line 1
> remove: | line 2, the first part
> +aaaaaaaaaaaaa | line 2, the wrapped part with sbr='+' indicator
>
> In screen line 2, just after the colon, there is one real space which
> is followed by a sequence of (fictious) padding screen spaces up to
> the window border. We begin highlighting a visual block at the 'R' in
> line 1. Then, denoting lower light-hand side of our block, we let the
> cursor stand at the space in line 2 just after the colon (see the red
> coloring). What's highlighted is this: "Remove: " in line 1 and
> "remove: " in line 2. Now we press 'd' to delete the selection.
>
> 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.
> According to the source code, the "linebreaked" space is looked upon
> as a char with size 13 instead of 1. And (like with a tab) if one part
> of a char is in the block and the rest lies outside, the char is
> usually replaced with a string of spaces of apropriate size and then
> split into two parts (interior and external) and then the one part
> which is in the block is deleted together with the rest of the
> 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.
Sorry for not being able to give you more concrete advise here.
Best,
Christian
--
Fehler gehören zu den Verpflichtungen,
mit denen man für ein vollwertiges Leben zahlt.
-- Sophia Loren (eig. Maria Scicolone)
--
--
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.
