From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5674 invoked by alias); 9 Oct 2012 15:54:26 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17317 Received: (qmail 29417 invoked from network); 9 Oct 2012 15:54:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) Date: Tue, 09 Oct 2012 16:44:15 +0100 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: bug in replace-string: widget loses characters Message-id: <20121009164415.1ad853e3@pwslap01u.europe.root.pri> In-reply-to: <121009082425.ZM29621@torch.brasslantern.com> References: <121009082425.ZM29621@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-TM-AS-MML: No On Tue, 09 Oct 2012 08:24:25 -0700 Bart Schaefer wrote: > On Oct 9, 3:34pm, Peter Stephenson wrote: > } > } The one side effect is that $UNDO_CHANGE_NO is different each time > it's } read. I could fix that if anyone cared, but if it helped you > could sort } of look on it as a feature: you are guaranteed that all > recorded change } points are unique and monotonically increasing > whether or not the line } itself was changed. > > I think this is OK, but I suppose there might be a case where one > wanted to be able to detect whether any changes had occurred between > state X and state Y, e.g. previously > > local current_undo=$UNDO_CHANGE_NO > # ... some stuff potentially happens ... > if (( current_undo == UNDO_CHANGE_NO )) > then > # nothing happened? > fi > > Is there another way to detect this? It's probably not a common thing > to care about so perhaps not worth a lot of effort. Well, with the current set-up you'd be guaranteed that the second call would be an increment of 1 from the first. You need to be careful how many times you call UNDO_CHANGE_NO, though, so it's not very robust. If it seems a preferable way of doing it, it's straightforward to add a flag saying who last incremented the number, so it only gets incremented the first time. The change numbers for the edits are hidden, so that ought to do the trick. -- Peter Stephenson Consultant, Software Tel: +44 (0)1223 434724 Samsung Cambridge Solution Centre St John's House, St John's Innovation Park, Cowley Road, Cambridge, CB4 0ZT, UK