GNU bug report logs - #69083
Emacs's keyboard hook state is not reset on session lock (Windows)

Previous Next

Package: emacs;

Reported by: Raffael Stocker <r.stocker <at> mnet-mail.de>

Date: Mon, 12 Feb 2024 19:37:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69083 <at> debbugs.gnu.org
Subject: bug#69083: Emacs's keyboard hook state is not reset on session lock (Windows)
Date: Sun, 03 Mar 2024 17:43:56 +0100
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> I'll think about this a bit more, maybe I can come up with a nice
>> solution that doesn't require keeping too much state just for the reset
>> function.  I am thinking about registering the notification for the
>> first created frame, and when that is deleted, i.e. receives the
>> ‘WM_DESTROY’ message, "handing" it over to some other frame if there is
>> one.
>
> This sounds like the simplest approach to me.

I have implemented this and attached the patch.  I have tested it with
both console and GUI Emacs (with and without server) and have found no
further problems with it.

>> I don't know much about the internals of Emacs frame handling.
>> Could ‘w32_frame_list_z_order’ be used (from the input thread) for
>> something like that?  Or is there a better approach?
>
> Why is the order important?  Can't you "hand" the registration to some
> other frame, no matter which one?

The order is not important, I just didn't know where to look to get
a frame; sorry for the noise.  I now use ‘Fnext_frame’.

Regards,
Raffael

[0001-Fix-resetting-keyboard-hook-state-on-Windows.patch (text/x-patch, attachment)]

This bug report was last modified 1 year and 162 days ago.

Previous Next


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