From: "Alexander Prähauser" <alexander.praehauser@gmx.at>
To: Po Lu <luangruo@yahoo.com>
Cc: 65068@debbugs.gnu.org
Subject: bug#65068: 29.1; xkb-interception interaction causes problems with key combinations
Date: Thu, 24 Aug 2023 17:34:39 +0200 [thread overview]
Message-ID: <875y54qwi8.fsf@gmx.at> (raw)
In-Reply-To: <874jko629m.fsf@yahoo.com>
Now when I press for instance Space, it doesn't seem to evaluate
immediately, but it does evaluate when I
press another dual-function-modified key. So if I press the same
sequence as below the first message doesn't appear but
the second one does.
Po Lu [2023-08-24 Thu 20:41] wrote:
> Alexander Prähauser <alexander.praehauser@gmx.at> writes:
>
>> It does seem to register the correct level shifts now, but it
>> seems to
>> evaluate each key immediately after having been
>> pressed. For instance, when I press Space-CapsLock-U, this
>> should
>> evaluate to C-; and it does, but this is the output
>> I'm receiving in-between:
>>
>> <Control_R> is undefined
>> C-' is undefined
>> C-; is undefined
>>
>> Po Lu [2023-08-24 Thu 17:56] wrote:
>>
>>> Alexander Prähauser <alexander.praehauser@gmx.at> writes:
>>>
>>>> The significance of the U-key is that when I press
>>>> Space-CapsLock-U
>>>> (or any other key, I think), it doesn't send the signal
>>>> that is configured by xkb but the corresponding key of the
>>>> default
>>>> English keymap (u for the U-key), which really
>>>> shouldn't happen. Anyway, here the output after pressing the
>>>> sequence
>>>> you wanted:
>>>>
>>>> keycode: 48, keysym: 65027, 0
>>>> keycode: 192, keysym: 269025093, 0
>>>> keycode: 37, keysym: 65507, 0
>>>> keycode: 37, keysym: 65507, 0 <- Control_R
>>>> keycode: 48, keysym: 65027, 0 <- AC11, ISO_Level3_Shift
>>>> keycode: 192, keysym: 269025093, <- XF86Launch5
>>>
>>> This attests to Emacs registering the keysyms you meant it
>>> to. If
>>> ISO_Level3_Shift is registered as a modifier key, it should
>>> not be
>>> translated into keyboard input afterwards, let alone the
>>> original
>>> apostrophe symbol.
>>>
>>> Does this patch resolve your problems with typing level 3
>>> characters
>>> coupled with Control?
>>>
>>> diff --git a/src/xterm.c b/src/xterm.c
>>> index 6a1642ff56e..7391041ea0c 100644
>>> --- a/src/xterm.c
>>> +++ b/src/xterm.c
>>> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> ptrdiff_t i;
>>> unsigned int old_state;
>>> struct xi_device_t *device, *source;
>>> + bool is_modifier_key;
>>> coding = Qlatin_1;
>>> @@ -24175,17 +24176,7 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> /* Any "vendor-specific" key is ok. */
>>> || (keysym & (1 << 28))
>>> || (keysym != NoSymbol && nbytes == 0))
>>> - && ! (IsModifierKey (keysym)
>>> - /* The symbols from XK_ISO_Lock
>>> - to XK_ISO_Last_Group_Lock
>>> - don't have real modifiers but
>>> - should be treated similarly to
>>> - Mode_switch by Emacs. */
>>> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
>>> - || (XK_ISO_Lock <= keysym
>>> - && keysym <=
>>> XK_ISO_Last_Group_Lock)
>>> -#endif
>>> - ))
>>> + && !is_modifier_key)
>>> {
>>> STORE_KEYSYM_FOR_DEBUG (keysym);
>>> /* make_lispy_event will convert this to a
>>> symbolic
>>> @@ -24204,7 +24195,11 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
>>> }
>>> - if (nbytes)
>>> + /* Mind that NBYTES can be set even if KEYSYM
>>> + represents a modifier key, but that no
>>> character
>>> + events should be sent in that case. */
>>> +
>>> + if (nbytes && !is_modifier_key)
>>> {
>>> inev.ie.kind =
>>> MULTIBYTE_CHAR_KEYSTROKE_EVENT;
>>> inev.ie.arg = make_unibyte_string
>>> (copy_bufptr,
>>> nbytes);
>
> Please excuse my carelessness, I appear to have ommitted a chunk
> of the
> diff:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a1642ff56e..4b2da066694 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info
> *dpyinfo,
> ptrdiff_t i;
> unsigned int old_state;
> struct xi_device_t *device, *source;
> + bool is_modifier_key;
>
> coding = Qlatin_1;
>
> @@ -24091,6 +24092,18 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> goto xi_done_keysym;
> }
>
> + is_modifier_key = (IsModifierKey (keysym)
> + /* The symbols from
> XK_ISO_Lock
> + to XK_ISO_Last_Group_Lock
> + don't have real modifiers
> but
> + should be treated
> similarly to
> + Mode_switch by Emacs. */
> +#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
> + || (XK_ISO_Lock <= keysym
> + && keysym <=
> XK_ISO_Last_Group_Lock)
> +#endif
> + );
> +
> /* Random non-modifier sorts of keysyms. */
> if (((keysym >= XK_BackSpace && keysym <=
> XK_Escape)
> || keysym == XK_Delete
> @@ -24175,17 +24188,7 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> /* Any "vendor-specific" key is ok. */
> || (keysym & (1 << 28))
> || (keysym != NoSymbol && nbytes == 0))
> - && ! (IsModifierKey (keysym)
> - /* The symbols from XK_ISO_Lock
> - to XK_ISO_Last_Group_Lock
> - don't have real modifiers but
> - should be treated similarly to
> - Mode_switch by Emacs. */
> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
> - || (XK_ISO_Lock <= keysym
> - && keysym <=
> XK_ISO_Last_Group_Lock)
> -#endif
> - ))
> + && !is_modifier_key)
> {
> STORE_KEYSYM_FOR_DEBUG (keysym);
> /* make_lispy_event will convert this to a
> symbolic
> @@ -24204,7 +24207,11 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
> }
>
> - if (nbytes)
> + /* Mind that NBYTES can be set even if KEYSYM
> + represents a modifier key, but that no
> character
> + events should be sent in that case. */
> +
> + if (nbytes && !is_modifier_key)
> {
> inev.ie.kind =
> MULTIBYTE_CHAR_KEYSTROKE_EVENT;
> inev.ie.arg = make_unibyte_string
> (copy_bufptr, nbytes);
next prev parent reply other threads:[~2023-08-24 15:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v8dv2ib3.fsf@gmx.at>
2023-08-09 0:02 ` bug#65068: 29.1; xkb-interception interaction causes problems with key combinations Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-15 13:31 ` Alexander Prähauser
2023-08-16 1:29 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-16 7:50 ` Alexander Prähauser
2023-08-16 8:02 ` Alexander Prähauser
2023-08-16 12:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-16 14:04 ` Alexander Prähauser
2023-08-17 1:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 2:37 ` Alexander Prähauser
2023-08-17 2:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 3:28 ` Alexander Prähauser
2023-08-17 4:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 13:35 ` Alexander Prähauser
2023-08-23 11:02 ` Alexander Prähauser
2023-08-23 11:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-23 14:05 ` Alexander Prähauser
2023-08-24 0:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-24 11:06 ` Alexander Prähauser
2023-08-24 9:56 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-24 14:12 ` Alexander Prähauser
2023-08-24 12:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-24 15:34 ` Alexander Prähauser [this message]
2023-08-25 2:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-25 10:11 ` Alexander Prähauser
2023-08-25 8:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87o7iv34z0.FSF@yahoo.com>
2023-08-25 10:36 ` Alexander Prähauser
2023-08-26 1:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-26 11:39 ` Alexander Prähauser
2023-08-26 10:01 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-26 10:08 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875y54qwi8.fsf@gmx.at \
--to=alexander.praehauser@gmx.at \
--cc=65068@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.