zsh-workers
 help / color / mirror / code / Atom feed
From: Philippe Altherr <philippe.altherr@gmail.com>
To: "Lawrence Velázquez" <larryv@zsh.org>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>, zsh-workers@zsh.org
Subject: Re: [PATCH] NEWS item about the ERR_EXIT fixes
Date: Tue, 13 Dec 2022 01:33:12 +0100	[thread overview]
Message-ID: <CAGdYchsO+M59YPAo6qpN==aaTH+FBF_AiF4WbAz5wcvO-jtUpw@mail.gmail.com> (raw)
In-Reply-To: <79df64ce-17e7-45e8-833f-f975c97f7797@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

>
> >> +  - 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

[-- Attachment #2: Type: text/html, Size: 5128 bytes --]

  reply	other threads:[~2022-12-13  0:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 21:45 Philippe Altherr
2022-12-09  0:24 ` Bart Schaefer
2022-12-09  6:44   ` Lawrence Velázquez
2022-12-09  9:30     ` Philippe Altherr
2022-12-09 15:17       ` Mikael Magnusson
2022-12-10  7:23         ` Lawrence Velázquez
2022-12-10  7:35       ` Lawrence Velázquez
2022-12-10 11:32     ` Daniel Shahaf
2022-12-10 13:49       ` Philippe Altherr
2022-12-11  3:32         ` Lawrence Velázquez
2022-12-13  0:33           ` Philippe Altherr [this message]
2022-12-13  3:05             ` Daniel Shahaf
2022-12-11  3:23       ` Lawrence Velázquez

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='CAGdYchsO+M59YPAo6qpN==aaTH+FBF_AiF4WbAz5wcvO-jtUpw@mail.gmail.com' \
    --to=philippe.altherr@gmail.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=larryv@zsh.org \
    --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).