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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> >> I suspect keyboard macros have not been used very much in batch mode
>> >> over the last 32 years.
>> >
>> > I actually question the wisdom of doing so.  It isn't what keyboard
>> > macros are for.
>> 
>> How else can one test keyboard interaction with Emacs commands,
>> including their interactive specs?  I see no way to do that other than
>> with keyboard macros.  I'd be happy to hear that there's a better way,
>> though.
>
> 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

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

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.

>> Often, a low-level change to Emacs is in fact acceptable.  I have little
>> way of knowing whether any given low-level change is acceptable, other
>> than by sending it in and seeing what others say.  I hope it is OK if I
>> continue to do that.
>
> It is definitely okay, and your work is certainly appreciated.  I'm
> just trying to explain the POV of the Emacs maintainers, in the hope
> that you could look for solutions in places other than low-level code
> which is used all over Emacs, when problems are specific to some
> higher-level API or specific situation.  That would make the review
> and acceptance of the changes more efficient, and will probably
> prevent you from doing extra unnecessary work.

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

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.

As a user, after I see/hear a "ding", I expect that Emacs has not done
any further processing.  Yet that's not what `ding` does.

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.


        Stefan