State of the ZLE region across new prompts

State of the ZLE region across new prompts

[Bart Schaefer]

Consider:

    zle-line-finish() { CURSOR=0 MARK=$#BUFFER REGION_ACTIVE=1 }
    zle -N zle-line-finish

The idea here, such as it is, is to highlight the entire buffer before
it is executed.  (I was doing this to test something unrelated.)

With this in place, run a command, then when ZLE resumes at the next
prompt, start recalling commands with up-line-or-history.  Note that
they are highlighted.  I'm not entirely sure but I believe this means
the region is still active, not just that highlighting is confused.
Is REGION_ACTIVE intended to persist in this way?

Aside:  The documentation for the zle_highlight "region" context
discusses "calling set-mark-command with a negative numeric argument"
and "exchange-point-and-mark with a zero numeric argument" but does
not mention deactivate-region or assignments to REGION_ACTIVE.

Re: State of the ZLE region across new prompts

[Peter Stephenson]

On Mon, 11 Jul 2016 21:28:14 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Consider:
> 
>     zle-line-finish() { CURSOR=0 MARK=$#BUFFER REGION_ACTIVE=1 }
>     zle -N zle-line-finish
> 
> The idea here, such as it is, is to highlight the entire buffer before
> it is executed.  (I was doing this to test something unrelated.)
> 
> With this in place, run a command, then when ZLE resumes at the next
> prompt, start recalling commands with up-line-or-history.  Note that
> they are highlighted.  I'm not entirely sure but I believe this means
> the region is still active, not just that highlighting is confused.
> Is REGION_ACTIVE intended to persist in this way?

I think the problem is that region_active is set to 0 at the end of
zlecore(), so you're missing it when zle-line-finish is called.  This is
therefore an edge case.

It's presumably reasonable also to set it to 0 on any entry to the
top-level of ZLE at the start of zleread(). 

pws

Re: State of the ZLE region across new prompts

[Oliver Kiddle]

Bart wrote:
> With this in place, run a command, then when ZLE resumes at the next
> prompt, start recalling commands with up-line-or-history.  Note that
> they are highlighted.  I'm not entirely sure but I believe this means
> the region is still active, not just that highlighting is confused.
> Is REGION_ACTIVE intended to persist in this way?

Yes, the region is remaining active. We reset it before calling
zle-line-finish. The patch below instead resets it on entry, before
zle-line-init.

> Aside:  The documentation for the zle_highlight "region" context
> discusses "calling set-mark-command with a negative numeric argument"
> and "exchange-point-and-mark with a zero numeric argument" but does
> not mention deactivate-region or assignments to REGION_ACTIVE.

How about the following rewording? I don't think it is the right place
in the documentation to enumerate all the ways in which the region can
be activated and deactivated so this removes the part about numeric
arguments (which is covered under the respective widgets documentation).
"selection" is probably the most common term for what emacs calls the
region and vim's visual mode warrants a mention.

Oliver

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index f51eada..1642c5b 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2571,15 +2571,14 @@ When one of the incremental history search widgets is active, the
 area of the command line matched by the search string or pattern.
 )
 item(tt(region))(
-The region between the cursor (point) and the mark as set with
-tt(set-mark-command).  The region is only highlighted if it is active,
-which is the case if tt(set-mark-command) or tt(exchange-point-and-mark)
-has been called and the line has not been subsequently modified.  The
-region can be deactivated by calling tt(set-mark-command) with a
-negative numeric argument, or reactivated by calling
-tt(exchange-point-and-mark) with a zero numeric argument.  Note
-that whether or not the region is active has no effect on its
-use within widgets, it simply determines whether it is highlighted.
+The currently selected text. In emacs terminology, this is referred to as
+the region and is bounded by the cursor (point) and the mark. The region
+is only highlighted if it is active, which is the case after the mark
+is modified with tt(set-mark-command) or tt(exchange-point-and-mark).
+Note that whether or not the region is active has no effect on its
+use within emacs style widgets, it simply determines whether it is
+highlighted. In vi mode, the region corresponds to selected text in
+visual mode.
 )
 cindex(special characters, highlighting)
 cindex(highlighting, special characters)
diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index 472e326..ac31d4e 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -1159,7 +1159,6 @@ zlecore(void)
 
     }
 
-    region_active = 0;
     popheap();
 }
 
@@ -1292,6 +1291,7 @@ zleread(char **lp, char **rp, int flags, int context, char *init, char *finish)
     lastcol = -1;
     initmodifier(&zmod);
     prefixflag = 0;
+    region_active = 0;
 
     zrefresh();
 

Re: State of the ZLE region across new prompts

[Bart Schaefer]

On Jul 13, 12:13pm, Oliver Kiddle wrote:
}
} Yes, the region is remaining active. We reset it before calling
} zle-line-finish. The patch below instead resets it on entry, before
} zle-line-init.

Peter seemed to think it might be necessary to reset it in both places?
But I guess it would be useful if zle-line-finish sees the final state
of the region.

} How about the following rewording? I don't think it is the right place
} in the documentation to enumerate all the ways in which the region can
} be activated and deactivated

Seems fine to me.

Re: State of the ZLE region across new prompts

[Peter Stephenson]

On Wed, 13 Jul 2016 09:38:19 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jul 13, 12:13pm, Oliver Kiddle wrote:
> }
> } Yes, the region is remaining active. We reset it before calling
> } zle-line-finish. The patch below instead resets it on entry, before
> } zle-line-init.
> 
> Peter seemed to think it might be necessary to reset it in both places?

I don't actually know of a case where resetting it on exit, too, is
going to add to the further spreading of joy and contentment.

pws