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: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: sbaugh <at> janestreet.com, 67836 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
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 15:52:34 +0200

> From: sbaugh <at> catern.com
> Date: Sat, 16 Dec 2023 13:13:25 +0000 (UTC)
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, sbaugh <at> janestreet.com,
> 	67836 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> 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).

> There is definitely at least one bug, since the docstring of ding
> currently erroneously says:
> 
> Also, unless an argument is given,
> terminate any keyboard macro currently executing.
> 
> Making ding match its docstring was one way to fix this bug.  If you
> don't want to do that, could you apply this patch or something like it?

Will look into the documentation issue, once we agree on resolving
this bug that way.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.