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

[Eli Zaretskii <eliz@gnu.org>]

[Please keep the bug address on the CC list, so this whole discussion
is recorded by the Emacs issue tracker.]

> From: Logan Perkins <logan@lp-programming.com>
> Date: Fri, 21 Feb 2020 10:37:39 -0800
> 
> On 2/21/20 12:23 AM, Eli Zaretskii wrote:
>  >> From: Logan Perkins <logan@lp-programming.com>
>  >> Date: Wed, 19 Feb 2020 21:01:30 -0800
>  >>
>  >> Is there some further reason to lock the keyboard that I haven't
>  >> considered?
>  >
>  > Can we back up a little, and discuss the use cases where the current
>  > behavior presents a limitation? Is quitting in the other clients the
>  > only one, or are there more?
> 
> Quitting in other clients is one, but fairly minor (C-z; kill %1 will
> get you out of it). Switching clients generally is another minor case.
> If you walk away with the minibuffer open by accident, and then try to
> use a remote client (via SSH or similar) later, it's locked (you can
> work around this by registering a SIGUSR handler to close the
> minibuffer, but that's not ideal).

These seem to be valid use cases, so I tend to agree we should have an
easier way of breaking out of the minibuffer input in another client.

>  > 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.

>  > In any case, we thank you for your interest in Emacs and look forward
>  > to seeing your contributions, but I suggest to start your legal
>  > paperwork rolling now, because changes you are talking about will
>  > probably be non-trivial in length, so we will need a copyright
>  > assignment from you in order to accept the changes. If you agree, I
>  > can send you the form to fill and the instructions to go with it.
> 
> I have no problem assigning copyright for my work on FSF projects to the
> FSF. I live in Eastern Washington, and am self employed, so getting
> the paperwork done should be about as trivial as it can be.

Thanks, I will send the form off-list.