Re: [PATCH] NEWS item about the ERR_EXIT fixes

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Lawrence Velázquez wrote on Fri, Dec 09, 2022 at 01:44:44 -0500:
> On Thu, Dec 8, 2022, at 7:24 PM, Bart Schaefer wrote:
> > On Thu, Dec 8, 2022 at 1:47 PM Philippe Altherr
> > <philippe.altherr@xxxxxxxxx> wrote:
> >>
> >> I couldn't make it shorter than what is in the patch.
> >
> > I think this is fine.  Any opposed?
> 
> I think it's overly verbose; NEWS doesn't have to explain how
> ERR_EXIT works.  Here's a possible alternative:
> 
> diff --git a/NEWS b/NEWS
> index cdafd1ff5..d8b8687c0 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -4,8 +4,27 @@ CHANGES FROM PREVIOUS VERSIONS OF ZSH
>  
>  Note also the list of incompatibilities in the README file.
>  
> -Changes since 5.8.1
> --------------------
> +Changes since 5.9
> +-----------------
> +
> +The ERR_EXIT option was refined to be more self-consistent and better
> +aligned with the POSIX-2017 specification of `set -e`:
> +
> +  - Prefixing a function call or anonymous function with `!` now
> +    suppresses ERR_EXIT.

Shouldn't this define the term "suppresses"?  It's not used in
the documentation of ERR_EXIT.

Is the option suppressed for the function call or the result of the
anonymous function, or /within/ the called function or anonymous
function?

What's the behaviour of ERR_EXIT on «! foo» when foo isn't a named or
anonymous function?  I.e., does the change make function calls an
exception, or does it make them /no longer/ an exception?  I think the
text should answer this.

> +
> +  - The `always` command now propagates ERR_EXIT suppression, as other
> +    complex commands do.
> +

Shouldn't this define the term "propagates"?  It's not used in
the documentation of ERR_EXIT.

> +  - Function calls, anonymous functions, and the `eval`, `.`, and
> +    `source` commands no longer propagate ERR_EXIT suppression.

s/commands/builtins/

> +
> +The ERR_RETURN option is now suppressed when a function containing
> +a compound sublist (`&&` or `||`) is called from within another compound
> +sublist.
> +

Does suppression happen for the result of the call, or within the
callee?

What exactly are the conditions whereupon suppression happens?  As
written, the text implies that suppression happens in
.
    FWaCL() { …; if false; then : && :; fi; … }
    false || FWaCL
.
regardless of the values of the ellipses; is that the intended meaning?

As you mentioned downthread, please add examples of affected cases (and,
if needed, of unaffected cases too).  Doc/Zsh/ can be updated as well,
if needed (this is discussed on the 51089 thread).

Proposed text (possibly wrong, do not use it without checking for
correctness and omissions):

    The ERR_EXIT option no longer applies to the result of commands
    of the form '! foo' regardless of what 'foo' is.  Previously, the
    option did take effect if 'foo' were a function call or an anonymous
    function.  Example:
    .
	setopt ERR_EXIT
        f() { false }
	g() { ! f; echo This will be printed in 5.10 but was not printed in 5.9 }

    The ERR_EXIT option now applies to the result of an 'always'
    block.  This aligns 'always' with other complex commands.
    Example:
    .
	setopt ERR_EXIT
        { false } always { echo This would be printed by either 5.9 and 5.10 }
	echo This would only be printed by 5.10 and newer
    # I'm saying "complex" rather than "compound" because that's the
    # term the manual uses.

    The ERR_EXIT option now applies to the results of function calls,
    anonymous functions, and the `eval`, `.`, and `source` builtins.
    Example:
    .
        setopt ERR_EXIT
	f() { false; }
	f
	echo This was printed under 5.9 but will not be printed by 5.10

    The ERR_RETURN option now applies within a function even if the
    return code of the function itself would not trigger ERR_RETURN
    behaviour from the function's caller (e.g., because the function
    call is on the left-hand side of an "&&" or "||").  Example:
    .
        setopt ERR_RETURN
	f() { false; echo This was printed under 5.9 but will not be printed under 5.10 }
	g() { f || true }

Cheers,

Daniel

P.S. Personally, I'd have preferred it if the four commits with "51001:"
at the start of their log message had something unique there, e.g.,
"51001/{1..4}", as per precedent (e.g., zsh-5.8-433-ga23f19bfb).
Rationale: so anyone doing «git log --grep='^51001'» would know, from
the first log message they see, that several commits match the grep,
rather than just one as might be assumed.

> +Changes from 5.8.1 to 5.9
> +-------------------------
>  
>  zsh 5.9 is dedicated to the memory of Sven Guckes, who was, amongst other
>  things, a long-time zsh advocate.  For more information, see:
> -- 
> vq
>