Re: UNDO_LIMIT_NO and its documentation

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 18 Aug 2015 00:09:16 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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