From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-36215-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 14323 invoked by alias); 18 Aug 2015 08:37:05 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 36215
Received: (qmail 13032 invoked from network); 18 Aug 2015 08:37:04 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.0
X-AuditID: cbfec7f4-f79c56d0000012ee-b5-55d2ec50b1f1
Date: Tue, 18 Aug 2015 09:26:43 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: UNDO_LIMIT_NO and its documentation
Message-id: <20150818092643.1aa9ce9b@pwslap01u.europe.root.pri>
In-reply-to: <150818000916.ZM28704@torch.brasslantern.com>
References: <150818000916.ZM28704@torch.brasslantern.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsVy+t/xy7oBby6FGry6Lm9xsPkhkwOjx6qD
	H5gCGKO4bFJSczLLUov07RK4MlZ/5iw4wFXRM/U2cwPjW/YuRk4OCQETie33DrBC2GISF+6t
	ZwOxhQSWMkpc25jcxcgFZM9gklj+rYkZwtnGKDHtRQ8LSBWLgKrEmsvXGEFsNgFDiambZoPZ
	IgLiEmfXngerERYwkDi5cDrYNl4Be4npn9+AbeAUsJJYPquXCWKbpcThexfAavgF9CWu/v3E
	BHGRvcTMK2cYIXoFJX5Mvgc2k1lAS2LztiZWCFteYvOat8wQc9QlbtzdzT6BUWgWkpZZSFpm
	IWlZwMi8ilE0tTS5oDgpPddQrzgxt7g0L10vOT93EyMkZL/sYFx8zOoQowAHoxIPb0XepVAh
	1sSy4srcQ4wSHMxKIrz6qUAh3pTEyqrUovz4otKc1OJDjNIcLErivHN3vQ8REkhPLEnNTk0t
	SC2CyTJxcEo1MEb7KrdVsC3iqDttY3TXTsjk+7v3l2/v/COW8L3q+KtleZZHSt1qTJafOhj1
	fee9+5uqpS5emCdQ7vU00C/zaBJD7OnCCnambb5bHA53FL29N0nM2dLE9ua29JdLdlz8Yrhj
	w71tLr/+mvHOn9e0Ps/r+eGV0vceza/jszz38uZPZ3HJxGCWolIlluKMREMt5qLiRAAqnwNE
	VQIAAA==

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