zsh-workers
 help / color / mirror / code / Atom feed
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.


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