Re: zle hook conventions (was Re: bracket-paste-magic ...)

[Daniel Shahaf <d.s@daniel.shahaf.name>]

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