bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros


From: sbaugh
Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC)
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:
>> >> - Users write functions using keyboard macros and put them in hooks,
>> >>   which happen to get invoked by packages which use inhibit-interaction.
>> >>   Those functions don't actually require interaction, but because they
>> >>   break, ultimately no code can use inhibit-interaction.
>> >> 
>> >> - I run tests in a batch Emacs, frequently using keyboard macros to
>> >>   provide input.  Sometimes a bug causes code to run which calls
>> >>   read-char outside of a keyboard macro.  I would like such read-char
>> >>   calls to error (instead of hanging, which is what they do by default
>> >>   in batch mode).  If I bind inhibit-interaction=t, then read-char will
>> >>   exit with an error, but my keyboard macros will also immediately
>> >>   error.
>> >
>> > In both cases, using a function would solve the problem.  So I'm not
>> > convinced we need to support those marginal cases, unless you can come
>> > up with a solution that will be both simple and will not affect
>> > unrelated use cases.
>> 
>> - Are you suggesting that novice users should have to rewrite all their
>>   keyboard macros in Lisp?  That sounds impractical.
>
> I don't see anything impractical here.

Many users of Emacs are not programmers.  They are able to use keyboard
macros as a simple, non-programming way to make reusable functions and
commands.  Are you saying they should learn to program so that they can
rewrite their keyboard macros by hand into Lisp?

>> - How can I provide keyboard input to the interactive spec of a command
>>   I am testing, other than by using keyboard macros?  I'd be pleased to
>>   have an alternative solution.
>
> Why do you need to do that when inhibit-interaction is non-nil in the
> first place?  Code that needs interaction shouldn't be run or tested
> in those conditions.

As I said before: because otherwise read-char outside a keyboard macro
will hang, and I want my test to fail instead of hang in that case.

Let me phrase the use case differently:

I have some tests which I'd like to run in batch Emacs.  By default, if
any of the code under test runs read-char, Emacs will simply hang
forever (that's what read-char does in batch mode).

I would prefer instead that my tests to fail immediately if any code
runs read-char.  How would you suggest I do that?

AFAIK the only way to achieve this currently is inhibit-interaction,
although I'd be happy to add an alternative way to do that.

So, to achieve this I'll use inhibit-interaction=t over my entire test
suite.  But then tests which make any use of a keyboard macro, for
testing interactive specs for example, will fail!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]