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

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Fri, 15 Dec 2023 15:40:02 UTC

Severity: normal

Found in version 29.1.90

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sbaugh <at> catern.com, 67836 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
Subject: bug#67836: 29.1.90; map-y-or-n-p doesn't terminate when run in a kmacro in batch mode
Date: Sat, 16 Dec 2023 17:55:18 +0200
> 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.