bug#67836: 29.1.90; map-y-or-n-p doesn't terminate when run in a kmacro in batch mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sbaugh@catern.com,  sbaugh@janestreet.com,  67836@debbugs.gnu.org
> Date: Sat, 16 Dec 2023 10:11:47 -0500
> 
> > One way is by mocking of functions that read input.  AFAIR we do that
> > in several places in the test suite (which I always run in batch
> > mode).
> 
> Interesting!
> I wrote a few test cases which needed such interaction, and I used
> neither of those approaches: I relied on `unread-command-events`.
> Take a look at
> 
>     grep unread-command-events test/**/*.el

Yes, that is also possible.  But that will not fit Spencer's bill,
AFAIU.

> Could you two point me to examples of uses of the
> techniques you propose?  I'm curious to see how they compare.

I'd start by grepping our test suite for "mock".

> BTW, regarding mocking, it might be a good idea to make sure
> `bitch_at_user` is always called via `Qding` so that its behavior can be
> adjusted via mocking.

No objections.

> There's a tension where fixing such problems at low-level can have
> longer term benefits (at the cost of backward incompatibilities), so
> I think the best is to start by sending a patch that fixes the problem
> at the place you judge to be The Right Place™.

There's no disagreement on this level, the disagreement is about
where's The Right Place™ ;-)

> Regarding `ding` in particular.  I don't really know what should be its
> behavior in general.  I've always been surprised that it (usually)
> doesn't actually signal an error even though its intention is to signal
> to the user that there was a problem.

You don't think we should be able to "ding" without signaling an
error?  Ringing a bell is also a means to attract attention; on modern
GUI desktops, for example, this will produce some visual cue even when
the frame is minimized and otherwise invisible.

> IOW, I guess what I'd expect is that ELisp code basically never calls
> `ding` directly but that it's called from the command-loop when it
> catches an error.  And that suggests that maybe it should be the
> command-loop's responsibility to exit the keyboard macro when it catches
> an error, which in turn suggests that `bitch_at_user` when called from
> a keyboard macro should signal a "real" error rather than a user-error.

Since I disagree that 'ding' should only be a side effect of signaling
an error, I also disagree with your conclusion from that premise.