* zle_line_init_functions (Re: accept-line-and-down-history and push-input) [not found] ` <20101026161947.19279c58@pwslap01u.europe.root.pri> @ 2010-10-27 5:01 ` Bart Schaefer 2010-10-27 9:22 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2010-10-27 5:01 UTC (permalink / raw) To: zsh-workers [>workers] On Oct 26, 4:19pm, Peter Stephenson wrote: } Subject: Re: accept-line-and-down-history and push-input } } On Tue, 26 Oct 2010 07:55:44 -0700 } Bart Schaefer <schaefer@brasslantern.com> wrote: } > (I'm beginning to think that zle-line-init should be a builtin widget } > that calls an array of hook functions, ala precmd.) } } I've been thinking along those lines, except that the array of hook } functions would be the alternative to the widget, as with chpwd and } friends I don't much like the idea of having an array of *widget names*. What's the benefit of invoking a series of widgets, rather than having one widget that calls a series of functions? The context is the same either way (i.e., "zle" with no args returns zero status and you can access all the line editor variables) and all the work of creating and destroying thingys can be avoided. } i.e. you could still define zle-line-init if you wanted a } simple life but zle_line_init_functions could contain an additional set } of widgets. Wouldn't you still get that effect if zle-line-init was a builtin widget that you could override with your own via zle -N ? } Not sure how to keep the name of the array entirely within zle I don't know what you're reaching for, there. The array has to be outside of zle at some point or you can't assign anything to it ...? zle-line-init() { local f for f in $zle_line_init_functions do if [[ $PWS_users_15493 ]] then zle "$f" elif [[ $my_suggestion ]] then "$f" || break fi done } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input) 2010-10-27 5:01 ` zle_line_init_functions (Re: accept-line-and-down-history and push-input) Bart Schaefer @ 2010-10-27 9:22 ` Peter Stephenson 2010-10-27 15:40 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2010-10-27 9:22 UTC (permalink / raw) To: zsh-workers On Tue, 26 Oct 2010 22:01:02 -0700 Bart Schaefer <schaefer@brasslantern.com> wrote: > } I've been thinking along those lines, except that the array of hook > } functions would be the alternative to the widget, as with chpwd and > } friends > > I don't much like the idea of having an array of *widget names*. > What's the benefit of invoking a series of widgets, rather than > having one widget that calls a series of functions? It looks like the way other hooks work. 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. 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. Then all the widgets have to be predefined in the appropriate configuration file. (I imagine there would be a template C function where the widget examined its name.) Before, no widget needed to exist at all; the whole thing just required a single universal function and a simple function call for each hook and you only created widgets as needed. That's the system I want to extend. > The context is > the same either way (i.e., "zle" with no args returns zero status > and you can access all the line editor variables) and all the work > of creating and destroying thingys can be avoided. There's no work of creating and destroying thingies. Either the widget exists, in which cases it's already referenced, or it doesn't, in which case nothing is created and NULL returned. 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.e. you could still define zle-line-init if you wanted a > } simple life but zle_line_init_functions could contain an additional > set } of widgets. > > Wouldn't you still get that effect if zle-line-init was a builtin > widget that you could override with your own via zle -N ? Depends if you want the current behaviour as well. If someone submits a suggestion that uses zle-line-init directly, which is how the shell currently works, and someone else a suggestion that involves the hook function, which would be neater, they can't both work without modification. Of course two suggestions using zle-line-init need work combining anyway, but it's obvious in that case that the function/widget can't do two different things. It's less obvious --- particularly if you've happily been using an earlier version of the shell and not noticed the way the behaviour has changed --- that redefining zle-line-init causes other facilities to disappear. I don't want to have to keep explaining this. > } Not sure how to keep the name of the array entirely within zle > > I don't know what you're reaching for, there. The array has to be > outside of zle at some point or you can't assign anything to it ...? That depends on the interface, but I can't think of a better way than an array. -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input) 2010-10-27 9:22 ` Peter Stephenson @ 2010-10-27 15:40 ` Bart Schaefer 2010-10-31 21:54 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2010-10-27 15:40 UTC (permalink / raw) To: zsh-workers On Oct 27, 10:22am, Peter Stephenson wrote: } Subject: Re: zle_line_init_functions (Re: accept-line-and-down-history and } } On Tue, 26 Oct 2010 22:01:02 -0700 } Bart Schaefer <schaefer@brasslantern.com> wrote: } > What's the benefit of invoking a series of widgets, rather than } > having one widget that calls a series of functions? } } It looks like the way other hooks work. My point being that it may *look* like it, but really it doesn't *act* like it, because all the other hooks call shell functions but this one calls zle widgets. At the least the array name should be zle_line_init_widgets to make the distinction obvious, and the doc for add-zsh-hook should be updated. (Either way I suspect the internals of add-zsh-hook also need to be updated, because the current set of hooks have simpler base names.) Also either way I think zle_line_init_whatever should preserve the behavior of abandoning the remaining hooks if any one of them fails. } 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. } 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. If it's an array of shell function names, you define the function and put its name in the array like all other hooks. If it's an array of widget names, you must additionally remember to "zle -N ..." for every function to make it a recognized widget, or it will silently be skipped when the array is walked. I'm also somewhat concerned about what happens if one of the widgets in question has been installed with "zle -C" instead of "zle -N". In other contexts there are problems with normal widgets and completion widgets calling one another. Is completion context available at the time of zle-line-init? Incidentally, what happens on "zle send-break" in the 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. } If someone submits a suggestion that uses zle-line-init directly, } which is how the shell currently works, and someone else a suggestion } that involves the hook function, which would be neater, they can't } both work without modification. Yep, with you on that one now. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input) 2010-10-27 15:40 ` Bart Schaefer @ 2010-10-31 21:54 ` Peter Stephenson 2010-11-01 7:01 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2010-10-31 21:54 UTC (permalink / raw) To: zsh-workers On Wed, 27 Oct 2010 08:40:31 -0700 Bart Schaefer <schaefer@brasslantern.com> 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 <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input) 2010-10-31 21:54 ` Peter Stephenson @ 2010-11-01 7:01 ` Bart Schaefer 0 siblings, 0 replies; 5+ messages in thread From: Bart Schaefer @ 2010-11-01 7:01 UTC (permalink / raw) To: zsh-workers On Oct 31, 9:54pm, Peter Stephenson wrote: } } > 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. } } 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 Ah, and hmm. So there's no clever way to pull off the equivalent of (pseudo-code): zle -N hook-runner (){ local f; for f in ... } I.e., take an anonymous function that does what you want and make a user-defined widget out of it? ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-11-01 7:02 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <AANLkTin4qeNKcBt_TDzY2xt-XJ6aHVH257FOa6iriPSm@mail.gmail.com> [not found] ` <101026075546.ZM28500@torch.brasslantern.com> [not found] ` <20101026161947.19279c58@pwslap01u.europe.root.pri> 2010-10-27 5:01 ` zle_line_init_functions (Re: accept-line-and-down-history and push-input) Bart Schaefer 2010-10-27 9:22 ` Peter Stephenson 2010-10-27 15:40 ` Bart Schaefer 2010-10-31 21:54 ` Peter Stephenson 2010-11-01 7:01 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).