From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21446 invoked by alias); 18 Aug 2015 09:17:44 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36216 Received: (qmail 18918 invoked from network); 18 Aug 2015 09:17:43 -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: cbfec7f5-f794b6d000001495-bc-55d2f830e8c7 Date: Tue, 18 Aug 2015 10:17:34 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: UNDO_LIMIT_NO and its documentation Message-id: <20150818101734.2a0ea7e9@pwslap01u.europe.root.pri> In-reply-to: <20150818092643.1aa9ce9b@pwslap01u.europe.root.pri> References: <150818000916.ZM28704@torch.brasslantern.com> <20150818092643.1aa9ce9b@pwslap01u.europe.root.pri> 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/xa7oGPy6FGix5Z2VxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mj50r2QtaOCquPHEr4GxkaOLkZNDQsBE4vyDBcwQtpjEhXvr 2boYuTiEBJYySjyduJgRwpnBJHH+1UJ2CGcbo8TRRefYQFpYBFQlNk7fxwpiswkYSkzdNJsR xBYREJc4u/Y8C4gtLGAgcXLhdHYQm1fAXuL22yNgNqeAg8Sc92uAVnMADc2XmNCqBRLmF9CX uPr3ExPERfYSM6+cYYRoFZT4Mfke2EhmAS2JzduaWCFseYnNa96CfSAkoC5x4+5u9gmMQrOQ tMxC0jILScsCRuZVjKKppckFxUnpuUZ6xYm5xaV56XrJ+bmbGCEh+3UH49JjVocYBTgYlXh4 K/IuhQqxJpYVV+YeYpTgYFYS4dVPBQrxpiRWVqUW5ccXleakFh9ilOZgURLnnbnrfYiQQHpi SWp2ampBahFMlomDU6qBcUsim/W1TFN2584Yr+cXpixVU7is//3TiiyXjt1tNr0nnrNblaWv Pqj2fznTQqUso3+7XWZVfC4JiNU9uJi9qML1/IH7ptIZNwJOlf+xuF1mbf385Yu8805pT8O2 bde4rcDS9zlozeovh/mdSyMyuzdc5mRyvLVkS9DeaUWnv8Y94k9U3D53rxJLcUaioRZzUXEi AD7uG9dVAgAA On Tue, 18 Aug 2015 09:26:43 +0100 Peter Stephenson 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)