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: Sat, 22 Feb 2020 10:00:42 -0800 Message-ID: <5bc16edc-a02d-f9ef-ba68-e0d7b94628e4@lp-programming.com> References: <3a518d18-cc99-195b-42a9-adc8ef764d67@lp-programming.com> <83mu9cjqml.fsf@gnu.org> <32ea14fb-1ab8-186e-2534-4d3d2a56d6d8@lp-programming.com> <83pne7hsyp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="25764"; 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 Cc: 39687@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 22 19:49:15 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 1j5Zpz-0006cx-5f for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Feb 2020 19:49:15 +0100 Original-Received: from localhost ([::1]:45088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Zpy-0002s4-8Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Feb 2020 13:49:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49228) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Zpn-0002mE-Ha for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 13:49:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5Zpm-00077X-49 for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 13:49:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44018) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5Zpl-00077S-Tf for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 13:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j5Zpl-0005gk-Rn for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 13:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Logan Perkins Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Feb 2020 18:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39687 X-GNU-PR-Package: emacs Original-Received: via spool by 39687-submit@debbugs.gnu.org id=B39687.158239729921805 (code B ref 39687); Sat, 22 Feb 2020 18:49:01 +0000 Original-Received: (at 39687) by debbugs.gnu.org; 22 Feb 2020 18:48:19 +0000 Original-Received: from localhost ([127.0.0.1]:49991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j5Zp2-0005fX-QO for submit@debbugs.gnu.org; Sat, 22 Feb 2020 13:48:19 -0500 Original-Received: from mr16.netdorm.com ([64.182.101.206]:44274 helo=gw1.litvpn.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j5Z5S-0004O0-JY for 39687@debbugs.gnu.org; Sat, 22 Feb 2020 13:01:11 -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 C160C408C3; Sat, 22 Feb 2020 13:01:15 -0500 (EST) In-Reply-To: <83pne7hsyp.fsf@gnu.org> Content-Language: en-US X-Mailman-Approved-At: Sat, 22 Feb 2020 13:48:15 -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:176401 Archived-At: On 2/22/20 1:27 AM, Eli Zaretskii wrote: > [Please keep the bug address on the CC list, so this whole discussion > is recorded by the Emacs issue tracker.] Oops! I hit reply instead of reply-all, not sure why Thunderbird doesn't make that the default, but I'll be more mindful of that in the future. > >> From: Logan Perkins >> Date: Fri, 21 Feb 2020 10:37:39 -0800 >> >> On 2/21/20 12:23 AM, Eli Zaretskii wrote: >> >> From: Logan Perkins >> >> 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. So I've just done some more testing, with emacs 26.3-r1 (the latest stable version in Gentoo), and emacs 27.0.50_pre20191223, the latest snapshot, both compiled with and without the gutted switch_to_single_kboard... (I'll see about getting the latest development version from the repo probably this evening). Looks like keyboard handling got changed sometime between the two versions. I ran the following sequence in all 4 copies. 1. ./emacs -nw #on seat0 2. M-x start-server 3. ./emacsclient -t #on seat1 4. Switch both to the scratch buffer 5. Put each seat's cursor on its own line 6. On seat0, type abcde 7. On seat1, type 12345 8. On seat0, type C-x 9. On seat1, type u 10. On seat1, type C-x 11. On seat0, type C-c Note that this sequence doesn't try to put emacs into single keyboard mode, so the gutted function has no impact on the results. In emacs-26, step 9 inserts a literal u on seat1's line, step 11 closes emacs. Before step 11, both seat and seat1 display C-x as "breadcrumbs" in the minibuffer. In emacs-27, step 9 undoes seat0's last action (removes abcde), step 11 closes seat1's emacsclient. Obviously, the behaviour in emacs-27 precludes simultanuous input. I also think it's poor behavior, even if we don't unlock the keyboard when the minibuffer is in use, since someone walking away after hitting C-x (or some other partial command) and then connecting later will get unexpected (and probably unseen) results with their first keypress. I'll see if I can figure out which changes in keyboard.c account for the changed behavior, and what the reason for them was.