[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
From: |
Spencer Baugh |
Subject: |
bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros |
Date: |
Fri, 16 Feb 2024 17:26:45 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> merge 67837 65291
> thanks
>
> AFAICT this is the same bug as bug#65291 and the suggested patch is similar.
>
>> I'm actually tend to think that this proposal is fundamentally wrong,
>> not just problematic implementation-wise. Providing input from a
>> keyboard macro is still input, and inhibit-interaction=t means asking
>> for input signals an error. So your suggestion subverts this feature,
>> and therefore it is simply wrong to install something like that.
>
> I guess it begs the question: what is the purpose of
> `inhibit-interaction`?
>
> The way I see it, the purpose is to avoid Emacs waiting for user input
> when we know there's no user, and thus signal an error if we ever get to
> this point.
>
> Basically, I think since our test suite runs just fine in batch, we
> should be able to run it with inhibit-interaction=t as well (which
> would fix annoying problems when some test fails and ends up waiting
> for user input).
Yes, I agree. I'm interested in making this possible and willing to put
in the work to do it for the Emacs test suite. (since it will help make
my own tests reliable)
> Note that trying to make the whole test suite runs with
> `inhibit-interaction` non-nil is not at all straightforward, sadly:
> there are several places where we do call things like `read-event`
> without providing any keyboard input (i.e. without
> `unread-command-event` or keyboard macros) and instead use a timeout
> because this `read-event` is just there to force Emacs to wait while
> some external process sends us some reply. Should these be considered
> "interaction"? If not, then we open up a whole where some code may call
> `read-event` with a relatively short timeout within a tight loop where
> the purpose *is* to get user input and where the timeout is only present
> to keep something else updated while we wait for that user's input.
What places are these?
I think that does sound like interaction to me. In which case, could we
change those places to not use read-event? Those places would break
anyway if they ran inside a user-defined keyboard macro, if I understand
correctly, so it's useful to fix them.
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros,
Spencer Baugh <=
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Stefan Monnier, 2024/02/16
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Eli Zaretskii, 2024/02/17
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Stefan Monnier, 2024/02/17
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Eli Zaretskii, 2024/02/17
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Eli Zaretskii, 2024/02/17
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Stefan Monnier, 2024/02/17
- bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Eli Zaretskii, 2024/02/17
bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros, Eli Zaretskii, 2024/02/17