GNU bug report logs -
#67836
29.1.90; map-y-or-n-p doesn't terminate when run in a kmacro in batch mode
Previous Next
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: sbaugh <at> catern.com, sbaugh <at> janestreet.com, 67836 <at> 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.
This bug report was last modified 1 year and 277 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.