bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[Alan Mackenzie]

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.