From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Logan Perkins Newsgroups: gmane.emacs.bugs Subject: bug#39687: 26.3; Add customize-variable option for not locking keyboards Date: Wed, 19 Feb 2020 21:01:30 -0800 Message-ID: <3a518d18-cc99-195b-42a9-adc8ef764d67@lp-programming.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86530"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 To: 39687@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 20 07:30:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j4fLi-000MO8-BW for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Feb 2020 07:30:14 +0100 Original-Received: from localhost ([::1]:36816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4fLh-000803-Cu for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Feb 2020 01:30:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57639) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4fLY-0007zi-2M for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 01:30:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4fLW-0002Y5-QW for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 01:30:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4fLW-0002Xc-Nt for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 01:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4fLW-0000WH-Kf for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 01:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Logan Perkins Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Feb 2020 06:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 39687 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.15821801881939 (code B ref -1); Thu, 20 Feb 2020 06:30:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 20 Feb 2020 06:29:48 +0000 Original-Received: from localhost ([127.0.0.1]:43741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4fLF-0000VB-Pa for submit@debbugs.gnu.org; Thu, 20 Feb 2020 01:29:47 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:59232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4dy3-0004gn-GA for submit@debbugs.gnu.org; Thu, 20 Feb 2020 00:01:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49177) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4dy2-0000F6-3t for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 00:01:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4dy0-0004Y2-Pw for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 00:01:41 -0500 Original-Received: from host29.netdorm.com ([64.182.105.29]:36626 helo=gw1.litvpn.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4dy0-0004Wx-Iw for bug-gnu-emacs@gnu.org; Thu, 20 Feb 2020 00:01:40 -0500 Original-Received: from [192.168.1.43] (unknown [63.227.187.208]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gw1.litvpn.com (Postfix) with ESMTPSA id 5CF114079C for ; Thu, 20 Feb 2020 00:01:48 -0500 (EST) Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Mailman-Approved-At: Thu, 20 Feb 2020 01:29:44 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176276 Archived-At: In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.11) of 2020-01-28 built on gentoo-server Windowing system distributor 'The X.Org Foundation', version 11.0.12005000 System Description: Gentoo Base System release 2.6 This is a feature request more than a bug report. When using the built-in server (either via `emacs --daemon` or `server-start`) + emacsclient, use of the minibuffer from one client completely blocks other clients (they can't even quit until the mini buffer finishes). This is governed by calls to `temporarily_switch_to_single_kboard(struct frame *f)` in `keyboard.c`. If I understand correctly, there are two reasons for locking other clients while the minibuffer is in use. First, the input for the minibuffer is stored in a single global variable; while enabling recursive minibuffers is possible, bottom line is there can only be *one* active mini buffer at a time. Locking secondary inputs reduces the potential for confusion with fighting over the minibuffer. Additionally, sometimes there is something which requires a user response (such as confirmation on killing a modified buffer), and resolving that is simpler if the state isn't changing in the background. On the other hand, even with a confirmation box open, a user can switch away from the minibuffer and continue changing state (potentially even opening a recursive minibuffer), so I don't think the second case is sufficient cause to disallow multi-keyboard mode when the minibuffer is in use. As for the first issue, I don't think the present behavior is clearly best, as it doesn't *ignore* secondary keyboard input, it *queues* it, executing it in one block when the minibuffer ends. This can cause unexpected issues for novice users. Also, the inability to even close the client (short of SIGTERMing it) is not ideal. I've gutted the `temporarily_switch_to_single_kboard(struct frame *f)` in `keyboard.c` on a test system, and successfully used it with multiple people sharing a single server instance (on a joint project), and it works reasonably well. I'd like to propose adding a customizeable variable in the `minibuffer` group which disables locking the other keyboards. Ideally, the other clients should get a "minibuffer in use" message in their minibuffers so users can see when someone is using the minibuffer. I am happy to work on this, and submit patches for it, but would appreciate some advice before I start. Is there some further reason to lock the keyboard that I haven't considered? I think it's better to use the customizeable variable to prevent the call to temporarily_switch_to_single_kboard, rather than have that function not do what it's name implies it does. Should I intercept all calls to it based on one new variable? Or should I split general minibuffer use from confirmation uses, and so on? (Looks like 3-4 different places it's called in the source). Should I make the behavior depend on some elisp function? I think that might be the easiest way to support the "minibuffer in use" message and the like, but I'm not sure what the downside would be. Is it a waste of time for me to submit patches related to this feature? If there's zero interest in adding this, or it would be less work for someone else to write it than review my patches, I won't waste your time sending them. Regards, Logan Perkins