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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Aug 21, 2023 at 7:14 AM Christoffer Lundell
<christofferlundell@xxxxxxxxxxxxxx> wrote:
>
> Change behavior of edit-command in visual-line mode to edit command linewise
> instead of only allowing editing of the text between MARK and CURSOR.
>
> The rationale being that in visual-line mode the entire line(s) appears visually
> selected, and so I expect edit-command to operate on the entire line(s).

This seems quite reasonable.

> With this patch everything visually selected will be brought into the editor,
> while preserving cursor position where applicable.

This looks OK, but I think it can be made a bit clearer by using the
(i)/(I) subscript indexing flags rather than ${(SB)...}.  This might
just be my own bias, but those flags already return the "correct"
values when the search fails, so the extra marks and offsets and tests
are not needed.

I'm no longer a regular vi user (and never used line-wise mode years
ago when I was) so I do have a couple of questions about your index
computations ...

> +  left=${(SB)${BUFFER[1,mark_left]}%$'\n'}
> +  (( left != 1 )) && (( left++ ))

This I follow.  If the (SB) is replaced with ...

  local nl=$'\n'
  left=${${BUFFER[1,mark_left]}[(I)$nl]}

... then $left can unconditionally be incremented because the result
will be 0 rather than 1 if there is no newline in the range.  Unless
of course  [[ $BUFFER[1] == $nl ]] in which case your version includes
that newline in the selection and mine doesn't.  Which one is correct?

The $nl is introduced because subscript brackets are parsed like
double quotes, which means you can't use $'\n' inside them.

> +  offset_right=${(SB)${BUFFER[mark_right+1,-1]}#$'\n'}

This I'm not sure of -- why mark_right+1 ?  In this direction that
seems to mean that if the mark is exactly on the newline, you're
extending to the following newline.  Is that how it's meant to work?

> +  if (( offset_right == 1 )); then
> +    right=$#BUFFER
> +  else
> +    (( right = mark_right + offset_right - 1 ))
> +  fi

I would do ...

  right=${${BUFFER[mark_right,-1]}[(i)$nl]}
  (( right += mark_right - 1 ))

... which returns the length of the range plus one if there is no
newline, so $right may be unconditionally decremented.  Again, though,
I would expect that if mark_right is on the newline, we stop there,
not skip it and find the next.

With my version the remaining tweak needed is to decrement $right a
second time when [[ $BUFFER[right] == $nl ]] because use of "$(<$1)"
trims a trailing newline when reading the back the editor file.

Unwinding a bit to remove the additional locals, the result is the attached.

diff --git a/Functions/Zle/edit-command-line b/Functions/Zle/edit-command-line
index 5f7ea321f..c9b140378 100644
--- a/Functions/Zle/edit-command-line
+++ b/Functions/Zle/edit-command-line
@@ -11,7 +11,7 @@ local left right prebuffer buffer=$BUFFER lbuffer=$LBUFFER
 local TMPSUFFIX=.zsh
 # set up parameters depending on which context we are called from,
 # see below comment for more details
-if (( REGION_ACTIVE )); then
+if (( REGION_ACTIVE == 1 )); then
   if (( CURSOR < MARK )); then
     left=$CURSOR right=$MARK
     lbuffer=
@@ -19,7 +19,23 @@ if (( REGION_ACTIVE )); then
     left=$MARK right=$CURSOR
     lbuffer[right-left,-1]=
   fi
-  (( left++ ))
+  buffer=$BUFFER[++left,right]
+elif (( REGION_ACTIVE == 2 )); then
+  local nl=$'\n'
+  if (( CURSOR < MARK )); then
+    left=${${BUFFER[1,CURSOR]}[(I)$nl]}
+    right=${${BUFFER[MARK,-1]}[(i)$nl]}
+    (( right += MARK ))
+  else
+    left=${${BUFFER[1,MARK]}[(I)$nl]}
+    right=${${BUFFER[CURSOR,-1]}[(i)$nl]}
+    (( right += CURSOR ))
+  fi
+  lbuffer=$BUFFER[1,++left]
+  if [[ $BUFFER[--right] = $nl ]]; then
+    # Keep the newline because "$(<$1)" below trims it
+    (( --right ))
+  fi
   buffer=$BUFFER[left,right]
 elif (( ! ZLE_RECURSIVE )); then
   prebuffer=$PREBUFFER