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: 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.)

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.