From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Logan Perkins Newsgroups: gmane.emacs.bugs Subject: bug#39687: 26.3; Add customize-variable option for not locking keyboards Date: Mon, 18 May 2020 18:15:15 -0700 Message-ID: <6a23af03-d597-6e3e-ceb4-5fb1305a496a@lp-programming.com> References: <3a518d18-cc99-195b-42a9-adc8ef764d67@lp-programming.com> <83mu9cjqml.fsf@gnu.org> <32ea14fb-1ab8-186e-2534-4d3d2a56d6d8@lp-programming.com> <83pne7hsyp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------17DD87586F2F79AE4ECEE762" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="68808"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: 39687@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 19 03:16:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jaqra-000Hhl-2u for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 May 2020 03:16:10 +0200 Original-Received: from localhost ([::1]:53656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaqrZ-000787-4l for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 May 2020 21:16:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaqrS-000780-TZ for bug-gnu-emacs@gnu.org; Mon, 18 May 2020 21:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37112) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaqrS-0003sv-KC for bug-gnu-emacs@gnu.org; Mon, 18 May 2020 21:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jaqrS-0006vO-GV for bug-gnu-emacs@gnu.org; Mon, 18 May 2020 21:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Logan Perkins Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 May 2020 01:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39687 X-GNU-PR-Package: emacs Original-Received: via spool by 39687-submit@debbugs.gnu.org id=B39687.158985094326589 (code B ref 39687); Tue, 19 May 2020 01:16:02 +0000 Original-Received: (at 39687) by debbugs.gnu.org; 19 May 2020 01:15:43 +0000 Original-Received: from localhost ([127.0.0.1]:48658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaqr8-0006un-Or for submit@debbugs.gnu.org; Mon, 18 May 2020 21:15:43 -0400 Original-Received: from mr15.netdorm.com ([64.182.101.205]:46642 helo=gw2.litvpn.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaqr4-0006uW-La for 39687@debbugs.gnu.org; Mon, 18 May 2020 21:15:41 -0400 Original-Received: from [192.168.1.43] (unknown [63.227.187.208]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gw2.litvpn.com (Postfix) with ESMTPSA id EFFDEE05BC; Mon, 18 May 2020 21:15:46 -0400 (EDT) In-Reply-To: <83pne7hsyp.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180570 Archived-At: This is a multi-part message in MIME format. --------------17DD87586F2F79AE4ECEE762 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/22/20 1:27 AM, Eli Zaretskii wrote: > > Also, are you implicitly saying that several persons work >> > simultaneously vis-à-vis the same Emacs server? Because if not, I'm >> > not sure I understand how simultaneous need to input from different >> > clients could even happen. >> >> That's exactly the use-case where it matters most. If you're familiar >> with Ludum Dare and similar code-sprints, it's pretty common to >> have multiple people working on the same files at the same time. Having >> a shared editor makes it faster and easier to draw attention to exactly >> where one person needs help. It's also great for teaching (when you >> aren't physically in front of the same computer), or for onboarding new >> team members. Screen (the terminal multiplexer) can be used to similar >> effect, but the ability to simultaneously edit the *same* file is >> specific to emacs. > I don't understand what you expect Emacs to do in these use cases. If > we process inputs from several clients as they arrive, we could > produce results that are unexpected and even disastrous. For example, > suppose we receive C-x from one client followed by C-u from another > followed by C-s from the first one -- if we process these in the order > they were received, the result will be none of what the two clients > intended. > > Maybe you thought that our input code will process input in chunks of > complete sequences, and thus avoid the above-mentioned disasters, but > then (a) I think we will need a very thorough restructuring of the > current code in keyboard.c, as it currently decides on this > dynamically; and (b) you will still have the same problem if the user > of one client types C-x and then pauses for some reason. > > So I'm afraid I don't see what kind of solution is sought for here, > please clarify. Alright, I finally had time to dig in to what commit broke the split input. The commit was e3cebbb839fc94f314659bf667c6790edebf4297, from 19 October 2019. It was to fix Bug#37782, and improve the fix for Bug#5095. Reverting that commit resolves the issue, but obviously reintroduces Bug#37782. I *think* I have a patch that still fixes the current behavior, and does not reintroduce those two bugs, I've included it below. Basically, the fix for Bug#5095 should only be applied if we are in the right context. If we're not, the if block above puts a Qswitch_frame at the head of the side queue and triggers replay_entire_sequence, so we just skip the second check. It'll get run again and catch the interruption on the next pass, but in the right context. diff --git a/src/keyboard.c b/src/keyboard.c index f9b9399d50..90ed1d3e9a 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -9599,17 +9599,23 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt, (interrupted_kboard, Fcons (make_lispy_switch_frame (frame), KVAR (interrupted_kboard, kbd_queue))); + mock_input = 0; + } + else + { + if (FIXNUMP (key) && XFIXNUM (key) != -2) + { + /* If interrupted while initializing terminal, we + need to replay the interrupting key. See + Bug#5095 and Bug#37782. */ + mock_input = 1; + keybuf[0] = key; + } + else + { + mock_input = 0; + } } - if (FIXNUMP (key) && XFIXNUM (key) != -2) - { - /* If interrupted while initializing terminal, we - need to replay the interrupting key. See - Bug#5095 and Bug#37782. */ - mock_input = 1; - keybuf[0] = key; - } - else - mock_input = 0; goto replay_entire_sequence; } } --------------17DD87586F2F79AE4ECEE762 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/22/20 1:27 AM, Eli Zaretskii wrote:

