From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5237 invoked by alias); 5 Mar 2015 13:59:04 -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: 34653 Received: (qmail 19663 invoked from network); 5 Mar 2015 13:59:00 -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 X-AuditID: cbfec7f5-b7fc86d0000066b7-5f-54f8608d36b5 Date: Thu, 05 Mar 2015 13:58:30 +0000 From: Peter Stephenson To: zsh workers Subject: Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context Message-id: <20150305135830.0e0e5d65@pwslap01u.europe.root.pri> In-reply-to: <20150305095944.5bce20ab@pwslap01u.europe.root.pri> References: <20150305095944.5bce20ab@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+NgFlrCLMWRmVeSWpSXmKPExsVy+t/xy7q9CT9CDG6eY7Q42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGT9a7jIWTOKrOPx8GVMD40XuLkYODgkBE4lH81i7GDmBTDGJ C/fWs4HYQgJLGSVe3BLqYuQCspcwSSy//poJwtnGKDF3wUuwKhYBVYmmV/+ZQGw2AUOJqZtm M4LYIkDx5u//WEBsYQFHiWOLz4LV8ArYS5xd/oEFZDGngINE93VniJkdjBI7nz0Dq+cX0Je4 +vcTE8RF9hIzr5xhhOgVlPgx+R5YDbOAlsTmbU2sELa8xOY1b5khrlaXuHF3N/sERqFZSFpm IWmZhaRlASPzKkbR1NLkguKk9FwjveLE3OLSvHS95PzcTYyQkP26g3HpMatDjAIcjEo8vAVJ 30KEWBPLiitzDzFKcDArifBeifwRIsSbklhZlVqUH19UmpNafIiRiYNTqoHx6OeKw5/WXXQU mXfF8mHeLK2EZt2HlxicJtUaXAlZvk75RLfIhhUa3No3D62odZYI430v19AsqHuoIa6yMV/8 2LfZSU2R6T9LJsl8esNXdOZbcfibtuP6P4qWL6q4G/jm2IEujqwUX1EhU9Ydbbe+2oZO9NWd WdSYrfz8+FGDP+oPMs0D3wgrsRRnJBpqMRcVJwIAPXaC8zcCAAA= On Thu, 5 Mar 2015 09:59:44 +0000 Peter Stephenson wrote: > Having the variable set in special cases is a bit of a headache, I > agree, since you don't necessarily know they're there, even if there are > ways round. > > It would be tempting to have a different variable for the vared case > such as ZLE_VARED_ABORTED. This would same to cover all the bases, except for the case where someone really wants to use the same variable to deal with vared and the shell command line. Mikael's experience suggests that's not the most obvious or convenient case. pws diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo index dd8e628..b8b9b8c 100644 --- a/Doc/Zsh/zle.yo +++ b/Doc/Zsh/zle.yo @@ -2223,7 +2223,8 @@ item(tt(send-break) (^G ESC-^G) (unbound) (unbound))( Abort the current editor function, e.g. tt(execute-named-command), or the editor itself, e.g. if you are in tt(vared). Otherwise abort the parsing of the current line; in this case the aborted line is available in the shell -variable tt(ZLE_LINE_ABORTED). +variable tt(ZLE_LINE_ABORTED). If the editor is aborted from within +tt(vared), the variable tt(ZLE_VARED_ABORTED) is set. ) tindex(run-help) item(tt(run-help) (ESC-H ESC-h) (unbound) (unbound))( diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c index a2f48e1..cec44c0 100644 --- a/Src/Zle/zle_main.c +++ b/Src/Zle/zle_main.c @@ -1253,7 +1253,9 @@ zleread(char **lp, char **rp, int flags, int context, char *init, char *finish) zlecore(); if (errflag) - setsparam("ZLE_LINE_ABORTED", zlegetline(NULL, NULL)); + setsparam((zlecontext == ZLCON_VARED) ? + "ZLE_VARED_ABORTED" : + "ZLE_LINE_ABORTED", zlegetline(NULL, NULL)); if (done && !exit_pending && !errflag) zlecallhook(finish, NULL);