From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13897 invoked by alias); 31 Oct 2010 22:56:20 -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: 28382 Received: (qmail 21920 invoked from network); 31 Oct 2010 22:56:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.56 as permitted sender) Date: Sun, 31 Oct 2010 21:54:50 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input) Message-ID: <20101031215450.06b7ed7b@pws-pc.ntlworld.com> In-Reply-To: <101027084031.ZM31108@torch.brasslantern.com> References: <101026075546.ZM28500@torch.brasslantern.com> <20101026161947.19279c58@pwslap01u.europe.root.pri> <101026220102.ZM29774@torch.brasslantern.com> <20101027102216.16719058@pwslap01u.europe.root.pri> <101027084031.ZM31108@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=3ENABmdyEd/Fm7fR7+mZIuMDn6+IErAeEhlfWBImZFk= c=1 sm=0 a=9HuqTt0HTkcA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=NLZqzBF-AAAA:8 a=9q55AhNT12S6c6ef_gkA:9 a=YmJdeAFr97qibf0UiaEA:7 a=TVjFGr77Dyduy8JwXri7wojL4VkA:4 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Wed, 27 Oct 2010 08:40:31 -0700 Bart Schaefer wrote: > Also either way I think zle_line_init_whatever should preserve the > behavior of abandoning the remaining hooks if any one of them fails. That's easy and sensible --- I interpret "fails" as errflag != 0. > } If you have the behaviour buried in the widget itself it looks > } different from the other hooks which are independent of the definition > } of the base function. > > That's a different issue, and one where now that you point it out, I > agree with you. Rather than have zle-line-init itself walk through > the array, I'd amend to suggest a second nameless widget that can't > be replaced by "zle -N" whose purpose is to walk the array, following > the structure of your patch in user/15493 more closely. This isn't so different from what I proposed, and has the attractive feature that you only have the one namespace --- there's no point in having functions named differently from widgets if you're explicitly saying which to call, so that makes sense. An unnamed widget doesn't fit in well with the scheme of defining widgets, so I called it hook-runner. Alas, it still doesn't work. Because the widget is built-in, there's no point at which the zle parameters get added --- the hierarchy is builtin widget -> ordinary shell function --- so you can't see (e.g.) $KEYMAP, which is crucial to being able to handle zle-keymap-select neatly. So we need a function widget at the top level, as in my original proposal, or rewrite the internals, a route I'm not going to take --- that doesn't mean it's not workable, it just means I've decided I've tried hard enough at this point. > } Also, if you do it the other way, within zle you have to do something > } more complicated than I've just written that performs an extra level > } of indirection to call a whole heap of other widgets. > > I'm not following the origin of this whole heap of other widgets. > > } Then all the widgets have to be predefined in the appropriate > } configuration file. > > We must have disconnected somewhere because this is (a previously > unstated) part of my objection to a zle_line_init_widgets array. The point was that in your original suggestion you'd need *always* to have widgets called zle-line-init etc., even if they didn't do anything, just to run the hooks, even if you hadn't defined any. In my scheme you'd only have widgets defined when they'd be run in a hook. > } It doesn't make sense to me to have a whole new set of callable zle > } functions that aren't widgets, it creates a new category that blurs > } the boundaries. > > I think that's a barn from which the horse has already escaped; we > already special tests used in traps when called from zle, various > "Utility Functions" like modify-current-argument, and of course the > entire collection of completers and their helpers. In these cases the functions aren't called from zle directly. There's at least one case where a function is, however, which is a zle -F handler; but that doesn't do editing, it just handles input, and is deliberately written so the function doesn't interact with the editor. I agree the distinctions are a bit blurry for your average user, though. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/