> Also, are you implicitly saying that several persons work 
 > simultaneously vis-à-vis the same Emacs server? Because if not, I'm
 > not sure I understand how simultaneous need to input from different
 > clients could even happen.

That's exactly the use-case where it matters most. If you're familiar
with Ludum Dare and similar code-sprints, it's pretty common to
have multiple people working on the same files at the same time. Having
a shared editor makes it faster and easier to draw attention to exactly
where one person needs help. It's also great for teaching (when you
aren't physically in front of the same computer), or for onboarding new
team members. Screen (the terminal multiplexer) can be used to similar
effect, but the ability to simultaneously edit the *same* file is
specific to emacs.

I don't understand what you expect Emacs to do in these use cases.  If
we process inputs from several clients as they arrive, we could
produce results that are unexpected and even disastrous.  For example,
suppose we receive C-x from one client followed by C-u from another
followed by C-s from the first one -- if we process these in the order
they were received, the result will be none of what the two clients
intended.

Maybe you thought that our input code will process input in chunks of
complete sequences, and thus avoid the above-mentioned disasters, but
then (a) I think we will need a very thorough restructuring of the
current code in keyboard.c, as it currently decides on this
dynamically; and (b) you will still have the same problem if the user
of one client types C-x and then pauses for some reason.

So I'm afraid I don't see what kind of solution is sought for here,
please clarify.

Alright, I finally had time to dig in to what commit broke the split input.  
The commit was e3cebbb839fc94f314659bf667c6790edebf4297, from 19 October 2019.
It was to fix Bug#37782, and improve the fix for Bug#5095.  

Reverting that commit resolves the issue, but obviously reintroduces Bug#37782.
I *think* I have a patch that still fixes the current behavior, and does not 
reintroduce those two bugs, I've included it below.  Basically, the fix for 
Bug#5095 should only be applied if we are in the right context.  If we're not, 
the if block above puts a Qswitch_frame at the head of the side queue and 
triggers replay_entire_sequence, so we just skip the second check.  It'll get
run again and catch the interruption on the next pass, but in the right context.

diff --git a/src/keyboard.c b/src/keyboard.c
index f9b9399d50..90ed1d3e9a 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -9599,17 +9599,23 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt,
                      (interrupted_kboard,
                       Fcons (make_lispy_switch_frame (frame),
                              KVAR (interrupted_kboard, kbd_queue)));
+                   mock_input = 0;
+                 }
+               else
+                 {
+                   if (FIXNUMP (key) && XFIXNUM (key) != -2)
+                     {
+                       /* If interrupted while initializing terminal, we
+                          need to replay the interrupting key.  See
+                          Bug#5095 and Bug#37782.  */
+                       mock_input = 1;
+                       keybuf[0] = key;
+                     }
+                   else
+                     {
+                       mock_input = 0;
+                     }
                  }
-                if (FIXNUMP (key) && XFIXNUM (key) != -2)
-                  {
-                    /* If interrupted while initializing terminal, we
-                       need to replay the interrupting key.  See
-                       Bug#5095 and Bug#37782.  */
-                    mock_input = 1;
-                    keybuf[0] = key;
-                  }
-                else
-                  mock_input = 0;
                goto replay_entire_sequence;
              }
          }
--------------17DD87586F2F79AE4ECEE762--