From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23117 invoked from network); 21 May 2004 20:06:23 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 21 May 2004 20:06:23 -0000 Received: (qmail 6365 invoked from network); 21 May 2004 20:06:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 21 May 2004 20:06:10 -0000 Received: (qmail 6495 invoked by alias); 21 May 2004 20:06:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19975 Received: (qmail 6485 invoked from network); 21 May 2004 20:06:07 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 21 May 2004 20:06:04 -0000 Received: (qmail 6241 invoked from network); 21 May 2004 20:06:04 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO binome.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 21 May 2004 20:06:02 -0000 Received: by binome.blorf.net (Postfix, from userid 1000) id 2C8BF2528; Fri, 21 May 2004 13:06:01 -0700 (PDT) Date: Fri, 21 May 2004 13:06:00 -0700 From: Wayne Davison To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: [PATCH] local history support, take 2 Message-ID: <20040521200600.GA12822@blorf.net> References: <20040521013738.GC31267@blorf.net> <5174.1085130941@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5174.1085130941@csr.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Fri, May 21, 2004 at 10:15:41AM +0100, Peter Stephenson wrote: > Is this going to be optional eventually? Yeah, I think that it should be optional just to be more flexible -- I can imagine someone wanting to call a push in a function without the auto-pop being forced upon them. I've added your earlier suggestion of the option "-a" to indicate that an automatic pop is desired. > You can also reject attempts to use `fc -P' if the history is marked > for automatic restoration which gets around the other problem. Actually, manually popping an automatic history doesn't cause any problems in the current code (the auto-pop of the history list happens prior to the restoration of local variables, so the early pop causes no problems that aren't present for the auto-pop). > I think it needs to be documented that if you're using commands you > shouldn't touch the variables by hand, otherwise confusion like this > is inevitable. It's fine if the user tweaks the values after a history push because they're just manipulating the current history buffer. The only problem comes in if they declare a variable to be local in a way that conflicts with the restoration order. I'm advising users to either omit marking the variables as local, or to declare them local at the top of the function and use the automatic-pop form of fc. (The other sequence that works fine is calling a non-automatic `fc -p' prior to localization, and then calling `fc -P' from outside the function, but I don't think we need to tell the user that.) I've checked in my updated version. We can continue to improve it, as desired, but I think it works quite well now. ..wayne..