[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65068: 29.1; xkb-interception interaction causes problems with key c
From: |
Po Lu |
Subject: |
bug#65068: 29.1; xkb-interception interaction causes problems with key combinations |
Date: |
Thu, 24 Aug 2023 20:41:41 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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);
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, (continued)
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/16
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/17
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/19
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/23
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/23
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/23
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/23
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/24
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/24
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/24
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations,
Po Lu <=
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/24
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/24
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/25
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/25
- Message not available
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/25
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/25
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Alexander Prähauser, 2023/08/26
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Po Lu, 2023/08/26
- bug#65068: 29.1; xkb-interception interaction causes problems with key combinations, Eli Zaretskii, 2023/08/26