Re: [PATCH] Enable linewise edit-command when in visual-line

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Aug 27, 2023 at 4:39 AM Christoffer Lundell
<christofferlundell@xxxxxxxxxxxxxx> wrote:
>
> > So ... I think this means that in vi-cmd-mode it is necessary to use
> > CURSOR+1 when MARK <= CURSOR, but not MARK+1 when CURSOR < MARK? And
> > never add one when in emacs mode?
>
> This makes me think I am missing something, because even when setting bindkey -e
> in my .zshrc and entering visual-line-mode, a cursor/mark on column 1 on a 2nd
> line to the right of the other cursor/mark never includes said 2nd line, despite
> it being visually highlighted. That is, while using the suggested:
>   right=${${BUFFER[CURSOR,-1]}[(i)$nl]} for MARK <= CURSOR

What I suggested in the excerpt above was that for MARK <= CURSOR this should be
  right=${${BUFFER[CURSOR+1,-1]}[(i)$nl]}
when in line-wise mode.  Which is what you have in your v3 patch.

> and
>   right=${${BUFFER[MARK,-1]}[(i)$nl]} for CURSOR < MARK
>
> I had to use CURSOR+1 and MARK+1 from the lines above to fix that edge case.

OK, one thing *I* was missing was that when entering line-wise, the
full line containing MARK is also highlighted.  Given that, yes,
MARK+1 is correct here.

I'm still a little bothered about exchange-point-and-mark.  When
CURSOR > MARK, your v3 patch slurps up everything up to and including
the character under the cursor.  If I then do exchange-point-and-mark,
the region has now lost one character from the right (because that
character is no longer under the cursor).  If, before
exchange-point-and-mark, I enter vicmd mode, this happens differently,
that is, the character under the cursor in vicmd remains in the
region, but I've still lost one character when the cursor moved left
on entry to vicmd (unless it was already at start of a line).

Thus in emacs mode, either that character should never have been in
the region in the first place, or exchange-point-and-mark has a side
effect on the region.  Anyone (other than Christoffer) have feedback
on that?

> > > lbuffer=$lbuffer[++left,-1]
>
> You are right in that lbuffer= is equivalent for left=$CURSOR, however
> lbuffer[right-left,-1]= leaves the leading part of $lbuffer intact even if the
> visual selection does not start at the beginning of $BUFFER.
>
> The only thing that has been working consistently, and what fixes cursor
> positioning for me, is the previous:
>   lbuffer=${lbuffer[++left,-1]}
> In both blocks for (( REGION_HIGHLIGHT == 1 )) and (( REGION_HIGHLIGHT == 2 ))

When (( REGION_HIGHLIGHT == 1 )) there are only two possible cursor
placements:  At the beginning of the first editor line for CURSOR <
MARK, and at the end of the last line for CURSOR > MARK, because the
editor is supposed to contain only the region between CURSOR and MARK
inclusive. (The editor gets an empty file when CURSOR == MARK.)  I
think the prevailing presumption was that so long as $#lbuffer >
CURSOR - MARK, the cursor should end up at the end of the last line
... but it appears that nowadays vim will (un)helpfully add space
padding when the "go" argument is larger than the file size, so the
"optimization" of merely shortening $lbuffer won't work in that case
any more.

> And as I
> understand, $lbuffer is supposed to represent only the highlighted text before
> the cursor, to later figure out cursor positioning for the opened editor.

That means $lbuffer has to be empty when CURSOR < MARK and not
line-wise, so calculating $lbuffer[++left,-1] is correct (because
++left >= CURSOR).  I suppose the added effort is small, so the cases
may as well be unified.

Obviously most people who use this don't use it with ranges set.

I'm now satisfied that except for the exchange-point curiosity, your
v3 patch is correct.