bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Nikolay Kudryavtsev]

I've originally mentioned this in discussion on #68914, because it 
seemed like a somewhat similar problem. But Eli suggested there that I 
should report this separately.

Let me disclaim in advance that I believe that this is an extremely 
minor niche issue and the value of investigating it is only in making 
sure that there aren't any other, more important use cases hit by this.

So here are the detailed reproduction steps:

1. Use Windows. I haven't really tested other platforms for this, but I 
highly suspect that this is a platform-specific issue.

2. Setup Mahou layout switcher. You can download it here:

https://gitea.com/BladeMight/Mahou/releases/download/latest-commit/Release_x86_x64.zip

The default settings should be sufficient. But to make sure, here are 
the relevant ones:

-On the "Layouts" tab, make sure "Change to specific layout by keys" is 
set to on and Caps Lock is the first key.

-On the "Functions" tab make sure "Remap Caps Lock to F18" is set to on.

3. Run Emacs -q

4. Eval (global-set-key [f18] nil) . We're doing this to avoid extra 
paste due to Mahou F18 setting. But strictly it's not necessary.

5. Freeze Emacs by forcing it to run some code for a few seconds. I've used:

(let ((x 0))
   (dotimes (i 10000000)
     (setq x (1+ x))))

6. While the above is running, start tapping CapsLock. You'd see that 
CapsLock toggles even though it shouldn't and this only happens when 
Emacs is frozen.

Few other notes regarding this bug:

Mahou is somewhat buggy too, I've seen it pointlessly toggle caps in 
other apps, but it does not seem to be the same issue.

I originally noticed it while using a certain proprietary app for the 
same purpose. So there are at least 2 applications with which this 
reliably happens.

There are many more applications with which this is not reproducible. I 
could not reproduce it with AutoHotkey, a dozen of other apps, including 
some other layout switchers like dotSwitcher.

So it seems like the third party app should be intercepting CapsLock in 
a very particular way for this to show up and thus the importance of the 
Mahou F18 setting is particularly interesting, because without it, the 
bug is not reproducible with Mahou.

I was wrong about Emacs 25 not suffering from this problem. I could 
reproduce it there too.

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Eli Zaretskii]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Date: Sun, 4 Feb 2024 22:11:55 +0300
> 
> 5. Freeze Emacs by forcing it to run some code for a few seconds. I've used:
> 
> (let ((x 0))
>    (dotimes (i 10000000)
>      (setq x (1+ x))))
> 
> 6. While the above is running, start tapping CapsLock. You'd see that 
> CapsLock toggles even though it shouldn't and this only happens when 
> Emacs is frozen.

Why are you saying that CapsLock should not toggle in this case?  What
prevents it from toggling in this scenario?

If I just run the above loop, and during its run quickly press and
release CapsLock, then type some letter key, then press and release
CapsLock again, I see an upper-case letter inserted after the loop
finishes.  Which means Emacs at least by default does pay attention to
CapsLock state even if it is busy with some calculation in its Lisp
thread.  Why should that behave differently with Mahou installed?

> I was wrong about Emacs 25 not suffering from this problem. I could 
> reproduce it there too.

So this is unlikely to be related to the low-level keyboard hook we
install on Windows since Emacs 26.

Thanks.

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Nikolay Kudryavtsev]

> Why are you saying that CapsLock should not toggle in this case?  What
> prevents it from toggling in this scenario?

Because I normally use CapsLock to toggle between keyboard layouts. 
External software like Mahou is what facilitates that and what should 
prevent the CapsLock itself from toggling. And it normally does, except 
for when Emacs gets busy with something.

Since I switch between layouts all the time I've noticed that I 
sometimes get those unwanted CapsLock toggles from time to time when 
using Emacs. Then eventually I've noticed that they only happens if I 
try to switch layout while Emacs is busy.

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Eli Zaretskii]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Date: Mon, 5 Feb 2024 15:45:13 +0300
> Cc: 68927@debbugs.gnu.org
> 
> > Why are you saying that CapsLock should not toggle in this case?  What
> > prevents it from toggling in this scenario?
> 
> Because I normally use CapsLock to toggle between keyboard layouts. 
> External software like Mahou is what facilitates that and what should 
> prevent the CapsLock itself from toggling. And it normally does, except 
> for when Emacs gets busy with something.

Then this is as likely to be an Emacs bug as it is a bug in Mahou,
right?  Perhaps Mahou is unprepared to cope with programs that hook
keyboard input on such a low level?

I think we need some expert to explain to us what happens with Mahou,
before we consider this an Emacs bug.

Thanks.

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Nikolay Kudryavtsev]

The reason why I consider this to be an Emacs bug above all is because 
of that inconsistency in input handling between the idle and busy states.

If Emacs had one consistent behavior that wouldn't change depending on 
the work load then it would be fine, regardless of what the behavior is, 
but this inconsistency tells me that something is amiss.

bug#68927: CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app

[Eli Zaretskii]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Date: Mon, 5 Feb 2024 16:13:24 +0300
> Cc: 68927@debbugs.gnu.org
> 
> The reason why I consider this to be an Emacs bug above all is because 
> of that inconsistency in input handling between the idle and busy states.
> 
> If Emacs had one consistent behavior that wouldn't change depending on 
> the work load then it would be fine, regardless of what the behavior is, 
> but this inconsistency tells me that something is amiss.

It's possible it's an Emacs bug, but it is also possible that Mahou
somehow mishandles the situation when Emacs responds slower than
usually.