GNU bug report logs - #39687
26.3; Add customize-variable option for not locking keyboards

Previous Next

Full log

Message #48 received at 39687 <at> debbugs.gnu.org (full text, mbox):

From: Logan Perkins <logan <at> lp-programming.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39687 <at> debbugs.gnu.org
Subject: Re: bug#39687: 26.3;
 Add customize-variable option for not locking keyboards
Date: Wed, 21 Jul 2021 15:44:46 -0700

On Wed, 21 Jul 2021 15:08:45 -0700,
Lars Ingebrigtsen wrote:
> 
> Logan Perkins <logan <at> lp-programming.com> writes:
> > Hopefully, with that sorted, we can discuss the issues around
> > `temporarily_switch_to_single_kboard`.
> 
> Yes.  This is basically the same issue as in bug#9729, so I'll merge the
> two.  And I think it'd be great to have this fixed.

Yes, it is the same as bug#9729, or at least the same underlying
cause/problem.  I missed that bug when I went looking to see if this
was already supported, as that only mentions it being a problem in
context of opening files.  The underlying problem applies anytime the
minibuffer is in use.  Still, makes sense to merge them.  

I just read that bug report end-to-end.  I *think* for part of its
discussion they were running into the fix from bug#5095.  While it is
true that emacs (being single threaded) only reads from one virtual
keyboard at a time, it is capable of switching between virtual
keyboards and interleaving their input.  Nor is it the case that only
one minibuffer input is possible at a time.  This is fundamentally how
`enable-recursive-minibuffers` works, and each client has its own
minibuffer even when that is `nil`.

Anyway, the fix for this needs to be gated behind an option (at least
initially), as it does cause some odd interactions with the
minibuffer.  (For example, when two clients both open a minibuffer,
when the first client finishes with the minibuffer, the prompt
vanishes on the second client, and the focus switches away, but the
minibuffer remains open).  I think these problems can be worked
through, but until they are, we need people to opt-in to them.  It's
also worth noting that, without recursive minibuffers, the vanishing
minibuffer issue doesn't occur, but one client gets a minibuffer in
use message instead.

> 
> >  I still have the assignment document and can submit
> > it again if that would help.
> 
> That'd be good; or ask copyright-clerk <at> fsf.org what the status is.
> 

I sent a message to that email an hour (ish) ago.  

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.