bug#39687: 26.3; Add customize-variable option for not locking keyboards

[Logan Perkins]

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