From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: zle hook conventions (was Re: bracket-paste-magic ...)
Date: Fri, 03 Jun 2016 20:40:43 +0000 [thread overview]
Message-ID: <20160603204043.GA18181@tarsus.local2> (raw)
In-Reply-To: <160602000600.ZM14708@torch.brasslantern.com>
Bart Schaefer wrote on Thu, Jun 02, 2016 at 00:06:00 -0700:
> On May 19, 9:14pm, Daniel Shahaf wrote:
> }
> } Bart Schaefer wrote on Sun, May 15, 2016 at 04:59:27 -0700:
> } > Hence I also think that a plugin registry for the special zle hook
> } > widgets ought to be implemented externally, and the plugins agree to
> } > make use of it -- because if the plugins don't follow such a
> } > convention then the user has to update .zshrc in lockstep with the
> } > plugin installation anyway.
> }
> } I don't follow your reasoning: whether .zshrc needs to be updated
> } manually is orthogonal to how the plugin hooks into zle.
>
> If you have two or more plugins referenced from .zshrc, and not all of
> them follow the same convention for how to hook into zle, then any time
> one of them changes the user has to make sure it hasn't now interfered
> with the hooks of the others.
>
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 (modulo a known
bug†):
https://github.com/zsh-users/zsh-syntax-highlighting/blob/47144ad9742a948337c6a0e315474b5fea94a6d3/zsh-syntax-highlighting.zsh#L243-L272
That said, I agree that having some an array of functions that are to be
called by a central dispatcher — as with add-zsh-hook and
add-zle-widget-hook — would sidestep this "devise a perfectly composable
wrapper" problem entirely.
> } It is about the mechanism used by zsh to find and run the code that
> } _installs_ the zle hook, not about whether said installation is done
> } by [...]
>
> That's exactly my point: A convention no one uses is no better than no
> convention at all, even if there's specialty C code instead of shell
> code.
>
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().
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?
> Further, an externally-defined convention can be made backward-compatible
> to at least some older versions of zsh.
>
Good point.
> } I'm happy to keep this external, although if widgets shipped with zsh
> } used this "external" plugin, it'd probably become de facto official.
>
> Currently there aren't any functions shipped with zsh that would need
> this. The only references to the zle-* hooks in the shipped code are
> tests for whether zle-line-init is currently in progress, not for using
> any hooks to set up specific behavior.
>
Currently, no. However, this subthread started when you mentioned (in
38485) that url-quote-magic considered hooking to zle-line-pre-redraw.
> Crudely sketched, I'm thinking of something like this:
> ⋮
> Usage would be e.g. (inventing a function for example purposes):
>
> add-zle-hook-widget zle-line-pre-redraw 30:z-sy-h-redraw
>
> If you leave out the number: prefix, it's assumed you don't care in
> what order it executes, but it'll always be after the ones that do
> have number prefixes. Left up to the plugins to work out what number
> they need/get. Note you can call the same widget more than once by
> adding it with two different numbers.
This appears to be a straightforward registrar API.
I would suggest making this idempotent by uniquifying the list of hooks
(in order to support 'source ~/.zshrc').
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?
> 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?
Many thanks,
Daniel
† The linked excerpt's infinite recursion guard doesn't currently catch
the case that $cur_widget is a user-defined widget and ${widgets[$cur_widget]#user:}
is a function that calls «_zsh_highlight_widget_${cur_widget}»; however,
this should be simple to fix by embedding a nonce (e.g., $EPOCHREALTIME)
in the name of the wrapper functions and widgets.
next prev parent reply other threads:[~2016-06-03 20:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 20:53 bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic) Axel Beckert
2016-05-08 18:50 ` Bart Schaefer
2016-05-09 14:13 ` Vincent Lefevre
2016-05-09 15:41 ` Bart Schaefer
2016-05-10 8:58 ` Vincent Lefevre
2016-05-10 19:58 ` Bart Schaefer
2016-05-13 9:23 ` Vincent Lefevre
2016-05-13 11:06 ` Bart Schaefer
2016-05-13 12:19 ` Vincent Lefevre
2016-06-02 7:20 ` undo problems/crashes (was Re: bracket-paste-magic ...) Bart Schaefer
2016-05-13 22:20 ` bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic) Daniel Shahaf
2016-05-14 1:33 ` Mikael Magnusson
2016-05-14 3:00 ` Daniel Shahaf
2016-05-15 11:59 ` Bart Schaefer
2016-05-19 21:14 ` Daniel Shahaf
2016-06-02 7:06 ` zle hook conventions (was Re: bracket-paste-magic ...) Bart Schaefer
2016-06-03 20:40 ` Daniel Shahaf [this message]
2016-06-03 22:51 ` Bart Schaefer
2016-06-04 16:57 ` Daniel Shahaf
2016-06-10 17:36 ` Daniel Shahaf
2016-06-10 19:51 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160603204043.GA18181@tarsus.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).