|
From: | Gregory Heytings |
Subject: | Re: Stop frames stealing eachothers' minibuffers! |
Date: | Fri, 27 Nov 2020 18:01:44 +0000 |
User-agent: | Alpine 2.22 (NEB 394 2020-01-19) |
My feeling (I did not look at the code) is that too many things were changed at once. Perhaps this should be done / have been done in two steps, first implement the additional behavior 2, then behavior 3.There are two things we could consider with 'minibuffer-follows-selected-frame' non-nil:- Optionally, don't move the minibuffer window too eagerly. Moving the prompt to my separate *Info* frame that I just want to consult for the interaction I'm about to perform might look gratuitous.
It does, definitely. What you describe here is the behavior of Emacs 21-27, IIUC.
- Optionally, tie the frame where a minibuffer interaction was initiated to that minibuffer and when the ensuing action is performed, make that frame the selected one.
Isn't this what minibuffer-follows-selected-frame t is supposed to do? (Except that the frame is not automatically selected.)
But I think the main task for the moment is to fix the 'minibuffer-follows-selected-frame' nil behavior.
The minibuffer-follows-selected-frame t behavior is also broken, alas, at least it doesn't do what the NEWS item says it should do.
My feeling is also that "minibuffer-follows-selected-frame" is not a good generic name for all these behaviors. Perhaps one should have something like "recursive-minibuffer-behavior" with several possible values:
move-to-selected-frame-on-activation always-on-selected-frame always-on-selected-frame-and-raise-activation-frame tie-to-activation-frame(This is just a draft. Perhaps these options should in fact be split in two separate options.)
[Prev in Thread] | Current Thread | [Next in Thread] |