Package: emacs;
Reported by: martin rudalics <rudalics <at> gmx.at>
Date: Wed, 29 Jun 2022 17:55:01 UTC
Severity: normal
Found in version 29.0.50
View this message in rfc822 format
From: Drew Adams <drew.adams <at> oracle.com> To: Alan Mackenzie <acm <at> muc.de>, martin rudalics <rudalics <at> gmx.at> Cc: "56305 <at> debbugs.gnu.org" <56305 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>, "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca> Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Sun, 10 Jul 2022 16:13:03 +0000
> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.