GNU bug report logs -
#39687
26.3; Add customize-variable option for not locking keyboards
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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;
}
}
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 138 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.