From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2017 09:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 29349@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.151099811430952 (code B ref -1); Sat, 18 Nov 2017 09:42:01 +0000 Received: (at submit) by debbugs.gnu.org; 18 Nov 2017 09:41:54 +0000 Received: from localhost ([127.0.0.1]:45544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFzdJ-00083A-Mm for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:53 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFzdI-00082y-Jv for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFzdC-0004AN-8A for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:47 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49273) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eFzdC-0004A5-4t for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:46 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFzdB-00008C-2G for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFzd6-0003zC-51 for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:45 -0500 Received: from ocolin.muc.de ([193.149.48.4]:22973 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eFzd5-0003ui-Ps for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:40 -0500 Received: (qmail 50993 invoked by uid 3782); 18 Nov 2017 09:41:34 -0000 Received: from acm.muc.de (p548C78EA.dip0.t-ipconnect.de [84.140.120.234]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Nov 2017 10:41:32 +0100 Received: (qmail 4504 invoked by uid 1000); 18 Nov 2017 09:38:43 -0000 Date: Sat, 18 Nov 2017 09:38:43 +0000 Message-ID: <20171118093843.GA3819@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.4 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.4 (----) Hello, Emacs. In branch emacs-26. I came across this bug whilst working on bug #29272 ("C-h k C-mouse-3" followed by menu selection asks for more keys). In a Linux tty using the GPM mouse package, doing read_key_sequence (the C function in keyboard.c), when a menu action is activated, read_key_sequence calls itself recursively to handle all the mouse manipulation. Unfortunately, the variable raw_keybuf_count is initialised to 0 in r_k_s. This includes in the recursive call. This variable indexes the global buffer raw_keybuf, which accumulates the raw events which make up the key sequence. The result of this is that the events in the recursive call overwrite the stored events of the outer r_k_s call, leaving a mess. r_k_s is static in keyboard.c and is called from three functions: command_loop_1, read_menu_command (the one that gives the trouble), and read_key_sequence_vs. So I propose as a solution that raw_keybuf_count be initialised to zero in two of these three functions, but not in read_menu_command (and no longer in read_key_sequence). I've tried this, and it seems to work. It has the disadvantage of being ugly, and it makes read_menu_command only callable as a subfunction of r_k_s. Has anybody any thoughts on this? ######################################################################### As a second problem, is there any way, preferably at the Lisp level, to determine that a key sequence is a menu key sequence? -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 12:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 29349@debbugs.gnu.org Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151109507711176 (code B ref 29349); Sun, 19 Nov 2017 12:38:02 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 12:37:57 +0000 Received: from localhost ([127.0.0.1]:46848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGOrF-0002uC-HA for submit@debbugs.gnu.org; Sun, 19 Nov 2017 07:37:57 -0500 Received: from ocolin.muc.de ([193.149.48.4]:50635 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGOrD-0002u3-T1 for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 07:37:56 -0500 Received: (qmail 12450 invoked by uid 3782); 19 Nov 2017 12:37:54 -0000 Received: from acm.muc.de (p548C7514.dip0.t-ipconnect.de [84.140.117.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Nov 2017 13:37:53 +0100 Received: (qmail 5527 invoked by uid 1000); 19 Nov 2017 12:34:56 -0000 Date: Sun, 19 Nov 2017 12:34:56 +0000 Message-ID: <20171119123456.GA4576@ACM> References: <20171118093843.GA3819@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171118093843.GA3819@ACM> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Emacs. On Sat, Nov 18, 2017 at 09:38:43 +0000, Alan Mackenzie wrote: > In branch emacs-26. > I came across this bug whilst working on bug #29272 ("C-h k C-mouse-3" > followed by menu selection asks for more keys). > In a Linux tty using the GPM mouse package, doing read_key_sequence (the > C function in keyboard.c), when a menu action is activated, > read_key_sequence calls itself recursively to handle all the mouse > manipulation. > Unfortunately, the variable raw_keybuf_count is initialised to 0 in > r_k_s. This includes in the recursive call. This variable indexes the > global buffer raw_keybuf, which accumulates the raw events which make up > the key sequence. > The result of this is that the events in the recursive call overwrite > the stored events of the outer r_k_s call, leaving a mess. > r_k_s is static in keyboard.c and is called from three functions: > command_loop_1, read_menu_command (the one that gives the trouble), and > read_key_sequence_vs. > So I propose as a solution that raw_keybuf_count be initialised to zero > in two of these three functions, but not in read_menu_command (and no > longer in read_key_sequence). I've tried this, and it seems to work. > It has the disadvantage of being ugly, and it makes read_menu_command > only callable as a subfunction of r_k_s. > Has anybody any thoughts on this? Here is how I propose to solve this: (i) In keyboard.c, the static variables raw_keybuf and raw_keybuf_count will become pointers. They will initially point to a static buffer and a static integer. For safety's sake, they will be reinitialised to those static variables in command_loop_1(), just before the invocation of read_key_sequence(). (ii) read_key_sequence() will get a Lisp_Object buffer and a count variable as local variables. Around the call to read_char(), raw_keybuf{,_count} will be set to point to these locals, so that should read_char encounter a menu, its events will be stored in the local copy of the Lisp_Object buffer. (iii) On return from read_char, if any events are in the local buffer, they will be appended to the buffer in the enclosing scope. The global pointers raw_keybuf{,_count} will be restored to their previous values. In short, raw_keybuf and raw_keybuf_count will be "bound" to local variables around the call to read_char(). Comments? -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 16:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 29349@debbugs.gnu.org Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151110733013891 (code B ref 29349); Sun, 19 Nov 2017 16:03:02 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 16:02:10 +0000 Received: from localhost ([127.0.0.1]:47694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGS2r-0003by-Q8 for submit@debbugs.gnu.org; Sun, 19 Nov 2017 11:02:10 -0500 Received: from ocolin.muc.de ([193.149.48.4]:37714 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGS2p-0003br-TJ for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 11:02:08 -0500 Received: (qmail 62760 invoked by uid 3782); 19 Nov 2017 16:02:05 -0000 Received: from acm.muc.de (p548C7514.dip0.t-ipconnect.de [84.140.117.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Nov 2017 17:02:05 +0100 Received: (qmail 9577 invoked by uid 1000); 19 Nov 2017 15:59:08 -0000 Date: Sun, 19 Nov 2017 15:59:08 +0000 Message-ID: <20171119155908.GB4576@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171119123456.GA4576@ACM> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Emacs. On Sun, Nov 19, 2017 at 12:34:56 +0000, Alan Mackenzie wrote: > On Sat, Nov 18, 2017 at 09:38:43 +0000, Alan Mackenzie wrote: > > In branch emacs-26. > > I came across this bug whilst working on bug #29272 ("C-h k C-mouse-3" > > followed by menu selection asks for more keys). > > In a Linux tty using the GPM mouse package, doing read_key_sequence (the > > C function in keyboard.c), when a menu action is activated, > > read_key_sequence calls itself recursively to handle all the mouse > > manipulation. > > Unfortunately, the variable raw_keybuf_count is initialised to 0 in > > r_k_s. This includes in the recursive call. This variable indexes the > > global buffer raw_keybuf, which accumulates the raw events which make up > > the key sequence. > > The result of this is that the events in the recursive call overwrite > > the stored events of the outer r_k_s call, leaving a mess. > > r_k_s is static in keyboard.c and is called from three functions: > > command_loop_1, read_menu_command (the one that gives the trouble), and > > read_key_sequence_vs. > > So I propose as a solution that raw_keybuf_count be initialised to zero > > in two of these three functions, but not in read_menu_command (and no > > longer in read_key_sequence). I've tried this, and it seems to work. > > It has the disadvantage of being ugly, and it makes read_menu_command > > only callable as a subfunction of r_k_s. > > Has anybody any thoughts on this? > Here is how I propose to solve this: > (i) In keyboard.c, the static variables raw_keybuf and raw_keybuf_count > will become pointers. They will initially point to a static buffer and > a static integer. For safety's sake, they will be reinitialised to > those static variables in command_loop_1(), just before the invocation > of read_key_sequence(). > (ii) read_key_sequence() will get a Lisp_Object buffer and a count > variable as local variables. Around the call to read_char(), > raw_keybuf{,_count} will be set to point to these locals, so that should > read_char encounter a menu, its events will be stored in the local copy > of the Lisp_Object buffer. > (iii) On return from read_char, if any events are in the local buffer, > they will be appended to the buffer in the enclosing scope. The global > pointers raw_keybuf{,_count} will be restored to their previous values. > In short, raw_keybuf and raw_keybuf_count will be "bound" to local > variables around the call to read_char(). > Comments? Here's a patch which implements the above: diff --git a/src/keyboard.c b/src/keyboard.c index 57757cf211..ae687aad89 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -121,12 +121,17 @@ ptrdiff_t this_command_key_count; /* This vector is used as a buffer to record the events that were actually read by read_key_sequence. */ -static Lisp_Object raw_keybuf; -static int raw_keybuf_count; - -#define GROW_RAW_KEYBUF \ - if (raw_keybuf_count == ASIZE (raw_keybuf)) \ - raw_keybuf = larger_vector (raw_keybuf, 1, -1) +static Lisp_Object raw_keybuf_buffer; +static int raw_keybuf_count_buffer; +static Lisp_Object *raw_keybuf = &raw_keybuf_buffer; +static int *raw_keybuf_count = &raw_keybuf_count_buffer; + +#define GROW_RAW_KEYBUF(inc) \ + if (*raw_keybuf_count > ASIZE (*raw_keybuf) - (inc)) \ + *raw_keybuf = \ + larger_vector (*raw_keybuf, \ + (inc) + *raw_keybuf_count - ASIZE (*raw_keybuf), \ + -1) /* Number of elements of this_command_keys that precede this key sequence. */ @@ -1365,6 +1370,8 @@ command_loop_1 (void) Vthis_command_keys_shift_translated = Qnil; /* Read next key sequence; i gets its length. */ + raw_keybuf_count = &raw_keybuf_count_buffer; /* For safety */ + raw_keybuf = &raw_keybuf_buffer; /* Ditto */ i = read_key_sequence (keybuf, ARRAYELTS (keybuf), Qnil, 0, 1, 1, 0); @@ -8910,6 +8917,11 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, /* How many keys there are in the current key sequence. */ int t; + int *outer_raw_keybuf_count; + Lisp_Object *outer_raw_keybuf; + int inner_raw_keybuf_count_buffer; + Lisp_Object inner_raw_keybuf_buffer = Fmake_vector (make_number (30), Qnil); + /* The length of the echo buffer when we started reading, and the length of this_command_keys when we started reading. */ ptrdiff_t echo_start UNINIT; @@ -8971,7 +8983,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, /* List of events for which a fake prefix key has been generated. */ Lisp_Object fake_prefixed_keys = Qnil; - raw_keybuf_count = 0; + *raw_keybuf_count = 0; last_nonmenu_event = Qnil; @@ -9142,11 +9154,23 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, { KBOARD *interrupted_kboard = current_kboard; struct frame *interrupted_frame = SELECTED_FRAME (); + int i; + outer_raw_keybuf_count = raw_keybuf_count; + outer_raw_keybuf = raw_keybuf; + inner_raw_keybuf_count_buffer = 0; + raw_keybuf_count = &inner_raw_keybuf_count_buffer; + raw_keybuf = &inner_raw_keybuf_buffer; /* Calling read_char with COMMANDFLAG = -2 avoids redisplay in read_char and its subroutines. */ key = read_char (prevent_redisplay ? -2 : NILP (prompt), current_binding, last_nonmenu_event, &used_mouse_menu, NULL); + raw_keybuf_count = outer_raw_keybuf_count; + raw_keybuf = outer_raw_keybuf; + GROW_RAW_KEYBUF (inner_raw_keybuf_count_buffer); + for (i = 0; i < inner_raw_keybuf_count_buffer; i++) + ASET (*raw_keybuf, (*raw_keybuf_count)++, + AREF (inner_raw_keybuf_buffer, i)); if ((INTEGERP (key) && XINT (key) == -2) /* wrong_kboard_jmpbuf */ /* When switching to a new tty (with a new keyboard), read_char returns the new buffer, rather than -2 @@ -9254,9 +9278,9 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, && XINT (key) == quit_char && current_buffer != starting_buffer) { - GROW_RAW_KEYBUF; - ASET (raw_keybuf, raw_keybuf_count, key); - raw_keybuf_count++; + GROW_RAW_KEYBUF (1); + ASET (*raw_keybuf, *raw_keybuf_count, key); + (*raw_keybuf_count)++; keybuf[t++] = key; mock_input = t; Vquit_flag = Qnil; @@ -9295,9 +9319,9 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, current_binding = active_maps (first_event); } - GROW_RAW_KEYBUF; - ASET (raw_keybuf, raw_keybuf_count, key); - raw_keybuf_count++; + GROW_RAW_KEYBUF (1); + ASET (*raw_keybuf, *raw_keybuf_count, key); + (*raw_keybuf_count)++; } /* Clicks in non-text areas get prefixed by the symbol @@ -9343,8 +9367,9 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, && BUFFERP (XWINDOW (window)->contents) && XBUFFER (XWINDOW (window)->contents) != current_buffer) { - ASET (raw_keybuf, raw_keybuf_count, key); - raw_keybuf_count++; + GROW_RAW_KEYBUF (1); + ASET (*raw_keybuf, *raw_keybuf_count, key); + (*raw_keybuf_count)++; keybuf[t] = key; mock_input = t + 1; @@ -10117,7 +10142,7 @@ shows the events before all translations (except for input methods). The value is always a vector. */) (void) { - return Fvector (raw_keybuf_count, XVECTOR (raw_keybuf)->contents); + return Fvector (*raw_keybuf_count, XVECTOR (*raw_keybuf)->contents); } DEFUN ("clear-this-command-keys", Fclear_this_command_keys, @@ -11262,8 +11287,8 @@ syms_of_keyboard (void) this_command_keys = Fmake_vector (make_number (40), Qnil); staticpro (&this_command_keys); - raw_keybuf = Fmake_vector (make_number (30), Qnil); - staticpro (&raw_keybuf); + raw_keybuf_buffer = Fmake_vector (make_number (30), Qnil); + staticpro (raw_keybuf); DEFSYM (Qcommand_execute, "command-execute"); DEFSYM (Qinternal_echo_keystrokes_prefix, "internal-echo-keystrokes-prefix"); -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 17:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 29349@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151111089219008 (code B ref 29349); Sun, 19 Nov 2017 17:02:02 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 17:01:32 +0000 Received: from localhost ([127.0.0.1]:47728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGSyJ-0004wW-Ug for submit@debbugs.gnu.org; Sun, 19 Nov 2017 12:01:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGSyI-0004wI-64 for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 12:01:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGSy8-000133-1W for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 12:01:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGSy7-00012x-UW; Sun, 19 Nov 2017 12:01:19 -0500 Received: from [176.228.60.248] (port=2103 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eGSy7-0005B2-9l; Sun, 19 Nov 2017 12:01:19 -0500 Date: Sun, 19 Nov 2017 19:01:09 +0200 Message-Id: <83tvxqdwyy.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20171119155908.GB4576@ACM> (message from Alan Mackenzie on Sun, 19 Nov 2017 15:59:08 +0000) References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 19 Nov 2017 15:59:08 +0000 > From: Alan Mackenzie > > > > In a Linux tty using the GPM mouse package, doing read_key_sequence (the > > > C function in keyboard.c), when a menu action is activated, > > > read_key_sequence calls itself recursively to handle all the mouse > > > manipulation. > > > > Unfortunately, the variable raw_keybuf_count is initialised to 0 in > > > r_k_s. This includes in the recursive call. This variable indexes the > > > global buffer raw_keybuf, which accumulates the raw events which make up > > > the key sequence. > > > > The result of this is that the events in the recursive call overwrite > > > the stored events of the outer r_k_s call, leaving a mess. > > > > r_k_s is static in keyboard.c and is called from three functions: > > > command_loop_1, read_menu_command (the one that gives the trouble), and > > > read_key_sequence_vs. > > > > So I propose as a solution that raw_keybuf_count be initialised to zero > > > in two of these three functions, but not in read_menu_command (and no > > > longer in read_key_sequence). I've tried this, and it seems to work. > > > It has the disadvantage of being ugly, and it makes read_menu_command > > > only callable as a subfunction of r_k_s. > > > > Has anybody any thoughts on this? > > > Here is how I propose to solve this: Can you please show a recipe where the current code misbehaves? I've re-read the thread, and found myself confused wrt the practical implications of the problem you describe. Thanks. From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 17:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 29349@debbugs.gnu.org Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151111370623050 (code B ref 29349); Sun, 19 Nov 2017 17:49:01 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 17:48:26 +0000 Received: from localhost ([127.0.0.1]:47768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGThh-0005zi-Qa for submit@debbugs.gnu.org; Sun, 19 Nov 2017 12:48:26 -0500 Received: from ocolin.muc.de ([193.149.48.4]:21461 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGThf-0005zZ-Vx for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 12:48:24 -0500 Received: (qmail 91401 invoked by uid 3782); 19 Nov 2017 17:48:20 -0000 Received: from acm.muc.de (p548C7514.dip0.t-ipconnect.de [84.140.117.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Nov 2017 18:48:19 +0100 Received: (qmail 10524 invoked by uid 1000); 19 Nov 2017 17:45:22 -0000 Date: Sun, 19 Nov 2017 17:45:22 +0000 Message-ID: <20171119174521.GB9922@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tvxqdwyy.fsf@gnu.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Sun, Nov 19, 2017 at 19:01:09 +0200, Eli Zaretskii wrote: > > Date: Sun, 19 Nov 2017 15:59:08 +0000 > > From: Alan Mackenzie > > > > In a Linux tty using the GPM mouse package, doing read_key_sequence (the > > > > C function in keyboard.c), when a menu action is activated, > > > > read_key_sequence calls itself recursively to handle all the mouse > > > > manipulation. > > > > Unfortunately, the variable raw_keybuf_count is initialised to 0 in > > > > r_k_s. This includes in the recursive call. This variable indexes the > > > > global buffer raw_keybuf, which accumulates the raw events which make up > > > > the key sequence. > > > > The result of this is that the events in the recursive call overwrite > > > > the stored events of the outer r_k_s call, leaving a mess. > > > > r_k_s is static in keyboard.c and is called from three functions: > > > > command_loop_1, read_menu_command (the one that gives the trouble), and > > > > read_key_sequence_vs. > > > > So I propose as a solution that raw_keybuf_count be initialised to zero > > > > in two of these three functions, but not in read_menu_command (and no > > > > longer in read_key_sequence). I've tried this, and it seems to work. > > > > It has the disadvantage of being ugly, and it makes read_menu_command > > > > only callable as a subfunction of r_k_s. > > > > Has anybody any thoughts on this? > > > Here is how I propose to solve this: > Can you please show a recipe where the current code misbehaves? I've > re-read the thread, and found myself confused wrt the practical > implications of the problem you describe. In the emacs-26 branch, in a Linux tty with GPM configured and working, type: C-h c C-mouse-3 mouse-1 mouse-1 , without moving the mouse. This will end up clicking on "emacs-tutorial". The message printed in the message area is then: (translated from ) at that spot runs the command help-with-tutorial . In the "translated from ", the first event, C-mouse-3 has been overwritten by mouse-1. This mouse-1 is a mouse-click from the menu processing. `describe-key-briefly' can then do nothing other than printing a spurious "translated from" message. With the patch applied, the C-down-mouse-3 survives in the raw key buffer, enabling `describe-key-briefly' to do the Right Thing. It does this by collecting the menu processing's mouse events in a separate buffer, then copying that buffer to the main one afterwards. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 18:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 29349@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151111456824869 (code B ref 29349); Sun, 19 Nov 2017 18:03:01 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 18:02:48 +0000 Received: from localhost ([127.0.0.1]:47897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGTvb-0006T3-QU for submit@debbugs.gnu.org; Sun, 19 Nov 2017 13:02:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGTva-0006Sq-2A for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 13:02:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGTvR-00051F-Vw for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 13:02:41 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGTvR-000516-SK; Sun, 19 Nov 2017 13:02:37 -0500 Received: from [176.228.60.248] (port=2149 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eGTvQ-0007qM-RQ; Sun, 19 Nov 2017 13:02:37 -0500 Date: Sun, 19 Nov 2017 20:02:23 +0200 Message-Id: <83mv3idu4w.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20171119174521.GB9922@ACM> (message from Alan Mackenzie on Sun, 19 Nov 2017 17:45:22 +0000) References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 19 Nov 2017 17:45:22 +0000 > Cc: 29349@debbugs.gnu.org > From: Alan Mackenzie > > In the emacs-26 branch, in a Linux tty with GPM configured and working, > type: > > C-h c C-mouse-3 mouse-1 mouse-1 > > , without moving the mouse. This will end up clicking on > "emacs-tutorial". The message printed in the message area is then: > > (translated from > ) at that spot runs the command > help-with-tutorial > > . In the "translated from ", the first event, > C-mouse-3 has been overwritten by mouse-1. This mouse-1 is a mouse-click > from the menu processing. `describe-key-briefly' can then do nothing > other than printing a spurious "translated from" message. > > With the patch applied, the C-down-mouse-3 survives in the raw key > buffer, enabling `describe-key-briefly' to do the Right Thing. It does > this by collecting the menu processing's mouse events in a separate > buffer, then copying that buffer to the main one afterwards. OK, but then (a) please install the patch on master, not on the release branch, and (b) why do we need the followup patch -- with the mouse-1 events injected into the sequence the "translation" looks correct and even educational. Thanks. From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 20:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 29349@debbugs.gnu.org Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.15111242646309 (code B ref 29349); Sun, 19 Nov 2017 20:45:01 +0000 Received: (at 29349) by debbugs.gnu.org; 19 Nov 2017 20:44:24 +0000 Received: from localhost ([127.0.0.1]:47981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGWRz-0001dh-OO for submit@debbugs.gnu.org; Sun, 19 Nov 2017 15:44:23 -0500 Received: from ocolin.muc.de ([193.149.48.4]:36909 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGWRy-0001dZ-8S for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 15:44:22 -0500 Received: (qmail 41593 invoked by uid 3782); 19 Nov 2017 20:44:19 -0000 Received: from acm.muc.de (p548C7514.dip0.t-ipconnect.de [84.140.117.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Nov 2017 21:44:18 +0100 Received: (qmail 19091 invoked by uid 1000); 19 Nov 2017 20:41:21 -0000 Date: Sun, 19 Nov 2017 20:41:21 +0000 Message-ID: <20171119204121.GE9922@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> <83mv3idu4w.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83mv3idu4w.fsf@gnu.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Sun, Nov 19, 2017 at 20:02:23 +0200, Eli Zaretskii wrote: > > Date: Sun, 19 Nov 2017 17:45:22 +0000 > > Cc: 29349@debbugs.gnu.org > > From: Alan Mackenzie > > In the emacs-26 branch, in a Linux tty with GPM configured and working, > > type: > > C-h c C-mouse-3 mouse-1 mouse-1 > > , without moving the mouse. This will end up clicking on > > "emacs-tutorial". The message printed in the message area is then: > > (translated from > > ) at that spot runs the command > > help-with-tutorial > > . In the "translated from ", the first event, > > C-mouse-3 has been overwritten by mouse-1. This mouse-1 is a mouse-click > > from the menu processing. `describe-key-briefly' can then do nothing > > other than printing a spurious "translated from" message. > > With the patch applied, the C-down-mouse-3 survives in the raw key > > buffer, enabling `describe-key-briefly' to do the Right Thing. It does > > this by collecting the menu processing's mouse events in a separate > > buffer, then copying that buffer to the main one afterwards. > OK, but then (a) please install the patch on master, not on the > release branch, .... I'll do that, but probably not tonight. > .... and (b) why do we need the followup patch -- with the mouse-1 > events injected into the sequence the "translation" looks correct and > even educational. I don't think it looks correct. The C-down-mouse-3 which exists as an essential part of the key sequence has been overwritten in the "translation". The other thing is that if mouse-movements get into the raw event buffer (which I've seen, but for some reason amn't seeing any more) the "translated from" could become objectionably long. I think the "translated from" bit is intended to document a sequence the user is aware of (such as a double click) being translated into a different sequence she's aware of (such as a single click). The mouse-1, I believe, is more part of the user's subconsciousness rather than awareness. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2017 03:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 29349@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.15111488289250 (code B ref 29349); Mon, 20 Nov 2017 03:34:01 +0000 Received: (at 29349) by debbugs.gnu.org; 20 Nov 2017 03:33:48 +0000 Received: from localhost ([127.0.0.1]:48104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGcqB-0002P7-Vl for submit@debbugs.gnu.org; Sun, 19 Nov 2017 22:33:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGcqA-0002Ov-WD for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 22:33:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGcq1-0001k1-4r for 29349@debbugs.gnu.org; Sun, 19 Nov 2017 22:33:41 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGcq1-0001jw-1U; Sun, 19 Nov 2017 22:33:37 -0500 Received: from [176.228.60.248] (port=2535 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eGcq0-0005eu-C0; Sun, 19 Nov 2017 22:33:36 -0500 Date: Mon, 20 Nov 2017 05:33:28 +0200 Message-Id: <83ine5ei9j.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20171119204121.GE9922@ACM> (message from Alan Mackenzie on Sun, 19 Nov 2017 20:41:21 +0000) References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> <83mv3idu4w.fsf@gnu.org> <20171119204121.GE9922@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 19 Nov 2017 20:41:21 +0000 > Cc: 29349@debbugs.gnu.org > From: Alan Mackenzie > > > > With the patch applied, the C-down-mouse-3 survives in the raw key > > > buffer, enabling `describe-key-briefly' to do the Right Thing. It does > > > this by collecting the menu processing's mouse events in a separate > > > buffer, then copying that buffer to the main one afterwards. > > > OK, but then (a) please install the patch on master, not on the > > release branch, .... > > I'll do that, but probably not tonight. > > > .... and (b) why do we need the followup patch -- with the mouse-1 > > events injected into the sequence the "translation" looks correct and > > even educational. > > I don't think it looks correct. The C-down-mouse-3 which exists as an > essential part of the key sequence has been overwritten in the > "translation". That's not what I see here, with your patch applied in keyboard.c, I see this: (translated from ) at that spot runs the command indent-pp-sexp (found in global-map), which is an interactive compiled Lisp function in `lisp-mode.el'. So C-down-mouse-3 is still there, we just have each click in the menus injected into the sequence. What did you see after applying that patch. > The other thing is that if mouse-movements get into the raw event buffer > (which I've seen, but for some reason amn't seeing any more) the > "translated from" could become objectionably long. I don't see that as a problem. > I think the "translated from" bit is intended to document a sequence the > user is aware of (such as a double click) being translated into a > different sequence she's aware of (such as a single click). And that's exactly what happens in this case. > The mouse-1, I believe, is more part of the user's subconsciousness > rather than awareness. But those mouse-1 clicks are real. From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2017 17:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 29349@debbugs.gnu.org Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.15111990439181 (code B ref 29349); Mon, 20 Nov 2017 17:31:01 +0000 Received: (at 29349) by debbugs.gnu.org; 20 Nov 2017 17:30:43 +0000 Received: from localhost ([127.0.0.1]:49277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGpu7-0002O1-5X for submit@debbugs.gnu.org; Mon, 20 Nov 2017 12:30:43 -0500 Received: from ocolin.muc.de ([193.149.48.4]:57726 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGpu5-0002Ns-9N for 29349@debbugs.gnu.org; Mon, 20 Nov 2017 12:30:41 -0500 Received: (qmail 16311 invoked by uid 3782); 20 Nov 2017 17:30:37 -0000 Received: from acm.muc.de (p548C744B.dip0.t-ipconnect.de [84.140.116.75]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Nov 2017 18:30:36 +0100 Received: (qmail 3942 invoked by uid 1000); 20 Nov 2017 17:27:26 -0000 Date: Mon, 20 Nov 2017 17:27:26 +0000 Message-ID: <20171120172726.GA3917@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> <83mv3idu4w.fsf@gnu.org> <20171119204121.GE9922@ACM> <83ine5ei9j.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ine5ei9j.fsf@gnu.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Mon, Nov 20, 2017 at 05:33:28 +0200, Eli Zaretskii wrote: > > Date: Sun, 19 Nov 2017 20:41:21 +0000 > > Cc: 29349@debbugs.gnu.org > > From: Alan Mackenzie [ .... ] > > > .... and (b) why do we need the followup patch -- with the mouse-1 > > > events injected into the sequence the "translation" looks correct and > > > even educational. > > I don't think it looks correct. The C-down-mouse-3 which exists as an > > essential part of the key sequence has been overwritten in the > > "translation". > That's not what I see here, with your patch applied in keyboard.c, I > see this: > (translated from > ) at that spot runs the command > indent-pp-sexp (found in global-map), which is an interactive compiled > Lisp function in `lisp-mode.el'. > So C-down-mouse-3 is still there, we just have each click in the menus > injected into the sequence. What did you see after applying that > patch. Apologies. I wasn't paying enough attention to your post, and I was a little confused. > > The other thing is that if mouse-movements get into the raw event buffer > > (which I've seen, but for some reason amn't seeing any more) the > > "translated from" could become objectionably long. > I don't see that as a problem. OK. > > I think the "translated from" bit is intended to document a sequence the > > user is aware of (such as a double click) being translated into a > > different sequence she's aware of (such as a single click). > And that's exactly what happens in this case. > > The mouse-1, I believe, is more part of the user's subconsciousness > > rather than awareness. > But those mouse-1 clicks are real. OK, again. I think I would still prefer to suppress that "translated from" message, but it's not a strong preference, and not a terribly important point. So, I'll get on and commit my patch to keyboard.c (to master), but leave help.el alone. If those "translated from"s ever do get to be objectionable, as measured by user response, we can always do something about them later. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 05:43:19 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alan Mackenzie Subject: bug#29349: closed (Re: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug.) Message-ID: References: <20171120181227.GA15871@ACM> <20171118093843.GA3819@ACM> X-Gnu-PR-Message: they-closed 29349 X-Gnu-PR-Package: emacs Reply-To: 29349@debbugs.gnu.org Date: Mon, 20 Nov 2017 18:16:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1511201762-17373-1" This is a multi-part message in MIME format... ------------=_1511201762-17373-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #29349: read_key_sequence is only partially recursive. This is a bug. which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 29349@debbugs.gnu.org. --=20 29349: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D29349 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1511201762-17373-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 29349-done) by debbugs.gnu.org; 20 Nov 2017 18:15:43 +0000 Received: from localhost ([127.0.0.1]:49330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGqbf-0004E7-5d for submit@debbugs.gnu.org; Mon, 20 Nov 2017 13:15:43 -0500 Received: from ocolin.muc.de ([193.149.48.4]:32790 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGqbb-000498-O6 for 29349-done@debbugs.gnu.org; Mon, 20 Nov 2017 13:15:40 -0500 Received: (qmail 30914 invoked by uid 3782); 20 Nov 2017 18:15:37 -0000 Received: from acm.muc.de (p548C744B.dip0.t-ipconnect.de [84.140.116.75]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Nov 2017 19:15:37 +0100 Received: (qmail 15876 invoked by uid 1000); 20 Nov 2017 18:12:27 -0000 Date: Mon, 20 Nov 2017 18:12:27 +0000 To: 29349-done@debbugs.gnu.org Subject: Re: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Message-ID: <20171120181227.GA15871@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171119155908.GB4576@ACM> User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 29349-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Bug fixed in master. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1511201762-17373-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 18 Nov 2017 09:41:54 +0000 Received: from localhost ([127.0.0.1]:45544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFzdJ-00083A-Mm for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:53 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFzdI-00082y-Jv for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFzdC-0004AN-8A for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:47 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49273) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eFzdC-0004A5-4t for submit@debbugs.gnu.org; Sat, 18 Nov 2017 04:41:46 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFzdB-00008C-2G for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFzd6-0003zC-51 for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:45 -0500 Received: from ocolin.muc.de ([193.149.48.4]:22973 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eFzd5-0003ui-Ps for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 04:41:40 -0500 Received: (qmail 50993 invoked by uid 3782); 18 Nov 2017 09:41:34 -0000 Received: from acm.muc.de (p548C78EA.dip0.t-ipconnect.de [84.140.120.234]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Nov 2017 10:41:32 +0100 Received: (qmail 4504 invoked by uid 1000); 18 Nov 2017 09:38:43 -0000 Date: Sat, 18 Nov 2017 09:38:43 +0000 To: bug-gnu-emacs@gnu.org Subject: read_key_sequence is only partially recursive. This is a bug. Message-ID: <20171118093843.GA3819@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.4 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.4 (----) Hello, Emacs. In branch emacs-26. I came across this bug whilst working on bug #29272 ("C-h k C-mouse-3" followed by menu selection asks for more keys). In a Linux tty using the GPM mouse package, doing read_key_sequence (the C function in keyboard.c), when a menu action is activated, read_key_sequence calls itself recursively to handle all the mouse manipulation. Unfortunately, the variable raw_keybuf_count is initialised to 0 in r_k_s. This includes in the recursive call. This variable indexes the global buffer raw_keybuf, which accumulates the raw events which make up the key sequence. The result of this is that the events in the recursive call overwrite the stored events of the outer r_k_s call, leaving a mess. r_k_s is static in keyboard.c and is called from three functions: command_loop_1, read_menu_command (the one that gives the trouble), and read_key_sequence_vs. So I propose as a solution that raw_keybuf_count be initialised to zero in two of these three functions, but not in read_menu_command (and no longer in read_key_sequence). I've tried this, and it seems to work. It has the disadvantage of being ugly, and it makes read_menu_command only callable as a subfunction of r_k_s. Has anybody any thoughts on this? ######################################################################### As a second problem, is there any way, preferably at the Lisp level, to determine that a key sequence is a menu key sequence? -- Alan Mackenzie (Nuremberg, Germany). ------------=_1511201762-17373-1-- From unknown Wed Jun 25 05:43:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2017 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 29349@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.151120229821741 (code B ref 29349); Mon, 20 Nov 2017 18:25:02 +0000 Received: (at 29349) by debbugs.gnu.org; 20 Nov 2017 18:24:58 +0000 Received: from localhost ([127.0.0.1]:49357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGqkc-0005ea-0E for submit@debbugs.gnu.org; Mon, 20 Nov 2017 13:24:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34027) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGqkb-0005eO-5C for 29349@debbugs.gnu.org; Mon, 20 Nov 2017 13:24:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGqkT-0003QP-G6 for 29349@debbugs.gnu.org; Mon, 20 Nov 2017 13:24:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGqkT-0003QG-Cd; Mon, 20 Nov 2017 13:24:49 -0500 Received: from [176.228.60.248] (port=3011 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eGqkS-0001YS-KL; Mon, 20 Nov 2017 13:24:49 -0500 Date: Mon, 20 Nov 2017 20:24:41 +0200 Message-Id: <83y3n0dd06.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20171120172726.GA3917@ACM> (message from Alan Mackenzie on Mon, 20 Nov 2017 17:27:26 +0000) References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> <83mv3idu4w.fsf@gnu.org> <20171119204121.GE9922@ACM> <83ine5ei9j.fsf@gnu.org> <20171120172726.GA3917@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Mon, 20 Nov 2017 17:27:26 +0000 > Cc: 29349@debbugs.gnu.org > From: Alan Mackenzie > > So, I'll get on and commit my patch to keyboard.c (to master), but leave > help.el alone. If those "translated from"s ever do get to be > objectionable, as measured by user response, we can always do something > about them later. Agreed. Thanks for working on this tricky issue.