UNDO_LIMIT_NO and its documentation

UNDO_LIMIT_NO and its documentation

[Bart Schaefer]

The doc says:

     A typical use of this variable in a widget function is as follows:

          integer save_limit=$UNDO_LIMIT_NO
          UNDO_LIMIT_NO=$UNDO_CHANGE_NO
          {
            # Perform some form of recursive edit.
          } always {
            UNDO_LIMIT_NO=save_limit
          }

Firstly, why not just

	local UNDO_LIMIT_NO=$UNDO_CHANGE_NO

and allow function scoping to restore it?  It's not a special.

Secondly, declaring "integer save_limit" means that save_limit will have
a default of zero, but UNDO_LIMIT_NO has a default of unset.  So when the
assignment back to UNDO_LIMIT_NO is done, it'll change state from unset
to zero.  Does that matter?

Re: UNDO_LIMIT_NO and its documentation

[Peter Stephenson]

On Tue, 18 Aug 2015 00:09:16 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> The doc says:
> 
>      A typical use of this variable in a widget function is as follows:
> 
>           integer save_limit=$UNDO_LIMIT_NO
>           UNDO_LIMIT_NO=$UNDO_CHANGE_NO
>           {
>             # Perform some form of recursive edit.
>           } always {
>             UNDO_LIMIT_NO=save_limit
>           }
> 
> Firstly, why not just
> 
> 	local UNDO_LIMIT_NO=$UNDO_CHANGE_NO
> 
> and allow function scoping to restore it?

As noted in the comments when the patch appeared, you'd need double
function scope because of the way ZLE widgets work.  I couldn't be
bothered to explain, but surrounding the code with (){ ... } should be
OK in principle.

> It's not a special.

All ZLE parameters are special, but removable.  See makezleparams().

> Secondly, declaring "integer save_limit" means that save_limit will have
> a default of zero, but UNDO_LIMIT_NO has a default of unset.  So when the
> assignment back to UNDO_LIMIT_NO is done, it'll change state from unset
> to zero.  Does that matter?

It should work fine, but I can't find any evidence in zle_params.c that
UNDO_LIMIT_NO is unset; only NUMERIC has that behaviour at the moment.
Either it's present as an integer variable or it isn't.

pws

Re: UNDO_LIMIT_NO and its documentation

[Peter Stephenson]

On Tue, 18 Aug 2015 09:26:43 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> > Firstly, why not just
> > 
> > 	local UNDO_LIMIT_NO=$UNDO_CHANGE_NO
> > 
> > and allow function scoping to restore it?
> 
> As noted in the comments when the patch appeared, you'd need double
> function scope because of the way ZLE widgets work.  I couldn't be
> bothered to explain, but surrounding the code with (){ ... } should be
> OK in principle.

I think this works.

pws

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 697b636..c06e226 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -971,14 +971,12 @@ to use `tt(zle undo) var(change)' in a widget to undo beyond
 that point; in that case, it will not be possible to undo at
 all until tt(UNDO_LIMIT_NO) is reduced.  Set to 0 to disable the limit.
 
-A typical use of this variable in a widget function is as follows:
+A typical use of this variable in a widget function is as follows (note
+the additional function scope is required):
 
-example(integer save_limit=$UNDO_LIMIT_NO
-UNDO_LIMIT_NO=$UNDO_CHANGE_NO
-{
+example(LPAR()RPAR() {
+  local UNDO_LIMIT_NO=$UNDO_CHANGE_NO
   # Perform some form of recursive edit.
-} always {
-  UNDO_LIMIT_NO=save_limit
 })
 )
 vindex(WIDGET)