From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27194 invoked from network); 17 Jan 2009 19:07:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 17 Jan 2009 19:07:12 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 57561 invoked from network); 17 Jan 2009 19:07:08 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jan 2009 19:07:08 -0000 Received: (qmail 13038 invoked by alias); 17 Jan 2009 19:07:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26349 Received: (qmail 13029 invoked from network); 17 Jan 2009 19:07:02 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jan 2009 19:07:02 -0000 Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by bifrost.dotsrc.org (Postfix) with ESMTP id 0A42E80271F0 for ; Sat, 17 Jan 2009 20:06:58 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173009.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KDM008L5Q7KMPF7@vms173009.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 17 Jan 2009 13:02:12 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n0HJ6qeQ008794 for ; Sat, 17 Jan 2009 11:06:53 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0HJ6kQr008793 for zsh-workers@sunsite.dk; Sat, 17 Jan 2009 11:06:46 -0800 Date: Sat, 17 Jan 2009 11:06:46 -0800 From: Bart Schaefer Subject: Re: problem with push-line-or-edit and precmd? In-reply-to: To: zsh-workers@sunsite.dk Message-id: <090117110646.ZM8792@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <18801.2149.303884.532633@gargle.gargle.HOWL> <090116200852.ZM22480@torch.brasslantern.com> Comments: In reply to Greg Klanderman "Re: problem with push-line-or-edit and precmd?" (Jan 17, 1:39am) X-Virus-Scanned: ClamAV 0.92.1/8873/Sat Jan 17 04:33:31 2009 on bifrost X-Virus-Status: Clean On Jan 17, 1:39am, Greg Klanderman wrote: } } So this is only a problem for push-input and push-line-or-edit? Yes. } I know it might not be the most elegant solution, but could some } global be set to inhibit the running of precmd and/or clear the error } status when these commands are used? Let's talk a little about the wider context. The trouble, as I now recall, is this: Controlling the whole "editor session" is the zsh command parser. It's asked by the ultimate top-level command loop to read one command from the shell input; this in turn invokes ZLE. When you hit accept-line at the end of that first line of a multi-line construct, control returns to the parser, which discovers that it doesn't yet have a fully formed command. The parser sets up the prompt level state, etc., and then starts a new ZLE "session" to get the next chunk of the command. This means that the only way for ZLE to get back control at the start of the multi-line construct is to force the *parser* to abandon *its* idea of what has been read so far, and restart as a new command. And the only [both relatively clean and already implemented] way to force the parser to restart is to convince it that the user interrupted the editor, i.e., to set errflag and let the parser deal with it. This therefore means that it's impossible for a user-defined widget to use push-input, or push-line-or-edit, and then proceed with other zle activities, because as soon as one of those builtins has been called the entire editor and parser state is for all useful purposes gone. Even if we implemented a global flag to tell the parser "hey, this is not really an error, pretend nothing happened" it still doesn't solve the underlying problem that in order to reset the parser state you have to abandon the widget in progress and unwind the call stack.