From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26631 invoked by alias); 4 Jun 2016 16:57:28 -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: 38608 Received: (qmail 23210 invoked from network); 4 Jun 2016 16:57:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Sat, 04 Jun 2016 16:57:22 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: zle hook conventions (was Re: bracket-paste-magic ...) Message-ID: <20160604165722.GA13730@tarsus.local2> References: <20160513092348.GB18186@zira.vinc17.org> <20160513222039.GA2425@tarsus.local2> <20160514030031.GA2530@tarsus.local2> <20160519211458.GD8007@tarsus.local2> <160602000600.ZM14708@torch.brasslantern.com> <20160603204043.GA18181@tarsus.local2> <160603155154.ZM25057@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160603155154.ZM25057@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Fri, Jun 03, 2016 at 15:51:54 -0700: > On Jun 3, 8:40pm, Daniel Shahaf wrote: > } > } I think it is possible for a plugin to hook into zle without interfering > } with other plugins' hooks, without assuming anything about those other > } plugins. z-sy-h's hooking code attempts to achieve that > > Yes, but (a) it's convoluted (b) it doesn't solve the ordering problem > [whichever plugin is sourced last gets its wrapper outermost] (c) it > is fragile in cases such as reloading a plugin [load A, load B, then > load A again, and now you have A() { B() { A() { ... } } } wrapping]. > Agreed on all counts. (Your point (c) is identical to the one I mentioned in the footnote of my previous mail.) > Plus, I thought the whole point of this conversation was to consider > ways to avoid having to do that kind of thing, because most plugins > are a lot more naive than z-sy-h. > Of course. I once considered abstracting away the hooking strategy z-sy-h uses into a separate, reusable component. I'm already convinced that add-zle-hook-widget is a far better design for such a reusable component, but that doesn't stop me from mentioning which other alternatives I had considered. > } I think you're saying: if one plugin uses add-zle-hook-widget(), then > } other plugins can coexist with that plugin by also using > } add-zle-hook-widget(). > > Again yes, but also: if no plugin uses add-zle-hook-widget because it > requires zsh-5.X for some X >=3 and those plugins want to keep working > in zsh-4+, then we might as well never have introduced the feature. > If we're taking the position that the feature is useful, we should > design it in such a way that plugin writers want to adopt it. > Of course. That implies, for example, that add-zle-hook-widget should be written to be backwards compatible with older versions of zsh, even if its source lives in the zsh-5.3 source tree; and we could recommend to downstream packagers to backport it to their zsh-5.(≤2) packages, etc.. > } I'm a bit wary of imposing dependencies on other plugins. Might there > } be a valid reason for those fourth-party plugins to prefer not to use > } add-zle-hook-widget? > > You seem to be arguing in circles here. This is back to supporting the > position of throwing up our hands and doing nothing because we can't > (or shouldn't) make everyone do the same thing. > I'm not proposing that we do nothing. I am simply trying to ensure that our outcome will be a design that plugin authors will in fact adopt. > Plugins that don't want to use the convention are in no different boat > than they always were: They either must be clever like z-sy-h, or they > simply break (or cause breakage) by being naive, and it's then up to > the user who's installing them to work it out (which was my original > point about paying attention to ~/.zshrc when updating a plugin). > Indeed. For what it's worth, this concern is not academic; there is in fact a third-party plugin that causes segfaults because of a bug in its zle hooking. (I've sent them a patch.) > } With my plugin author perspective, if I were to add a dependency on this > } function, I'd want it to be easily available for users to install. > } Where would add-zle-hook-widget's implementation live? In Functions/ in > } the zsh tree, or as a third-party project? > > I'd presume that if the convention were agreed upon, we'd ship it with > the "standard" set of autoloadable functions alongside (or even packed > with, in some way) add-zsh-hook. > Perfect. I'd be happy to agree on add-zle-widget-hook. (I have a few localised changes to propose, by the way, once it loses its "crude sketch" status.) > } > zstyle -g extant_hooks "$hook" widgets > } > extant_hooks+=("$@") > } > zstyle -- "$hook" widgets "${extant_hooks[@]}" > } > } Why use zstyle's instead of declaring a global array and appending to it? > > Mostly to be able to use the widget names directly without having to > remove hyphens or convert to underscores. Partly, to avoid polluting > the parameter namespace further. Also to demonstrate that zstyle is > not just a quaint side-effect of the completion system. The last point resonates with me: I've felt for some time that I could put zstyle to use, but haven't quite pinned how. Cheers, Daniel