Extending zsh hooks

Extending zsh hooks

[Gregory Seidman]

I discovered add-zsh-hook not too long ago and I've made some good use of
it, but I have a similar application for a new kind of hook. I'd like to
modify the add-zsh-hook implementation to allow custom named hooks with a
flag, e.g. add-zsh-hook -f myhook myfunc.

While I've found https://sourceforge.net/p/zsh/code/ci/master/tree/ I am a
lot more familiar with contributing to FLOSS on GitHub by forking and a PR.
Does it work the same way on SourceForge? (Also, my SourceForge account
seems to have gone away, maybe because I haven't used it in over a decade,
but I can make a new one.)

--Gregory

Re: Extending zsh hooks

[Lawrence Velázquez]

On Tue, Nov 7, 2023, at 6:31 PM, Gregory Seidman wrote:
> While I've found https://sourceforge.net/p/zsh/code/ci/master/tree/ I am a
> lot more familiar with contributing to FLOSS on GitHub by forking and a PR.
> Does it work the same way on SourceForge? (Also, my SourceForge account
> seems to have gone away, maybe because I haven't used it in over a decade,
> but I can make a new one.)

The usual process is to propose changes on this list and include
any patches inline or as an attachment.  You can find many examples
in the archive (e.g., <https://www.zsh.org/mla/workers/2023/>).

-- 
vq

PATCH: custom zsh hooks (was Re: Extending zsh hooks)

[Gregory Seidman]

On Tue, Nov 07, 2023 at 09:35:30PM -0500, Lawrence Velázquez wrote:
[...]
> The usual process is to propose changes on this list and include
> any patches inline or as an attachment.  You can find many examples
> in the archive (e.g., <https://www.zsh.org/mla/workers/2023/>).

Perfect! My one-line-plus-documentation patch is below. The proposal is to
have a way to add custom hook types to be managed with add-zsh-hook.

> -- 
> vq
--Gregory

diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo
index f43ac2257..004a244b6 100644
--- a/Doc/Zsh/contrib.yo
+++ b/Doc/Zsh/contrib.yo
@@ -303,10 +303,11 @@ The shell function tt(add-zsh-hook) provides a simple way of adding or
 removing functions from the array.
 
 var(hook) is one of tt(chpwd), tt(periodic), tt(precmd), tt(preexec),
-tt(zshaddhistory), tt(zshexit), or tt(zsh_directory_name),
-the special functions in question.  Note that tt(zsh_directory_name)
-is called in a different way from the other functions, but may
-still be manipulated as a hook.
+tt(zshaddhistory), tt(zshexit), or tt(zsh_directory_name), the special
+functions in question.  Additional custom hooks may be manipulated with
+add-zsh-hook by setting the var(customhooktypes) shell variable.  Note that
+tt(zsh_directory_name) is called in a different way from the other
+functions, but may still be manipulated as a hook.
 
 var(function) is name of an ordinary shell function.  If no options
 are given this will be added to the array of functions to be executed
diff --git a/Functions/Misc/add-zsh-hook b/Functions/Misc/add-zsh-hook
index 3bc952e2f..33090f201 100644
--- a/Functions/Misc/add-zsh-hook
+++ b/Functions/Misc/add-zsh-hook
@@ -18,6 +18,7 @@ local -a hooktypes
 hooktypes=(
   chpwd precmd preexec periodic zshaddhistory zshexit
   zsh_directory_name
+  ${customhooktypes:-}
 )
 local usage="Usage: add-zsh-hook hook function\nValid hooks are:\n  $hooktypes"
 

Re: Extending zsh hooks

[Bart Schaefer]

On Tue, Nov 7, 2023 at 6:35 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> The usual process is to propose changes on this list and include
> any patches inline or as an attachment.

Although this remains the preferred way, recently we've been picking
up some patches from the GitHub mirror
https://github.com/zsh-users/zsh, see examples in ChangeLog.  I can't
comment on how reliable that would be.

Re: PATCH: custom zsh hooks (was Re: Extending zsh hooks)

[Bart Schaefer]

On Wed, Nov 8, 2023 at 11:17 AM Gregory Seidman
<gsslist+zshdev@anthropohedron.net> wrote:
>
> My one-line-plus-documentation patch is below. The proposal is to
> have a way to add custom hook types to be managed with add-zsh-hook.

The doc paragraph preceding the one you edited says:
  Several functions ... are automatically called at specific points during
  shell execution.

This patch would introduce a new reserved parameter name; the arrays
thereby managed are obviously not related to any other
automatically-called function; and extending the list of hook names in
this way introduces the possibility of name conflicts with actual new
hook functions that might be added in the future.

I think we need some more justification for why this should be
enshrined in the official sources, and for why it should overload
add-zsh-hook rather than be its own new function.  The options-parsing
part of add-zsh-hook is already duplicated in add-zle-hook-widget, so
either there's no issue with duplicating it again, or it's a candidate
for being pulled out into its own function and then called from both
of those and a third new one (or just rewritten using zparseopts,
since getopts/OPTIND handling is a bit iffy [cf. README for changes
5.8.1 to 5.9]).

If a new function is introduced, I would suggest basing it on
add-zle-hook-widget rather than on add-zsh-hook, because
add-zle-hook-widget uses zstyle rather than array parameters and
thereby doesn't clutter the parameter namespace.  (That assumes you
want something mostly backward compatible, because going forward this
could all use namespaces.)