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