GNU bug report logs -
#56305
29.0.50; 'yes-or-no-p' deselects minibuffer frame
Previous Next
Full log
Message #98 received at 56305 <at> debbugs.gnu.org (full text, mbox):
Hello, Martin.
On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote:
> > I don't follow. If the WM does "Raise on focus", surely it will
> > raise the frame no matter how it acquires the focus. Such focus is
> > here essential for the working of the minibuffer.
> It should not deliberately raise a frame that already has focus.
OK. We could add an extra check for the frame already having the focus.
Is there anything else suboptimal about that proposed fix to emacs-28?
> > Is it not the case that acquiring the focus with Fx_focus_frame
> > would be better than not doing so?
> It does not restore the Emacs 26 behavior. If you look at the reports
> for Bug#8856, Bug#11566 or Bug#11939, you might be able to imagine how
> much time I spent to get the behavior right for Drew's setup back then.
> It's quite sobering to see my efforts from that period get wasted now.
If there are bugs, we fix them. You're surely not saying that the Emacs
26 behaviour was ideal, are you? I'll take a look at these bug reports
this evening.
Part of the problem is that this desired behaviour is not formulated
anywhere, and there don't appear to be tests in 'make check' for it.
In the mean time, how well does the change to master work? It attempts
to fix the cause of (rather than just working around) bug #56305.
> >> AFAICT the most simple approach appears to restore the Emacs 26
> >> behavior for sessions with separate minibuffer frames.
> > I'm not sure how simple that would be. Have you a patch to propose?
> No. I think you should trace all 'minibuffer-follows-selected-frame'
> related changes and make them pertinent to the value of that variable.
> Then people who need the old behavior could get it back by setting that
> variable to nil.
That would be an enormous amount of work, since the code was to a
significant extent in a chaotic state when I made those changes. I think
it is now in a less chaotic state. We surely do not wish to restore the
chaos.
Even If I were to do that, I doubt Eli would accept the result for Emacs
28.2, since it would be too large a change.
Again, how well does my change made last night to master fix the bug?
As a matter of interest, the setting of minibuffer-follows-selected-frame
which gives behaviour closest to the old is non-nil, non-t (e.g. the
symbole `hybrid').
> It was an unwritten rule of Emacs development that a new feature that
> breaks established behavior should be (a) made optional and (b) by
> default turned off. Maybe that rule doesn't apply any more but at
> least (a) should be still supported.
> >> What would the semantics of 'minibuffer-follows-selected-frame' be for
> >> such a session anyway?
> > I've a vague memory of checking this was OK at the time of the change.
> > I can't remember many of the details now, though.
> Then please try to remember. AFAICT 'minibuffer-follows-selected-frame'
> should never impact the behavior of separate minibuffer frames.
Again, bug #56305 was not caused by the m-f-s-f changes, but by some
chaotic code in do_switch_frame which is hopefully now fixed (in master).
I don't agree with you that reverting the minibuffer-follows-select-frame
changes is a good way to fix the current bug, or any similar bugs.
If my last night's commit to master is satisfactory, perhaps it might
somehow be possibly to cherry-pick it into Emacs 28.2.
> martin
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 2 years and 331 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.