From: Marlon Richert <marlon.richert@gmail.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Does add-zle-hook-widget violate the contract of ZLE hook widgets?
Date: Thu, 24 Jun 2021 13:34:00 +0300 [thread overview]
Message-ID: <CAHLkEDsnf1J0soGwCFeSH-dS0wivVAf2HUCuQHKPZEgw-5DNKA@mail.gmail.com> (raw)
In-Reply-To: <9c56f50a-d061-4175-958a-6f89f6bae822@www.fastmail.com>
On Thu, Jun 24, 2021 at 1:06 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Marlon Richert wrote on Wed, 23 Jun 2021 20:30 +00:00:
> > foo implements a perfectly fine zle-line-init widget. It obeys the
> > contract laid out at
> > https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#Special-Widgets,
> > which says nothing about return values.
>
> That has two possible interpretations:
>
> - Hook functions may set $? however they want
>
> - Hook functions should set $? to zero on success and to non-zero
> otherwise
>
> In favour of the first interpretation is that the manual's language
> doesn't explicitly rule it out and compatibility with hook functions
> that predate add-zle-hook-widget and don't set $? as
> add-zle-hook-widget expects.
>
> In favour of the second interpretation is that those semantics are the
> default, ubiquitous, baked into the language's syntax, and extensible
> (same thing as "This bit must be zero" in wire protocol specifications).
>
> I'm voting for the second interpretation.
>
> I suppose we could've added something to NEWS/README when add-zle-hook-widget
> was introduced, if only because this is an interoperability issue (foo
> and bar may be have separate maintainers).
I think this should be mentioned permanently in the manual, exactly
because we see foo and bar from separate maintainers in the wild.
> > Isn't add-zle-hook-widget here violating the contract between foo and
> > zle -N zle-line-init?
>
> No. The contract with foo is that it'll be called, and it does get called.
>
> > Should that `|| return` be removed?
> No, because that would break the case of _deliberately_ returning non-zero
> from one a-z-h-w hook to prevent further a-z-h-w hooks from running.
> Granted, that's not a documented promise, but there's no reason to break
> it, either.
For hooks added through azhw, yes. But hooks added through zle -N
zle-<hook> have no reason to expect that their return value has any
effect.
How about if azhw would ignore the return value _only_ of any
pre-existing zle -N zle-X widget? For example, this part of the azhw
code could be modified to wrap the original widget function in a
function that always returns zero:
# Check for an existing widget, add it as the first hook
if [[ ${widgets[$hook]:-} != "user:azhw:$hook" ]]; then
if [[ -n ${widgets[$hook]:-} ]]; then
zle -A "$hook" "${widgets[$hook]}" # <-- This line could be
changed. --M
extant_hooks=(0:"${widgets[$hook]}" "${extant_hooks[@]}")
fi
zle -N "$hook" azhw:"$hook"
fi
Also, regardless of the above, the documentation in
https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#Special-Widgets
could be updated to guide the user towards azhw. And the documentation
of azhw could be updated to mention the canceling behavior.
> Hope that answers your question.
I didn't mean this as a Q&A, but more as a point of discussion. :)
If we are happy with the behavior as-is, then this should be
documented. In particular, 3rd-party developers should be strongly
encouraged to use azhw and not zle -N zle-X.
next prev parent reply other threads:[~2021-06-24 10:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 20:30 Marlon Richert
2021-06-23 21:57 ` Daniel Shahaf
2021-06-23 23:33 ` Lawrence Velázquez
2021-06-24 0:09 ` Daniel Shahaf
2021-06-24 10:34 ` Marlon Richert [this message]
2021-06-24 10:45 ` Roman Perepelitsa
2021-06-24 18:54 ` Daniel Shahaf
2021-06-24 19:51 ` Roman Perepelitsa
2021-06-24 18:30 ` Daniel Shahaf
2021-06-24 21:48 ` Marlon Richert
2021-06-24 22:29 ` Lawrence Velázquez
2021-06-26 10:12 ` Marlon Richert
2021-06-26 14:51 ` Bart Schaefer
2021-06-24 23:52 ` Daniel Shahaf
2021-06-26 10:49 ` Marlon Richert
2021-06-25 17:34 ` Bart Schaefer
2021-06-27 8:19 Marlon Richert
2021-06-29 2:06 ` Bart Schaefer
2021-06-29 14:50 ` Marlon Richert
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=CAHLkEDsnf1J0soGwCFeSH-dS0wivVAf2HUCuQHKPZEgw-5DNKA@mail.gmail.com \
--to=marlon.richert@gmail.com \
--cc=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).