From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Sun, 10 Jul 2022 16:55:49 +0000 Message-ID: References: <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2861"; mail-complaints-to="usenet@ciao.gmane.io" Cc: martin rudalics , "56305@debbugs.gnu.org" <56305@debbugs.gnu.org>, acm@muc.de, Eli Zaretskii , "monnier@iro.umontreal.ca" To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 10 18:56:11 2022 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 1oAaE6-0000YY-GK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 18:56:10 +0200 Original-Received: from localhost ([::1]:56898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAaE5-0003e7-3W for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 12:56:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAaDy-0003ci-Rt for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAaDy-0003Qc-Jq for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oAaDy-0007nN-I4 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2022 16:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.165747216029958 (code B ref 56305); Sun, 10 Jul 2022 16:56:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 10 Jul 2022 16:56:00 +0000 Original-Received: from localhost ([127.0.0.1]:37744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAaDv-0007n6-NI for submit@debbugs.gnu.org; Sun, 10 Jul 2022 12:56:00 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:22764 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1oAaDt-0007mo-DK for 56305@debbugs.gnu.org; Sun, 10 Jul 2022 12:55:58 -0400 Original-Received: (qmail 60640 invoked by uid 3782); 10 Jul 2022 16:55:50 -0000 Original-Received: from acm.muc.de (p4fe15b15.dip0.t-ipconnect.de [79.225.91.21]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Jul 2022 18:55:49 +0200 Original-Received: (qmail 10251 invoked by uid 1000); 10 Jul 2022 16:55:49 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:236588 Archived-At: Hello, Drew. [ Top-posting, because the ideas in your post are a bit spread out. ] I rather agree with most of what you've said here. In fact in the later posts here, between Martin and me, we've lamented the fact that the focus gets switched frivolously between frames. I've proposed cleaning things up such that select-frame and select-window would NOT switch the focus under any circumstances (as is documented in the Elisp manual). Perhaps if/when we do implement such a clean-up, you could come on board as one of the main customers, with test cases and what-not. Even then, there are times when the focus _must_ be set, for example when the frame previously focused gets deleted. The specific problem with yes-or-no-p in this bug was that the focus did NOT end up on the minibuffer frame, and this was intolerable for users. (At least, it was intolerable for Martin R.) I analysed the cause, and found some code redirecting the focus frivolously, going back to 1992. I have removed this from master, which appears to solve the bug, at least more or less. We still have problems getting a fix suitable (i.e. non-dangerous) for the 28.2 pretest, and this is still under discussion. However this bug is purely about where the focus goes when yes-or-no-p is invoked, namely the minibuffer frame. There is absolutely no intention of stopping users moving the focus around while the MB is active. -- Alan Mackenzie (Nuremberg, Germany). On Sun, Jul 10, 2022 at 16:13:03 +0000, Drew Adams wrote: > > I think that might be over-stating things. > > Most of the time, users are just going to be > > typing "yes" or "no" here. > [Big caveat: I'm not following this thread.] > FTR/FWIW - > I expect that there's lots in here that I don't > agree with. > But there's also lots that's happened over the > last few releases that I don't agree with, wrt > Emacs grabbing or changing the focus (frame) > from what my code or user actions have decided. > I tend to think that such changes have been > essentially gratuitous (unconsciously so), even > if someone thought they were called for to fix > this or that reported problem. Fixing one user > problem can easily mess up other things. And > fiddling with frame focus is a particularly > sensitive kind of fiddling - including because > different platforms can do things differently. > ____ > I'll just say this wrt `yes-or-no-p' - at > least wrt how it _used_ to behave. > `yes-or-no-p' is just a function that reads > minibuffer input. As far as that reading's > concerned, it's "modal" in this sense _only_: > you can't end the reading of minibuffer input > without hitting `C-g' or `C-]' or similar, or > else entering `yes' or `no'. That's it - > nothing more modal than that. > There's _nothing_ that prevents a user (and > code invoked by the user hitting a key etc.) > from changing the focus to another window or > frame, and carrying out any number of actions > there. Even multiple frames, successively. > (Not to mention recursive minibuffers.) > There should be _ZERO_ expectation by Emacs > that focus should remain with the minibuffer > during `yes-or-no-p', any more than during > any other minibuffer interaction. > [`y-or-n-p' _has_ been thoroughly modal in > the past. It expressly did _not_ use the > minibuffer. But now it reads input from > the minibuffer...] > Users and code need to be in control, able > to change focus away from the minibuffer > and back to it. Emacs really shouldn't get > in the way. > Once Someone(TM) gets the idea that focus > needs to be kept in the minibuffer, we're > headed down the road to knee-capping code > and user - crippling the minibuffer. > And that, no doubt from good intentions. > Good intentions, but maybe some ignorance > of minibuffer possibilities. > The minibuffer is just a buffer - there's > _NO_ prescribed, ineluctable, "consistent", > simple behavior that can be counted on. > And there should be none. That's a GOOD > THING. > At least that was the case before any > sanitizing mission started blasting away. > More and more, it seems, if you write code > that takes advantage of how Emacs behaves > you'll lose, because Someone will climb > under the pavement and make a fundamental > change that "fixes" some perceived problem, > upsetting the apple cart above. > ____ > Here's the general problem I see wrt someone > trying to "regularize", make "consistent", > "simplify" - or whatever - minibuffer > interaction, including focus: > You'll undoubtedly screw things up by making > simplistic assumptions - either about user > or programmatic behavior or about state at > some point. Sorry to say that (really), but > that's my conclusion. I know that people > mean well, but that's what happens, IMO. > Why do I say that? Because I think that's > what's happened, to break my code. > Starting with Emacs 26 (I think Stefan has > pointed to this) - and definitely with Emacs > 27, Emacs has apparently tried to get too > smart about such focus things - making more > assumptions about what users and code will > or should do. > The result: _Emacs changes the focus when > it shouldn't_. > I can't be more precise than that. I've > given up. I don't have the time to chase > it. I use only Emacs 26 and earlier now. > My code, including as a result of user > actions, _explicitly_ uses things such as > `select-frame-set-input-focus'. IOW, my > code, and users, control the UI, including > focus. > Alas, that careful control has been broken > by Emacs. No doubt Someone thought he was > doing Emacs and its users a favor "cleaning" > things up and making things more "consistent". > Nothing but good intentions, no doubt. No > carelessness, I assume. > Instead of giving code & users _more_ control, > to handle frame focus as they see fit, Emacs > has itself apparently tried to take control. > Too smart for its own britches. > The fault is in accidental hubris that can > creep in by not appreciating that Emacs > allows for umpteen _zillion_ different > states and interactions. > It's all too easy to think that every user, > use, use case, and setup (configuration), > and all Emacs code, are more or less similar > to your own use, setup, code etc. > Someone makes a "consistency/cleanup" change, > tries it out with a few (even many) setups, > and considers it a job well done. Shiny. > Maybe someone else reports, in vague terms, > that Emacs now breaks things. Without a > clear, simple recipe to show that, Emacs > just goes ahead with the new "improvement". > And on it goes. > What was stable for many years becomes > something different, less flexible, etc. > The minibuffer, in particular, is just a > buffer. And it can be in its own frame. > Users and code can switch focus to & from > that frame, including during minibuffer > interaction. > And other frames (e.g. a dedicated > *Completions* frame) can have their focus > redirected to the minibuffer frame. And > such redirection doesn't prevent code or > users from switching the focus to such a > frame, and back again. > In short, it should be possible to do > pretty much _anything_ while the > minibuffer is active. > And that - especially - includes changing > the input focus among different frames.