GNU bug report logs -
#68927
CapsLock gets toggled by a frozen Emacs even if that's supposed to be prevented by a third party app
Previous Next
To reply to this bug, email your comments to 68927 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Sun, 04 Feb 2024 19:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 04 Feb 2024 19:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Mon, 05 Feb 2024 12:11:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 68927 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Mon, 05 Feb 2024 12:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 68927 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Mon, 05 Feb 2024 13:02:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 68927 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Mon, 5 Feb 2024 15:45:13 +0300
> Cc: 68927 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Mon, 05 Feb 2024 13:14:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 68927 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68927
; Package
emacs
.
(Mon, 05 Feb 2024 14:31:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 68927 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Mon, 5 Feb 2024 16:13:24 +0300
> Cc: 68927 <at> 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.
This bug report was last modified 295 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.