From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2742 invoked by alias); 3 Jun 2016 22:51:59 -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: 38594 Received: (qmail 26527 invoked from network); 3 Jun 2016 22:51:56 -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,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=pRUVAjAQ7jtFG5K/3St8C+LkyARFEN3zDqT0uWBYdBU=; b=wbXmurfXDINn4W2imC2KkRnVjPWTPT5QuxXgbR/jH7Rm/Dh9VRdGRKKuv1qsP9Yx4R X6RXswwEJoFw0zl+EsaFKpBczG3ccTrp8sRLl2jUTjA8mk++7AKy54HYQB2xFD4AEBMr OH2ySfAtcvsrd/9wRrtVWYVjy1iCaQBLZvpi5x563Dl3ZrIqPRrHeZJYLJ85CfAzm5HY 8YJO2UcyDmFxljGaNq18LA7jrWXU7W3on9LyaB5qP40QWhjABHtcy46hLclsjDdeLlzb r/nI5o4c/Vj7Ac9KzImfRL6T5HyToazpOZCDVA+Ag6nSwpPhFNtCXsOsDRr7Idbby8ep H5Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=pRUVAjAQ7jtFG5K/3St8C+LkyARFEN3zDqT0uWBYdBU=; b=TFFW66rU46exZLJUib0Y8jZUJ4WFYFDO8/8L4uUydTHfRtzPzMjIDqR3NAyZTTJWzN IkVO08XjtGMU1N4d+wQG8QhgoLoolM69toSLaYsGTbuggHaRnCnvUplL2svTnF1WnqPh RcFy9f6aMAo5hB+jYfxGFXdNYFgHbfVbEDMmavU+Y0p04FNtc2VfLZkt4gjpq+B9L+qH vrW4qrlKW79RgEOOtn0xVfln13/hgvZN48HcAhRu3G7ckf/zJAg7rrjYcliVwF3KSJRX TH5HYIq2Pn/kZhXpO81SaPlCl4e4ELPH5V0OZI8aqoDJnF5u4vnU048Bem/GN9Y4N8vN uIMg== X-Gm-Message-State: ALyK8tLkZiRpA3jCVY8xWGke9RL039+n5+c+/jRo066lBjGl+qtHsFFfe+pCnYNLeZNm6g== X-Received: by 10.98.2.80 with SMTP id 77mr8833999pfc.67.1464994314239; Fri, 03 Jun 2016 15:51:54 -0700 (PDT) From: Bart Schaefer Message-Id: <160603155154.ZM25057@torch.brasslantern.com> Date: Fri, 3 Jun 2016 15:51:54 -0700 In-Reply-To: <20160603204043.GA18181@tarsus.local2> Comments: In reply to Daniel Shahaf "Re: zle hook conventions (was Re: bracket-paste-magic ...)" (Jun 3, 8:40pm) References: <20160510085833.GA20332@cventin.lip.ens-lyon.fr> <160510125848.ZM1686@torch.brasslantern.com> <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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: zle hook conventions (was Re: bracket-paste-magic ...) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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]. 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. } 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. } 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. 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). } > Usage would be e.g. (inventing a function for example purposes): } > } > add-zle-hook-widget zle-line-pre-redraw 30:z-sy-h-redraw } } This appears to be a straightforward registrar API. Intentionally comparable to add-zsh-hook. } I would suggest making this idempotent by uniquifying the list of hooks } (in order to support 'source ~/.zshrc'). Cf. "crudely sketched", but it in fact does so, the extant_hooks local is declared with -U, so when assigned it will discard duplicates. } 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. } > 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. -- Barton E. Schaefer