all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Alexander Prähauser" <alexander.praehauser@gmx.at>
Cc: 65068@debbugs.gnu.org
Subject: bug#65068: 29.1; xkb-interception interaction causes problems with key combinations
Date: Thu, 24 Aug 2023 20:41:41 +0800	[thread overview]
Message-ID: <874jko629m.fsf@yahoo.com> (raw)
In-Reply-To: <87il94sew9.fsf@gmx.at> ("Alexander Prähauser"'s message of "Thu, 24 Aug 2023 16:12:55 +0200")

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);





  reply	other threads:[~2023-08-24 12:41 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 [this message]
2023-08-24 15:34                                         ` Alexander Prähauser
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=874jko629m.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=65068@debbugs.gnu.org \
    --cc=alexander.praehauser@gmx.at \
    --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.