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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Aug 23, 2023 at 2:06 AM Christoffer Lundell
<christofferlundell@xxxxxxxxxxxxxx> wrote:
>
> > > + offset_right=${(SB)${BUFFER[mark_right+1,-1]}#$'\n'}
> >
> > This I'm not sure of -- why mark_right+1 ?
>
> This is because CURSOR and MARK are 0-indexed, according to zshzle(1).

They're 0-based because position 0 represents an empty line, the
non-character before $LBUFFER.  The BUFFER and LBUFFER arrays
themselves are still 1-indexed (unless you're crazed enough to be
using zle with ksharrays).

BUFFER[CURSOR] is always the character to the left of the visible
cursor position.  To make this work, CURSOR is decremented when
entering vicmd mode (unless it's already zero), but that doesn't
change MARK.

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 bothers me a little because starting from CURSOR < MARK,
exchange-point-and-mark (or vi-goto-mark?) could extend the range one
full line to the right?

> which also means we later on no longer need to immediately predecrement $right,
> since the matched index will be 1 lower.

I'm not sure whether the foregoing affects that, and can't experiment right now.

> There is also the issue about supporting cursor position in emacs, since now
> $lbuffer is used to split the selected lines and figure out the cursor line and
> column. But in both the original code and in your patch improvement, $lbuffer
> will contain text from the beginning of $BUFFER regardless of where the visual
> selection actually starts. This works fine in vim since they only use byte
> offsets, but I would recommend changing it to the following in _both_ cases.
>
> lbuffer=$lbuffer[++left,-1]

That's equivalent to lbuffer= when left=$CURSOR because by definition
everything after LBUFFER[CURSOR] is empty (and lbuffer=$LBUFFER at
that point).  I believe ((right-left == left+1)) when right=$CURSOR,
so should be a no-op compared to the original ((REGION_HIGHLIGHT ==
1)) case.  Disagree?