>
> >> +  - Function calls, anonymous functions, and the `eval`, `.`, and
> >> +    `source` commands no longer propagate ERR_EXIT suppression.
> >
> > This kind of suggests that these constructs always propagated the
> > suppression, which isn't the case, but the exact circumstances look too
> > complex to explain. Maybe replace "no longer" with "now never".


> What were the circumstances under which they previously propagated
> suppression?


This is now explained in my new patch proposal (see new thread).

I admit that I don't fully understand what this commit did, so I
> more or less copied the entry Bart added to ChangeLog:


>         * Philippe Altherr: 51071: Src/exec.c, Test/C03traps.ztst: fix
>         ERR_RETURN when a function using && / || is called within another
>         statement using && / ||


> That's not accurate either, then?


That's just a bit less definitive/precise than your formulation. Enough so
that it can be qualified as "not wrong" ;-)

My new patch proposal describes the exact circumstances, which
unfortunately are rather convoluted.

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?



[...]


These are all valid questions. I think that they are all addressed by my
two new patch proposals.

The documentation addresses some but not all of the special cases
> and weirdness of ERR_EXIT.  I figured that fixing that was out of
> scope here, but this might actually be a good time to remedy the
> omissions.  That way NEWS and README don't have to waste a bunch
> of space explaining aspects of ERR_EXIT that should be in the
> documentation anyway.


Better documentation of ERR_EXIT makes it indeed easier to explain what
changed. I took that approach in my two new patch proposals.

This is only incidentally true.  The documentation omits many details
> about ERR_EXIT's special cases, so your changes largely fall between
> the lines (so to speak).


That was my point. The current documentation is so shallow that it fits
both the state before and after my patches. So it could remain as is
without being more or less wrong than before. But of course that doesn't
avoid the need of documenting what changed because some users may have
started to depend on the previous behavior. My updated patch for NEWS and
README now describes in detail all the changes. And my patch for the
ERR_EXIT and ERR_RETURN documentation adds enough details that it would no
longer be compatible with the state before my patches.

Philippe