Re: Stop frames stealing eachothers' minibuffers!

Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

I am reporting three technical problems with the current minibuffer
quitting behaviour (on commit 20e48b6fd6cade60e468140a66127d326abfb8ff,
after your patch was applied):

1) If you enter a (non-minibuffer) M-x recursive-edit inside a
   minibuffer, abort-minibuffers (bound to C-g) will quit the inner
   recursive edit but not the minibuffer, which is what the command's
   doc-string suggests. This is only a minor inconvenience. In fact,
   this behaviour is consistent with previous Emacs versions.

2) If you
   - set minibuffer-follows-selected-frame to nil,
   - open a minibuffer on frame A,
   - open a new inner minibuffer on frame B,
   - enter a M-x recursive-edit in this minibuffer,
   - select frame A's outer minibuffer, press C-g and answer yes,
   abort-minibuffers will fail to quit the outer minibuffer, it will not
   be visible in the mini-window, but you can check by evaluating
   (minibuffer-depth).

3) This one is a bit opinionated: internal_catch now has undocumented
   special handling for Qexit.

I have come up with an idea to fix all of the above problems:
- revert the special handling of Qexit in internal_catch
- in read_minibuf, wrap the call to recursive_edit_1 with a catch for
  symbol exit-read-minibuffer
- throwing to this symbol with nil or t shall have the same effect as
  throwing nil or t to 'exit
- throwing to this symbol with a natural number N shall re-throw to this
  same symbol with N-1 (or quit if N<=1), effectively quitting out of N
  minibuffers
- make exit-minibuffer throw to 'exit-read-minibuffer
- make quit-minibuffers throw to 'exit-read-minibuffer with
  minibuf_level - this_minibuf_depth () + 1

Please let me know if you find this idea worthy of implementing and if
you want me to try implementing it and posting a patch.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, jakanakaevangeli.

Thank you very much indeed for your post, which I have treated as a bug
report.

On Wed, Feb 03, 2021 at 16:20:50 +0100, jakanakaevangeli wrote:
> I am reporting three technical problems with the current minibuffer
> quitting behaviour (on commit 20e48b6fd6cade60e468140a66127d326abfb8ff,
> after your patch was applied):

> 1) If you enter a (non-minibuffer) M-x recursive-edit inside a
>    minibuffer, abort-minibuffers (bound to C-g) will quit the inner
>    recursive edit but not the minibuffer, which is what the command's
>    doc-string suggests. This is only a minor inconvenience. In fact,
>    this behaviour is consistent with previous Emacs versions.

Indeed, in my patch I failed completely to account for recursive edits.
The behaviour you report is indeed a bug.

> 2) If you
>    - set minibuffer-follows-selected-frame to nil,
>    - open a minibuffer on frame A,
>    - open a new inner minibuffer on frame B,
>    - enter a M-x recursive-edit in this minibuffer,
>    - select frame A's outer minibuffer, press C-g and answer yes,
>    abort-minibuffers will fail to quit the outer minibuffer, it will not
>    be visible in the mini-window, but you can check by evaluating
>    (minibuffer-depth).

Yes.  This is a bug closely related to the above.

> 3) This one is a bit opinionated: internal_catch now has undocumented
>    special handling for Qexit.

Yes, also.  I'll be thinking about this in the coming days.  It would
probably be a good idea to put a comment describing the special handling
for (throw 'exit t) before the function.

I notice also, on the page "Text from Minibuffer" in the Elisp manual, I
neglected to change the description of the binding of C-g from the
former `abort-recursive-edit' to the now current `abort-minibuffers'.

> I have come up with an idea to fix all of the above problems:
> - revert the special handling of Qexit in internal_catch
> - in read_minibuf, wrap the call to recursive_edit_1 with a catch for
>   symbol exit-read-minibuffer
> - throwing to this symbol with nil or t shall have the same effect as
>   throwing nil or t to 'exit
> - throwing to this symbol with a natural number N shall re-throw to this
>   same symbol with N-1 (or quit if N<=1), effectively quitting out of N
>   minibuffers
> - make exit-minibuffer throw to 'exit-read-minibuffer
> - make quit-minibuffers throw to 'exit-read-minibuffer with
>   minibuf_level - this_minibuf_depth () + 1

> Please let me know if you find this idea worthy of implementing and if
> you want me to try implementing it and posting a patch.

It's an ingenious idea, but to be honest I don't think it's the best way
to solve the problems.  The handling you're proposing for
exit-read-minibuffer is no less complicated than what's already there
for exit.  I can't help feeling that there would be nasty interactions
between the two catch tags exit and exit-read-minibuffer.  I think it's
documented in the Elisp manual that (throw 'exit t) is the way to abort
a minibuffer and its calling function.

Also, this part of the Emacs C code is horrendous to adapt and maintain,
as I've discovered since November.  ;-)  It is full of special cases
that one is scarcely aware of (a minibuffer in its own frame, for
example).  To be honest, I've become tired of trying to make this
section of the code work properly, but having started on it, I've got to
finish it.

Anyhow, I've attempted to solve the problems you reported, and come up
with the following patch, which should apply cleanly to the savannah
master branch.  I'd be grateful if you could try it out, and report back
as to whether the bugs you noticed are actually fixed by it, or what is
still not quite right.



diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 03cc70c0d4..f8143feedd 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2116,16 +2116,18 @@ minibuffer-hide-completions
 (defun exit-minibuffer ()
   "Terminate this minibuffer argument."
   (interactive)
+  (when (not (minibuffer-innermost-command-loop-p))
+    (error "%s" "Not in most nested command loop"))
+  (when (not (innermost-minibuffer-p))
+    (error "%s" "Not in most nested minibuffer"))
   ;; If the command that uses this has made modifications in the minibuffer,
   ;; we don't want them to cause deactivation of the mark in the original
   ;; buffer.
   ;; A better solution would be to make deactivate-mark buffer-local
   ;; (or to turn it into a list of buffers, ...), but in the mean time,
   ;; this should do the trick in most cases.
-  (when (innermost-minibuffer-p)
-    (setq deactivate-mark nil)
-    (throw 'exit nil))
-  (error "%s" "Not in most nested minibuffer"))
+  (setq deactivate-mark nil)
+  (throw 'exit nil))
 
 (defun self-insert-and-exit ()
   "Terminate minibuffer input."
diff --git a/src/eval.c b/src/eval.c
index 5bf3faebc8..d4456d8b46 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1197,15 +1197,12 @@ internal_catch (Lisp_Object tag,
 	   exit all minibuffers more deeply nested than the current
 	   one.  */
 	{
-	  EMACS_INT mini_depth = this_minibuffer_depth (Qnil);
-	  if (mini_depth && mini_depth != minibuffer_quit_level)
-	    {
-	      if (minibuffer_quit_level == -1)
-		minibuffer_quit_level = mini_depth;
-	      if (minibuffer_quit_level
-		  && (minibuf_level > minibuffer_quit_level))
-		Fthrow (Qexit, Qt);
-	    }
+          if (minibuffer_quit_level == -1)
+            minibuffer_quit_level = this_minibuffer_depth (Qnil);
+          if (minibuf_level > minibuffer_quit_level
+              || command_loop_level
+              > minibuf_c_loop_level (minibuffer_quit_level))
+            Fthrow (Qexit, Qt);
 	  else
 	    minibuffer_quit_level = -1;
 	}
diff --git a/src/lisp.h b/src/lisp.h
index f658868544..035d7b37fc 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4349,6 +4349,7 @@ extern bool is_minibuffer (EMACS_INT, Lisp_Object);
 extern EMACS_INT this_minibuffer_depth (Lisp_Object);
 extern EMACS_INT minibuf_level;
 extern Lisp_Object get_minibuffer (EMACS_INT);
+extern EMACS_INT minibuf_c_loop_level (EMACS_INT depth);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
 extern void barf_if_interaction_inhibited (void);
@@ -4368,6 +4369,7 @@ extern void syms_of_casetab (void);
 
 /* Defined in keyboard.c.  */
 
+extern EMACS_INT command_loop_level;
 extern Lisp_Object echo_message_buffer;
 extern struct kboard *echo_kboard;
 extern void cancel_echoing (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index 949c3d989d..0745c095bb 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -41,6 +41,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
    minibuffer recursions are encountered.  */
 
 Lisp_Object Vminibuffer_list;
+Lisp_Object Vcommand_loop_level_list;
 
 /* Data to remember during recursive minibuffer invocations.  */
 
@@ -64,6 +65,7 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 static Lisp_Object nth_minibuffer (EMACS_INT depth);
+static void restore_minibuf_window (Lisp_Object mw);
 
 \f
 /* Return TRUE when a frame switch causes a minibuffer on the old
@@ -389,6 +391,21 @@ No argument or nil as argument means use the current buffer as BUFFER.  */)
     : Qnil;
 }
 
+DEFUN ("minibuffer-innermost-command-loop-p", Fminibuffer_innermost_command_loop_p,
+       Sminibuffer_innermost_command_loop_p, 0, 1, 0,
+       doc: /* Return t if BUFFER is a minibuffer at the current command loop level.
+No argument or nil as argument means use the current buffer as BUFFER.  */)
+  (Lisp_Object buffer)
+{
+  EMACS_INT depth;
+  if (NILP (buffer))
+    buffer = Fcurrent_buffer ();
+  depth = this_minibuffer_depth (buffer);
+  return depth && minibuf_c_loop_level (depth) == command_loop_level
+    ? Qt
+    : Qnil;
+}
+
 /* Return the nesting depth of the active minibuffer BUFFER, or 0 if
    BUFFER isn't such a thing.  If BUFFER is nil, this means use the current
    buffer.  */
@@ -598,7 +615,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 
   if (minibuf_level > 1
       && minibuf_moves_frame_when_opened ()
-      && !minibuf_follows_frame ())
+      && (!minibuf_follows_frame ()
+	  || (!EQ (mini_frame, selected_frame))))
     {
       EMACS_INT i;
 
@@ -835,7 +853,18 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
-  recursive_edit_1 ();
+  {
+    /* Note that here it doesn't suffice to record MINIBUF_WINDOW in a local
+       variable.  It must be correct in `read_minibuf_unwind' in the event of
+       a non-local exit.  */
+    int count2 = SPECPDL_INDEX ();
+
+    record_unwind_protect (restore_minibuf_window, minibuf_window);
+
+    recursive_edit_1 ();
+
+    unbind_to (count2, Qnil);
+  }
 
   /* We've exited the recursive edit without an error, so switch the
      current window away from the expired minibuffer window.  */
@@ -908,6 +937,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   return val;
 }
 
+static void restore_minibuf_window (Lisp_Object mw)
+{
+  minibuf_window = mw;
+}
+
 /* Return true if BUF is a particular existing minibuffer.  */
 bool
 is_minibuffer (EMACS_INT depth, Lisp_Object buf)
@@ -959,11 +993,16 @@ Lisp_Object
 get_minibuffer (EMACS_INT depth)
 {
   Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  Lisp_Object cll_tail = Fnthcdr (make_fixnum (depth),
+				  Vcommand_loop_level_list);
   if (NILP (tail))
     {
       tail = list1 (Qnil);
       Vminibuffer_list = nconc2 (Vminibuffer_list, tail);
+      cll_tail = list1 (Qnil);
+      Vcommand_loop_level_list = nconc2 (Vcommand_loop_level_list, cll_tail);
     }
+  XSETCAR (cll_tail, make_fixnum (depth ? command_loop_level : 0));
   Lisp_Object buf = Fcar (tail);
   if (NILP (buf) || !BUFFER_LIVE_P (XBUFFER (buf)))
     {
@@ -991,6 +1030,14 @@ get_minibuffer (EMACS_INT depth)
   return buf;
 }
 
+EMACS_INT minibuf_c_loop_level (EMACS_INT depth)
+{
+  Lisp_Object cll = Fnth (make_fixnum (depth), Vcommand_loop_level_list);
+  if (FIXNUMP (cll))
+    return XFIXNUM (cll);
+  return 0;
+}
+
 static void
 run_exit_minibuf_hook (void)
 {
@@ -2137,6 +2184,7 @@ void
 init_minibuf_once (void)
 {
   staticpro (&Vminibuffer_list);
+  staticpro (&Vcommand_loop_level_list);
   pdumper_do_now_and_after_load (init_minibuf_once_for_pdumper);
 }
 
@@ -2150,6 +2198,7 @@ init_minibuf_once_for_pdumper (void)
      restore from a dump file.  pdumper doesn't try to preserve
      frames, windows, and so on, so reset everything related here.  */
   Vminibuffer_list = Qnil;
+  Vcommand_loop_level_list = Qnil;
   minibuf_level = 0;
   minibuf_prompt = Qnil;
   minibuf_save_list = Qnil;
@@ -2380,6 +2429,7 @@ instead. */);
 
   defsubr (&Sminibufferp);
   defsubr (&Sinnermost_minibuffer_p);
+  defsubr (&Sminibuffer_innermost_command_loop_p);
   defsubr (&Sabort_minibuffers);
   defsubr (&Sminibuffer_prompt_end);
   defsubr (&Sminibuffer_contents);
diff --git a/src/window.h b/src/window.h
index 79eb44e7a3..b6f88e8f55 100644
--- a/src/window.h
+++ b/src/window.h
@@ -1120,10 +1120,6 @@ void set_window_buffer (Lisp_Object window, Lisp_Object buffer,
 
 extern Lisp_Object echo_area_window;
 
-/* Depth in recursive edits.  */
-
-extern EMACS_INT command_loop_level;
-
 /* Non-zero if we should redraw the mode lines on the next redisplay.
    Usually set to a unique small integer so we can track the main causes of
    full redisplays in `redisplay--mode-lines-cause'.  */



-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

Thanks for your hard work.
Your patch fixes the mentioned problems, save for the following
regression, which isn't related to minibuffers: upon
entering two or more M-x recursive-edit, pressing C-]
(abort-recursive-edit) will take you to top-level rather than quit just
one recursive edit and produce an error "No catch for tag: exit, t".

> The handling you're proposing for exit-read-minibuffer is no less
> complicated than what's already there for exit.

Actually with function minibuf_c_loop_level, introduced in the patch,
you could probably do something similar to my proposed idea by adjusting
the catch for Qexit (in command_loop in src/keyboard.c) rather than
introducing a new catch for a new Qexit_read_minibuffer.

If you have the time and energy, you can read more about this below,
where I brainstorm two more ideas.

The way I see it, there is, in essence, one problem: we want to quit out
of multiple recursive-edit levels. And for this, there are three
solutions:

1) internal_catch shall detect if we are in a non-inner minibuffer and
   re-throw Qexit until necessary. This is the current solution.

   Pros:
   - The simplest solution and easiest to maintain
   Cons:
   - internal_catch special cases Qexit and is dependent on
     Fcurrent_buffer
   (Note that my experience in lisp programming is limited and my gut
   feeling that this "isn't clean" may be completely misplaced.)

2) command_loop (in src/keyboard.c) shall detect if we are in a
   non-inner minibuffer and re-throw Qexit until necessary. So
   basically, move the code from internal_catch to command_loop or
   recursive_edit_1.

   Cons:
   - A bit harder to implement and maintain

3) The catcher for Qexit in command_loop shall be generalized to accept
   an integer value N, which would mean to re-throw to Qexit with N-1
   (or quit if N<=1) and quit-minibuffers shall be adjusted to calculate
   how many minibuffers to quit with the help of your new
   minibuf_c_loop_level function.

   Cons:
   - The most complicated solution
   - The new (throw 'exit N) API will have to be documented and
     maintained
   - Will probably not be all that useful for users
   - In could even cause a lot more problems that its worth
   - Hard to deprecate (perhaps its use could be discouraged or the API
     considered not supported and only to be used by internal Emacs
     commands like quit-minibuffers)
   Pros:
   - does not rely on static variables
   - isolates multi-level quitting only to a single command
     (quit-minibuffers)
   - Users might get a new possibly useful API for quitting multiple
     levels

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello again, jakanakaevangeli.

On Sun, Feb 07, 2021 at 00:25:56 +0100, jakanakaevangeli wrote:
> Thanks for your hard work.

Just as a matter of interest, your email host rejected my post yesterday,
saying that the interchange had to start with a STARTTLS command.

> Your patch fixes the mentioned problems, save for the following
> regression, which isn't related to minibuffers: upon entering two or
> more M-x recursive-edit, pressing C-] (abort-recursive-edit) will take
> you to top-level rather than quit just one recursive edit and produce
> an error "No catch for tag: exit, t".

Yes.  That happens even on C-] when there's just a single recursive edit
in progress.

> > The handling you're proposing for exit-read-minibuffer is no less
> > complicated than what's already there for exit.

> Actually with function minibuf_c_loop_level, introduced in the patch,
> you could probably do something similar to my proposed idea by adjusting
> the catch for Qexit (in command_loop in src/keyboard.c) rather than
> introducing a new catch for a new Qexit_read_minibuffer.

> If you have the time and energy, you can read more about this below,
> where I brainstorm two more ideas.

> The way I see it, there is, in essence, one problem: we want to quit out
> of multiple recursive-edit levels. And for this, there are three
> solutions:

[ .... ]

It turns out the tools in place were adequate to fix the problem without
too much trouble.  The critical thing is in internal_catch to distinguish
between minibuffer throws and recursive edit throws, and only throw again
for the minibuffer case.

Additionally, minibuf_c_loop_level should now be made a static function,
but I can do that later.

Could I ask you please to try out the following patch, which should be
applied on top of yesterday's patch:




--- src/eval.c~	2021-02-06 12:44:35.798096526 +0000
+++ src/eval.c	2021-02-07 12:27:09.927308860 +0000
@@ -1199,9 +1199,10 @@
 	{
           if (minibuffer_quit_level == -1)
             minibuffer_quit_level = this_minibuffer_depth (Qnil);
-          if (minibuf_level > minibuffer_quit_level
-              || command_loop_level
-              > minibuf_c_loop_level (minibuffer_quit_level))
+          /* MINIBUFFER_QUIT_LEVEL == 0 -> not in minibuffer. */
+	  if (minibuffer_quit_level
+	      && minibuf_level > minibuffer_quit_level
+	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
             Fthrow (Qexit, Qt);
 	  else
 	    minibuffer_quit_level = -1;
--- src/minibuf.c~	2021-02-06 15:04:58.878632379 +0000
+++ src/minibuf.c	2021-02-07 12:02:54.913389037 +0000
@@ -437,6 +437,8 @@
 
   if (!minibuf_depth)
     error ("Not in a minibuffer");
+  if (NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
+    error ("Not in most nested command loop");
   if (minibuf_depth < minibuf_level)
     {
       array[0] = fmt;


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

> Just as a matter of interest, your email host rejected my post
> yesterday, saying that the interchange had to start with a STARTTLS
> command.

Thank you for reporting, I will try to get in touch with my email host.

> Could I ask you please to try out the following patch, which should be
> applied on top of yesterday's patch:

I tried it and everything works as expected, if we use C-g. The only
minor thing I noticed is with abort-recursive-edit (C-]). When executed
from a normal buffer, it does what its doc-string suggests. But when
executed from a non-innermost minibuffer, it exits multiple recursive
edits, just like abort-minibuffers. (This isn't surprising since it
calls Fthrow (Qexit, Qt) just like abort-minibuffers, only without
asking yes_or_no_p first.)

This might actually be intended behaviour, depending on how you
interpret "this minibuffer input" from abort-recursive-edit's
doc-string.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello jakanakaevangeli.

Thank you indeed for all the testing you are doing.  It is saving me a
lot of hassle in the future.

On Sun, Feb 07, 2021 at 17:44:17 +0100, jakanakaevangeli wrote:

[ .... ]

> > Could I ask you please to try out the following patch, which should be
> > applied on top of yesterday's patch:

> I tried it and everything works as expected, if we use C-g. The only
> minor thing I noticed is with abort-recursive-edit (C-]). When executed
> from a normal buffer, it does what its doc-string suggests. But when
> executed from a non-innermost minibuffer, it exits multiple recursive
> edits, just like abort-minibuffers. (This isn't surprising since it
> calls Fthrow (Qexit, Qt) just like abort-minibuffers, only without
> asking yes_or_no_p first.)

This is not good.

> This might actually be intended behaviour, depending on how you
> interpret "this minibuffer input" from abort-recursive-edit's
> doc-string.

I spent some time boring into the doc string and the description in the
Elisp manual.  The only conclusion I could come to was that C-] is meant
to abort EXACTLY ONE level.

So I have tweaked the C sources once more and come up with the following
patch.  It should apply to the Emacs state after yesterday's patch.
Please remove the patch from earlier today before you try to apply the
new patch.  Thanks!



--- src/eval.c~	2021-02-06 12:44:35.798096526 +0000
+++ src/eval.c	2021-02-07 20:07:13.793787769 +0000
@@ -1163,16 +1163,17 @@
    FUNC should return a Lisp_Object.
    This is how catches are done from within C code.  */
 
+/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
+   throwing t to tag `exit'.
+   Value -1 means there is no (throw 'exit t) in progress;
+   0 means the `throw' wasn't done from an active minibuffer;
+   N > 0 means the `throw' was done from the minibuffer at level N.  */
+EMACS_INT minibuffer_quit_level = -1;
+
 Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
 {
-  /* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
-     throwing t to tag `exit'.
-     Value -1 means there is no (throw 'exit t) in progress;
-     0 means the `throw' wasn't done from an active minibuffer;
-     N > 0 means the `throw' was done from the minibuffer at level N.  */
-  static EMACS_INT minibuffer_quit_level = -1;
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c = push_handler (tag, CATCHER);
 
@@ -1192,16 +1193,14 @@
       Lisp_Object val = handlerlist->val;
       clobbered_eassert (handlerlist == c);
       handlerlist = handlerlist->next;
-      if (EQ (tag, Qexit) && EQ (val, Qt))
+      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
 	/* If we've thrown t to tag `exit' from within a minibuffer, we
 	   exit all minibuffers more deeply nested than the current
 	   one.  */
 	{
-          if (minibuffer_quit_level == -1)
-            minibuffer_quit_level = this_minibuffer_depth (Qnil);
-          if (minibuf_level > minibuffer_quit_level
-              || command_loop_level
-              > minibuf_c_loop_level (minibuffer_quit_level))
+          /* MINIBUFFER_QUIT_LEVEL == 0 -> not in minibuffer. */
+	  if (minibuf_level > minibuffer_quit_level
+	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
             Fthrow (Qexit, Qt);
 	  else
 	    minibuffer_quit_level = -1;
--- src/minibuf.c~	2021-02-06 15:04:58.878632379 +0000
+++ src/minibuf.c	2021-02-07 20:06:34.249789948 +0000
@@ -437,12 +437,17 @@
 
   if (!minibuf_depth)
     error ("Not in a minibuffer");
+  if (NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
+    error ("Not in most nested command loop");
   if (minibuf_depth < minibuf_level)
     {
       array[0] = fmt;
       array[1] = make_fixnum (minibuf_level - minibuf_depth + 1);
       if (!NILP (Fyes_or_no_p (Fformat (2, array))))
-	Fthrow (Qexit, Qt);
+	{
+	  minibuffer_quit_level = minibuf_depth;
+	  Fthrow (Qexit, Qt);
+	}
     }
   else
     Fthrow (Qexit, Qt);
--- src/lisp.h~	2021-02-06 12:45:15.205094355 +0000
+++ src/lisp.h	2021-02-07 20:07:45.816786005 +0000
@@ -4090,6 +4090,7 @@
 }
 
 /* Defined in eval.c.  */
+extern EMACS_INT minibuffer_quit_level;
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vrun_hooks;
 extern Lisp_Object Vsignaling_function;


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

Alan Mackenzie <acm@muc.de> writes:

> Hello jakanakaevangeli.

Hello

> I spent some time boring into the doc string and the description in the
> Elisp manual.  The only conclusion I could come to was that C-] is meant
> to abort EXACTLY ONE level.
>
> So I have tweaked the C sources once more and come up with the following
> patch.  It should apply to the Emacs state after yesterday's patch.
> Please remove the patch from earlier today before you try to apply the
> new patch.  Thanks!

During testing, I didn't encounter any problems related to your latest
patch so you hard work paid off.

Sadly, I did encounter 2 additional minibuffer issues which aren't
related to your latest two patches, that is, they are present regardless
if these patches are applied or not. I'm posting them here since they
are still possibly related to the new minibuffer frame-following
functionality.

1) With minibuffer-follows-selected-frame set to t (the default value):
- press M-x on frame A
- select frame B (the minibuffer will move to this frame)
- C-x o, to select the minibuffer
- C-g to quit it
Miniwindow stays selected and its buffer is *Minibuf-1* instead of
*Minibuf-0*. You can check this by evaluating (minibuffer-window).

2) With minibuffer-follows-selected-frame set to nil:
- (setq set enable-recursive-minibuffers t)
- (minibuffer-depth-indicate-mode 1)
- select frame A and press M-x
- select frame B and press M-x
- select frame A and close it
- select frame B and quit its minibuffer with C-g.
This doesn't quit the outer minibuffer, as expected, but this minibuffer
isn't shown anywhere and the only reasonable way to quit it is with C-],
which, I believe, a lot of users don't know about (at least I personally
didn't until quite recently). You can check this with
(minibuffer-depth).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, jakanakaevangeli.

On Mon, Feb 08, 2021 at 13:53:43 +0100, jakanakaevangeli wrote:
> Alan Mackenzie <acm@muc.de> writes:

> Hello

> > I spent some time boring into the doc string and the description in the
> > Elisp manual.  The only conclusion I could come to was that C-] is meant
> > to abort EXACTLY ONE level.

> > So I have tweaked the C sources once more and come up with the following
> > patch.  It should apply to the Emacs state after yesterday's patch.
> > Please remove the patch from earlier today before you try to apply the
> > new patch.  Thanks!

> During testing, I didn't encounter any problems related to your latest
> patch so you hard work paid off.

> Sadly, I did encounter 2 additional minibuffer issues which aren't
> related to your latest two patches, that is, they are present regardless
> if these patches are applied or not. I'm posting them here since they
> are still possibly related to the new minibuffer frame-following
> functionality.

Thanks!

> 1) With minibuffer-follows-selected-frame set to t (the default value):
> - press M-x on frame A
> - select frame B (the minibuffer will move to this frame)
> - C-x o, to select the minibuffer
> - C-g to quit it
> Miniwindow stays selected and its buffer is *Minibuf-1* instead of
> *Minibuf-0*. You can check this by evaluating (minibuffer-window).

This one was somewhat tricky to resolve, my fixes uncovering several
other inconsistencies in the minibuffer handling, which I hope I have
now fixed.

> 2) With minibuffer-follows-selected-frame set to nil:
> - (setq set enable-recursive-minibuffers t)
> - (minibuffer-depth-indicate-mode 1)
> - select frame A and press M-x
> - select frame B and press M-x
> - select frame A and close it
> - select frame B and quit its minibuffer with C-g.
> This doesn't quit the outer minibuffer, as expected, but this minibuffer
> isn't shown anywhere and the only reasonable way to quit it is with C-],
> which, I believe, a lot of users don't know about (at least I personally
> didn't until quite recently). You can check this with
> (minibuffer-depth).

This is more involved.  What do we want to happen when a frame with open
minibuffers is deleted?  I would say that these minibuffers should,
except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
together with any others in other frames whose nesting level makes this
necessary.  Then there're complications with recursive edits.  But I
haven't looked at implementing this, yet.  Alternatively, maybe open
minibuffers should be moved to the "previous" frame.  Perhaps I should
open another thread on emacs-devel for this problem.

Anyhow, I have a patch for bug 1.  It is a full diff from master, rather
than a difference from "yesterday".  I would be very grateful indeed if
you could try it out, and let me know again how well it's working.  I
would really like to commit this to master.  Thanks again!



diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index a899a943d4..aacb8ab00b 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2116,18 +2116,19 @@ minibuffer-hide-completions
 (defun exit-minibuffer ()
   "Terminate this minibuffer argument."
   (interactive)
-  (when (or
-         (innermost-minibuffer-p)
-         (not (minibufferp)))
+  (when (minibufferp)
+    (when (not (minibuffer-innermost-command-loop-p))
+      (error "%s" "Not in most nested command loop"))
+    (when (not (innermost-minibuffer-p))
+      (error "%s" "Not in most nested minibuffer")))
   ;; If the command that uses this has made modifications in the minibuffer,
   ;; we don't want them to cause deactivation of the mark in the original
   ;; buffer.
   ;; A better solution would be to make deactivate-mark buffer-local
   ;; (or to turn it into a list of buffers, ...), but in the mean time,
   ;; this should do the trick in most cases.
-    (setq deactivate-mark nil)
-    (throw 'exit nil))
-  (error "%s" "Not in most nested minibuffer"))
+  (setq deactivate-mark nil)
+  (throw 'exit nil))
 
 (defun self-insert-and-exit ()
   "Terminate minibuffer input."
diff --git a/src/eval.c b/src/eval.c
index 3aff3b56d5..91fc4e6837 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1165,21 +1165,23 @@ usage: (catch TAG BODY...)  */)
    FUNC should return a Lisp_Object.
    This is how catches are done from within C code.  */
 
+/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
+   throwing t to tag `exit'.
+   0 means there is no (throw 'exit t) in progress, or it wasn't from
+     a minibuffer which isn't the most nested;
+   N > 0 means the `throw' was done from the minibuffer at level N which
+     wasn't the most nested.  */
+EMACS_INT minibuffer_quit_level = 0;
+
 Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
 {
-  /* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
-     throwing t to tag `exit'.
-     Value -1 means there is no (throw 'exit t) in progress;
-     0 means the `throw' wasn't done from an active minibuffer;
-     N > 0 means the `throw' was done from the minibuffer at level N.  */
-  static EMACS_INT minibuffer_quit_level = -1;
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c = push_handler (tag, CATCHER);
 
   if (EQ (tag, Qexit))
-    minibuffer_quit_level = -1;
+    minibuffer_quit_level = 0;
 
   /* Call FUNC.  */
   if (! sys_setjmp (c->jmp))
@@ -1194,22 +1196,16 @@ internal_catch (Lisp_Object tag,
       Lisp_Object val = handlerlist->val;
       clobbered_eassert (handlerlist == c);
       handlerlist = handlerlist->next;
-      if (EQ (tag, Qexit) && EQ (val, Qt))
+      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
 	/* If we've thrown t to tag `exit' from within a minibuffer, we
 	   exit all minibuffers more deeply nested than the current
 	   one.  */
 	{
-	  EMACS_INT mini_depth = this_minibuffer_depth (Qnil);
-	  if (mini_depth && mini_depth != minibuffer_quit_level)
-	    {
-	      if (minibuffer_quit_level == -1)
-		minibuffer_quit_level = mini_depth;
-	      if (minibuffer_quit_level
-		  && (minibuf_level > minibuffer_quit_level))
-		Fthrow (Qexit, Qt);
-	    }
+	  if (minibuf_level > minibuffer_quit_level
+	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
+            Fthrow (Qexit, Qt);
 	  else
-	    minibuffer_quit_level = -1;
+	    minibuffer_quit_level = 0;
 	}
       return val;
     }
diff --git a/src/lisp.h b/src/lisp.h
index 409a1e7060..0847324d1f 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4091,6 +4091,7 @@ intern_c_string (const char *str)
 }
 
 /* Defined in eval.c.  */
+extern EMACS_INT minibuffer_quit_level;
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vrun_hooks;
 extern Lisp_Object Vsignaling_function;
@@ -4369,6 +4370,7 @@ extern void syms_of_casetab (void);
 
 /* Defined in keyboard.c.  */
 
+extern EMACS_INT command_loop_level;
 extern Lisp_Object echo_message_buffer;
 extern struct kboard *echo_kboard;
 extern void cancel_echoing (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index 949c3d989d..4b1f4b1ff7 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -41,6 +41,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
    minibuffer recursions are encountered.  */
 
 Lisp_Object Vminibuffer_list;
+Lisp_Object Vcommand_loop_level_list;
 
 /* Data to remember during recursive minibuffer invocations.  */
 
@@ -64,6 +65,8 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 static Lisp_Object nth_minibuffer (EMACS_INT depth);
+static EMACS_INT minibuf_c_loop_level (EMACS_INT depth);
+static void set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth);
 
 \f
 /* Return TRUE when a frame switch causes a minibuffer on the old
@@ -181,7 +184,12 @@ void move_minibuffer_onto_frame (void)
 	set_window_buffer (sf->minibuffer_window, nth_minibuffer (i), 0, 0);
       minibuf_window = sf->minibuffer_window;
       if (of != sf)
-	set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+	{
+	  Lisp_Object temp = get_minibuffer (0);
+
+	  set_window_buffer (of->minibuffer_window, temp, 0, 0);
+	  set_minibuffer_mode (temp, 0);
+	}
     }
 }
 
@@ -389,6 +397,21 @@ No argument or nil as argument means use the current buffer as BUFFER.  */)
     : Qnil;
 }
 
+DEFUN ("minibuffer-innermost-command-loop-p", Fminibuffer_innermost_command_loop_p,
+       Sminibuffer_innermost_command_loop_p, 0, 1, 0,
+       doc: /* Return t if BUFFER is a minibuffer at the current command loop level.
+No argument or nil as argument means use the current buffer as BUFFER.  */)
+  (Lisp_Object buffer)
+{
+  EMACS_INT depth;
+  if (NILP (buffer))
+    buffer = Fcurrent_buffer ();
+  depth = this_minibuffer_depth (buffer);
+  return depth && minibuf_c_loop_level (depth) == command_loop_level
+    ? Qt
+    : Qnil;
+}
+
 /* Return the nesting depth of the active minibuffer BUFFER, or 0 if
    BUFFER isn't such a thing.  If BUFFER is nil, this means use the current
    buffer.  */
@@ -420,12 +443,17 @@ confirm the aborting of the current minibuffer and all contained ones.  */)
 
   if (!minibuf_depth)
     error ("Not in a minibuffer");
+  if (NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
+    error ("Not in most nested command loop");
   if (minibuf_depth < minibuf_level)
     {
       array[0] = fmt;
       array[1] = make_fixnum (minibuf_level - minibuf_depth + 1);
       if (!NILP (Fyes_or_no_p (Fformat (2, array))))
-	Fthrow (Qexit, Qt);
+	{
+	  minibuffer_quit_level = minibuf_depth;
+	  Fthrow (Qexit, Qt);
+	}
     }
   else
     Fthrow (Qexit, Qt);
@@ -508,6 +536,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
   Lisp_Object calling_frame = selected_frame;
+  Lisp_Object calling_window = selected_window;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -598,7 +627,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 
   if (minibuf_level > 1
       && minibuf_moves_frame_when_opened ()
-      && !minibuf_follows_frame ())
+      && (!minibuf_follows_frame ()
+	  || (!EQ (mini_frame, selected_frame))))
     {
       EMACS_INT i;
 
@@ -607,8 +637,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 	set_window_buffer (minibuf_window, nth_minibuffer (i), 0, 0);
     }
 
-  record_unwind_protect_void (choose_minibuf_frame);
-
   record_unwind_protect (restore_window_configuration,
                          Fcons (Qt, Fcurrent_window_configuration (Qnil)));
 
@@ -640,7 +668,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+		    Fcons (calling_frame,
+			   Fcons (calling_window,
+				  minibuf_save_list))));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -694,6 +724,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Switch to the minibuffer.  */
 
   minibuffer = get_minibuffer (minibuf_level);
+  set_minibuffer_mode (minibuffer, minibuf_level);
   Fset_buffer (minibuffer);
 
   /* Defeat (setq-default truncate-lines t), since truncated lines do
@@ -738,6 +769,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
      where there is an active minibuffer.
      Set them to point to ` *Minibuf-0*', which is always empty.  */
   empty_minibuf = get_minibuffer (0);
+  set_minibuffer_mode (empty_minibuf, 0);
 
   FOR_EACH_FRAME (dummy, frame)
     {
@@ -837,20 +869,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 
   recursive_edit_1 ();
 
-  /* We've exited the recursive edit without an error, so switch the
-     current window away from the expired minibuffer window.  */
-  {
-    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
-    /* PREV can be on a different frame when we have a minibuffer only
-       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
-       and its "focus window" is also MINIBUF_WINDOW.  */
-    while (!EQ (prev, minibuf_window)
-	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
-      prev = Fprevious_window (prev, Qnil, Qnil);
-    if (!EQ (prev, minibuf_window))
-      Fset_frame_selected_window (selected_frame, prev, Qnil);
-  }
-
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -959,11 +977,16 @@ Lisp_Object
 get_minibuffer (EMACS_INT depth)
 {
   Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  Lisp_Object cll_tail = Fnthcdr (make_fixnum (depth),
+				  Vcommand_loop_level_list);
   if (NILP (tail))
     {
       tail = list1 (Qnil);
       Vminibuffer_list = nconc2 (Vminibuffer_list, tail);
+      cll_tail = list1 (Qnil);
+      Vcommand_loop_level_list = nconc2 (Vcommand_loop_level_list, cll_tail);
     }
+  XSETCAR (cll_tail, make_fixnum (depth ? command_loop_level : 0));
   Lisp_Object buf = Fcar (tail);
   if (NILP (buf) || !BUFFER_LIVE_P (XBUFFER (buf)))
     {
@@ -973,7 +996,6 @@ get_minibuffer (EMACS_INT depth)
       buf = Fget_buffer_create (lname, Qnil);
       /* Do this before set_minibuffer_mode.  */
       XSETCAR (tail, buf);
-      set_minibuffer_mode (buf, depth);
       /* Although the buffer's name starts with a space, undo should be
 	 enabled in it.  */
       Fbuffer_enable_undo (buf);
@@ -985,12 +1007,19 @@ get_minibuffer (EMACS_INT depth)
 	 while the buffer doesn't know about them any more.  */
       delete_all_overlays (XBUFFER (buf));
       reset_buffer (XBUFFER (buf));
-      set_minibuffer_mode (buf, depth);
     }
 
   return buf;
 }
 
+static EMACS_INT minibuf_c_loop_level (EMACS_INT depth)
+{
+  Lisp_Object cll = Fnth (make_fixnum (depth), Vcommand_loop_level_list);
+  if (FIXNUMP (cll))
+    return XFIXNUM (cll);
+  return 0;
+}
+
 static void
 run_exit_minibuf_hook (void)
 {
@@ -1004,17 +1033,16 @@ static void
 read_minibuf_unwind (void)
 {
   Lisp_Object old_deactivate_mark;
-  Lisp_Object window;
+  Lisp_Object calling_frame;
+  Lisp_Object calling_window;
   Lisp_Object future_mini_window;
 
-  /* If this was a recursive minibuffer,
-     tie the minibuffer window back to the outer level minibuffer buffer.  */
-  minibuf_level--;
-
-  window = minibuf_window;
   /* To keep things predictable, in case it matters, let's be in the
-     minibuffer when we reset the relevant variables.  */
-  Fset_buffer (XWINDOW (window)->contents);
+     minibuffer when we reset the relevant variables.  Don't depend on
+     `minibuf_window' here.  This could by now be the mini-window of any
+     frame.  */
+  Fset_buffer (nth_minibuffer (minibuf_level));
+  minibuf_level--;
 
   /* Restore prompt, etc, from outer minibuffer level.  */
   Lisp_Object key_vec = Fcar (minibuf_save_list);
@@ -1042,6 +1070,10 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  calling_frame = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
+  calling_window = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -1059,7 +1091,7 @@ read_minibuf_unwind (void)
      mini-window back to its normal size.  */
   if (minibuf_level == 0
       || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
-    resize_mini_window (XWINDOW (window), 0);
+    resize_mini_window (XWINDOW (minibuf_window), 0);
 
   /* Deal with frames that should be removed when exiting the
      minibuffer.  */
@@ -1090,6 +1122,24 @@ read_minibuf_unwind (void)
      to make sure we don't leave around bindings and stuff which only
      made sense during the read_minibuf invocation.  */
   call0 (intern ("minibuffer-inactive-mode"));
+
+  /* We've exited the recursive edit, so switch the current windows
+     away from the expired minibuffer window, both in the current
+     minibuffer's frame and the original calling frame.  */
+  choose_minibuf_frame ();
+  if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    if (!EQ (prev, minibuf_window)
+	&& EQ (WINDOW_FRAME (XWINDOW (prev)),
+	       WINDOW_FRAME (XWINDOW (minibuf_window))))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+  else
+    Fset_frame_selected_window (calling_frame, calling_window, Qnil);
 }
 \f
 
@@ -2137,6 +2187,7 @@ void
 init_minibuf_once (void)
 {
   staticpro (&Vminibuffer_list);
+  staticpro (&Vcommand_loop_level_list);
   pdumper_do_now_and_after_load (init_minibuf_once_for_pdumper);
 }
 
@@ -2150,6 +2201,7 @@ init_minibuf_once_for_pdumper (void)
      restore from a dump file.  pdumper doesn't try to preserve
      frames, windows, and so on, so reset everything related here.  */
   Vminibuffer_list = Qnil;
+  Vcommand_loop_level_list = Qnil;
   minibuf_level = 0;
   minibuf_prompt = Qnil;
   minibuf_save_list = Qnil;
@@ -2380,6 +2432,7 @@ instead. */);
 
   defsubr (&Sminibufferp);
   defsubr (&Sinnermost_minibuffer_p);
+  defsubr (&Sminibuffer_innermost_command_loop_p);
   defsubr (&Sabort_minibuffers);
   defsubr (&Sminibuffer_prompt_end);
   defsubr (&Sminibuffer_contents);
diff --git a/src/window.h b/src/window.h
index 79eb44e7a3..b6f88e8f55 100644
--- a/src/window.h
+++ b/src/window.h
@@ -1120,10 +1120,6 @@ void set_window_buffer (Lisp_Object window, Lisp_Object buffer,
 
 extern Lisp_Object echo_area_window;
 
-/* Depth in recursive edits.  */
-
-extern EMACS_INT command_loop_level;
-
 /* Non-zero if we should redraw the mode lines on the next redisplay.
    Usually set to a unique small integer so we can track the main causes of
    full redisplays in `redisplay--mode-lines-cause'.  */



-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> This is more involved.  What do we want to happen when a frame with open
> minibuffers is deleted?  I would say that these minibuffers should,
> except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
> together with any others in other frames whose nesting level makes this
> necessary.

I vote for moving those minibuffers elsewhere (anywhere else is fine by
me, really).  I assume it's no more complicated code-wise, and it should
suffer less from the risk of losing information.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

Thanks for still reading this old thread!

On Thu, Feb 11, 2021 at 09:29:44 -0500, Stefan Monnier wrote:
> > This is more involved.  What do we want to happen when a frame with open
> > minibuffers is deleted?  I would say that these minibuffers should,
> > except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
> > together with any others in other frames whose nesting level makes this
> > necessary.

> I vote for moving those minibuffers elsewhere (anywhere else is fine by
> me, really).  I assume it's no more complicated code-wise, and it should
> suffer less from the risk of losing information.

Thinking about it, you are right.  Deleting frames doesn't abort any
other buffers, so why should minibuffers suffer?  The code is going to
be tedious and moderately difficult to write either way.  So I think on
deleting a frame, any minibuffers in it should get pushed onto the
previous frame.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan and jakanakaevangeli.

On Thu, Feb 11, 2021 at 09:29:44 -0500, Stefan Monnier wrote:
> > This is more involved.  What do we want to happen when a frame with open
> > minibuffers is deleted?  I would say that these minibuffers should,
> > except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
> > together with any others in other frames whose nesting level makes this
> > necessary.

> I vote for moving those minibuffers elsewhere (anywhere else is fine by
> me, really).  I assume it's no more complicated code-wise, and it should
> suffer less from the risk of losing information.

Just a quick recapitulation of the problem: when
minibuffer-follows-selected-frame is nil, and
enable-recursive-minibuffers t, it is possible to have several open
minibuffers on several frames.  If one of these frames is deleted, its
minibuffers continue to exist, but are wholly inaccessible - the only
thing to do with them is to abort them, e.g. with C-].  This is
suboptimal.

The patch below tries to solve this by, when such a frame gets deleted,
"zipping" its minibuffers into those of another frame.  The idea behind
the patch is to use the mini-window's w->prev_buffers component to hold
the list of its minibuffers.  This mini-window component was unused by
the rest of Emacs, apart from accidentally by
window--before-delete-windows, which I have now amended.

I would be grateful indeed if either of you (or indeed, anybody else),
would apply the patch and try it out, or indeed comment on it.  Thanks!



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index f81e64bdf9..7da0a48b7c 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -82,7 +82,9 @@ Basic Minibuffer
 (@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
 (approximately) the behavior prior to Emacs 28.1.  Note that the
 effect of the command, when you finally finish using the minibuffer,
-always takes place in the frame where you first opened it.
+always takes place in the frame where you first opened it.  The sole
+exception is that when that frame no longer exists, the action takes
+place in the currently selected frame.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/lisp/window.el b/lisp/window.el
index cfd9876ed0..fb2ea4a985 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4158,7 +4158,7 @@ window--before-delete-windows
 
 This function is called only if `switch-to-buffer-preserve-window-point'
 evaluates non-nil."
-  (dolist (win (window-list))
+  (dolist (win (window-list nil 'no-minibuf))
     (let* ((buf   (window-buffer (or window win)))
            (start (window-start win))
            (pos   (window-point win))
@@ -4416,7 +4416,8 @@ record-window-buffer
        window (assq-delete-all buffer (window-prev-buffers window))))
 
     ;; Don't record insignificant buffers.
-    (unless (eq (aref (buffer-name buffer) 0) ?\s)
+    (when (or (not (eq (aref (buffer-name buffer) 0) ?\s))
+              (string-match "^ \\*Minibuf" (buffer-name buffer)))
       ;; Add an entry for buffer to WINDOW's previous buffers.
       (with-current-buffer buffer
 	(let ((start (window-start window))
diff --git a/src/frame.c b/src/frame.c
index a62347c1fb..b9df5739dd 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1487,7 +1487,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
-  move_minibuffer_onto_frame ();
+  move_minibuffers_onto_frame (sf, for_deletion);
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index b95f389b89..2f4e6377cb 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4348,7 +4348,7 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
-extern void move_minibuffer_onto_frame (void);
+extern void move_minibuffers_onto_frame (struct frame *, int);
 extern bool is_minibuffer (EMACS_INT, Lisp_Object);
 extern EMACS_INT this_minibuffer_depth (Lisp_Object);
 extern EMACS_INT minibuf_level;
diff --git a/src/minibuf.c b/src/minibuf.c
index 4b1f4b1ff7..53ed8d5ef8 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -67,6 +67,7 @@ static ptrdiff_t minibuf_prompt_width;
 static Lisp_Object nth_minibuffer (EMACS_INT depth);
 static EMACS_INT minibuf_c_loop_level (EMACS_INT depth);
 static void set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth);
+static bool live_minibuffer_p (Lisp_Object);
 
 \f
 /* Return TRUE when a frame switch causes a minibuffer on the old
@@ -78,6 +79,7 @@ minibuf_follows_frame (void)
              Qt);
 }
 
+#if 0
 /* Return TRUE when a minibuffer always remains on the frame where it
    was first invoked. */
 static bool
@@ -85,6 +87,7 @@ minibuf_stays_put (void)
 {
   return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
+#endif
 
 /* Return TRUE when opening a (recursive) minibuffer causes
    minibuffers on other frames to move to the selected frame.  */
@@ -112,83 +115,137 @@ choose_minibuf_frame (void)
 	emacs_abort ();
 
       minibuf_window = sf->minibuffer_window;
-      /* If we've still got another minibuffer open, use its mini-window
-         instead.  */
-      if (minibuf_level > 1 && minibuf_stays_put ())
-        {
-          Lisp_Object buffer = get_minibuffer (minibuf_level);
-          Lisp_Object tail, frame;
-
-          FOR_EACH_FRAME (tail, frame)
-            if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
-                    buffer))
-              {
-                minibuf_window = XFRAME (frame)->minibuffer_window;
-                break;
-              }
-        }
     }
+}
 
-  if (minibuf_moves_frame_when_opened ()
-      && FRAMEP (selected_frame)
-      && FRAME_LIVE_P (XFRAME (selected_frame)))
-    /* Make sure no other frame has a minibuffer as its selected window,
-       because the text would not be displayed in it, and that would be
-       confusing.  Only allow the selected frame to do this,
-       and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
-    struct frame *of;
-
-    FOR_EACH_FRAME (tail, frame)
-      if (!EQ (frame, selected_frame)
-          && minibuf_level > 1
-	  /* The frame's minibuffer can be on a different frame.  */
-	  && ! EQ (XWINDOW ((of = XFRAME (frame))->minibuffer_window)->frame,
-		   selected_frame))
-        {
-          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
-            Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                        Qnil);
-
-          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
-                   nth_minibuffer (0)))
-            set_window_buffer (of->minibuffer_window,
-                               nth_minibuffer (0), 0, 0);
-        }
-  }
+/* Get the next live buffer entry from a w->prev_buffer, setting the pertinent
+  variables of `zip_minibuffer_stacks'.  The parameter P is either "d" for
+  the destination structures, or "s" for the source structures.  When the
+  ->prev_buffers list is exhausted, set di/si to -1.  */
+#define NEXT_BUFFER_ENTRY(p)						\
+  do									\
+    {									\
+      if (NILP (p##_bufs))						\
+        {								\
+	  p##b = Qnil;							\
+	  p##_ent = Qnil;						\
+	}								\
+      else								\
+	{								\
+	  p##_ent = Fcar (p##_bufs);					\
+	  p##b = Fcar (p##_ent);					\
+	  p##_bufs = Fcdr (p##_bufs);					\
+	}								\
+      if (!NILP (p##b))							\
+	p##i = this_minibuffer_depth (p##b);				\
+      else								\
+	p##i = -1;							\
+    } while (p##i == 0)
+
+/* Move the ordered "stack" of minibuffers from SOURCE_WINDOW to
+   DEST_WINDOW, interleaving those minibuffers with any in DEST_WINDOW
+   to produce an ordered combination.  The ordering is by minibuffer
+   depth.  A stack of minibuffers consists of the minibuffer currently
+   in DEST/SOURCE_WINDOW together with any recorded in the
+   ->prev_buffers field of the struct window.  */
+static void
+zip_minibuffer_stacks (Lisp_Object dest_window, Lisp_Object source_window)
+{
+  struct window *dw = XWINDOW (dest_window);
+  struct window *sw = XWINDOW (source_window);
+  Lisp_Object d_bufs, s_bufs;	/* Lists of minibuffer entries */
+  Lisp_Object acc = Qnil;
+  Lisp_Object d_ent, s_ent;	/* Entries from dw/sw->prev_buffers */
+  Lisp_Object db, sb;		/* (Mini)buffers from the above */
+  EMACS_INT di, si;  /* Indices in the minibuffer list of db and sb */
+
+  if (!live_minibuffer_p (dw->contents)
+      && NILP (dw->prev_buffers))
+    {
+      set_window_buffer (dest_window, sw->contents, 0, 0);
+      Fset_window_start (dest_window, Fwindow_start (source_window), Qnil);
+      Fset_window_point (dest_window, Fwindow_point (source_window));
+      dw->prev_buffers = sw->prev_buffers;
+      set_window_buffer (source_window, get_minibuffer (0), 0, 0);
+      sw->prev_buffers = Qnil;
+      return;
+    }
+
+  if (live_minibuffer_p (dw->contents))
+    call1 (Qrecord_window_buffer, dest_window);
+  if (live_minibuffer_p (sw->contents))
+    call1 (Qrecord_window_buffer, source_window);
+
+  d_bufs = Fnreverse (dw->prev_buffers);
+  s_bufs = Fnreverse (sw->prev_buffers);
+
+  NEXT_BUFFER_ENTRY (d);
+  NEXT_BUFFER_ENTRY (s);
+
+  while (di != -1 && si != -1)
+    if (di < si)
+      {
+	acc = Fcons (d_ent, acc);
+	NEXT_BUFFER_ENTRY (d);
+      }
+    else
+      {
+	acc = Fcons (s_ent, acc);
+	NEXT_BUFFER_ENTRY (s);
+      }
+  while (di != -1)
+    {
+      acc = Fcons (d_ent, acc);
+      NEXT_BUFFER_ENTRY (d);
+    }
+  while (si != -1)
+    {
+      acc = Fcons (s_ent, acc);
+      NEXT_BUFFER_ENTRY (s);
+    }
+  if (!NILP (acc))
+    {
+      d_ent = Fcar (acc);
+      acc = Fcdr (acc);
+      set_window_buffer (dest_window, Fcar (d_ent), 0, 0);
+      Fset_window_start (dest_window, Fcar (Fcdr (d_ent)), Qnil);
+      Fset_window_point (dest_window, Fcar (Fcdr (Fcdr (d_ent))));
+    }
+  dw->prev_buffers = acc;
+  sw->prev_buffers = Qnil;
+  set_window_buffer (source_window, get_minibuffer (0), 0, 0);
 }
+#undef NEXT_BUFFER_ENTRY
 
-/* If `minibuffer_follows_selected_frame' is t and we have a
-   minibuffer, move it from its current frame to the selected frame.
-   This function is intended to be called from `do_switch_frame' in
-   frame.c.  */
-void move_minibuffer_onto_frame (void)
+/* If `minibuffer_follows_selected_frame' is t, or we're about to
+   delete a frame which potentially "contains" minibuffers, move them
+   from the old frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  OF is the
+   old frame, FOR_DELETION is self explanatory.  */
+void
+move_minibuffers_onto_frame (struct frame *of, int for_deletion)
 {
-  if (!minibuf_level)
-    return;
-  if (!minibuf_follows_frame ())
+  if (!for_deletion && (!minibuf_level || !minibuf_follows_frame ()))
     return;
   if (FRAMEP (selected_frame)
       && FRAME_LIVE_P (XFRAME (selected_frame))
-      && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+      && (for_deletion
+	  || !EQ (minibuf_window,
+		  XFRAME (selected_frame)->minibuffer_window)))
     {
-      EMACS_INT i;
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
-      struct frame *of = XFRAME (old_frame);
-
-      /* Stack up all the (recursively) open minibuffers on the selected
-         mini_window.  */
-      for (i = 1; i <= minibuf_level; i++)
-	set_window_buffer (sf->minibuffer_window, nth_minibuffer (i), 0, 0);
-      minibuf_window = sf->minibuffer_window;
-      if (of != sf)
+      Lisp_Object mini_frame = XWINDOW (minibuf_window)->frame;
+      struct frame *mf = XFRAME (mini_frame);
+      if (minibuf_follows_frame () || for_deletion)
+	zip_minibuffer_stacks (sf->minibuffer_window,
+			       of->minibuffer_window);
+      if (minibuf_window != sf->minibuffer_window)
 	{
 	  Lisp_Object temp = get_minibuffer (0);
 
-	  set_window_buffer (of->minibuffer_window, temp, 0, 0);
+	  set_window_buffer (mf->minibuffer_window, temp, 0, 0);
 	  set_minibuffer_mode (temp, 0);
+	  minibuf_window = sf->minibuffer_window;
 	}
     }
 }
@@ -221,6 +278,7 @@ without invoking the usual minibuffer commands.  */)
 /* Actual minibuffer invocation.  */
 
 static void read_minibuf_unwind (void);
+static void minibuffer_unwind (void);
 static void run_exit_minibuf_hook (void);
 
 
@@ -544,7 +602,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histval;
 
   Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
+  Lisp_Object old_minibuf_window = minibuf_window;
 
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
@@ -626,17 +684,23 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
 
   if (minibuf_level > 1
+      && (!EQ (minibuf_window, old_minibuf_window))
       && minibuf_moves_frame_when_opened ()
-      && (!minibuf_follows_frame ()
-	  || (!EQ (mini_frame, selected_frame))))
+      && (!minibuf_follows_frame ()))
     {
-      EMACS_INT i;
+      Lisp_Object old_frame = XWINDOW (old_minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
 
-      /* Stack up the existing minibuffers on the current mini-window */
-      for (i = 1; i < minibuf_level; i++)
-	set_window_buffer (minibuf_window, nth_minibuffer (i), 0, 0);
+      zip_minibuffer_stacks (minibuf_window, old_minibuf_window);
+      /* The frame's minibuffer can be on a different frame.  */
+      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+	Fset_frame_selected_window (old_frame,
+				    Fframe_first_window (old_frame), Qnil);
     }
+  if (live_minibuffer_p (XWINDOW (minibuf_window)->contents))
+    call1 (Qrecord_window_buffer, minibuf_window);
 
+  record_unwind_protect_void (minibuffer_unwind);
   record_unwind_protect (restore_window_configuration,
                          Fcons (Qt, Fcurrent_window_configuration (Qnil)));
 
@@ -771,23 +835,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   empty_minibuf = get_minibuffer (0);
   set_minibuffer_mode (empty_minibuf, 0);
 
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-      Lisp_Object buffer;
-
-      if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
-          && !NILP (Fwindow_minibuffer_p (mini_window)))
-        {
-          buffer = XWINDOW (mini_window)->contents;
-          if (!live_minibuffer_p (buffer))
-            /* Use set_window_buffer instead of Fset_window_buffer (see
-               discussion of bug#11984, bug#12025, bug#12026).  */
-            set_window_buffer (mini_window, empty_minibuf, 0, 0);
-        }
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -908,7 +955,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   unbind_to (count, Qnil);
 
   /* Switch the frame back to the calling frame.  */
-  if (!EQ (selected_frame, calling_frame)
+  if ((!EQ (selected_frame, calling_frame)
+       || !EQ (XWINDOW (XFRAME (calling_frame)->minibuffer_window)->frame,
+	       calling_frame))
       && FRAMEP (calling_frame)
       && FRAME_LIVE_P (XFRAME (calling_frame)))
     call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil);
@@ -1127,20 +1176,57 @@ read_minibuf_unwind (void)
      away from the expired minibuffer window, both in the current
      minibuffer's frame and the original calling frame.  */
   choose_minibuf_frame ();
-  if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
-  {
-    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
-    /* PREV can be on a different frame when we have a minibuffer only
-       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
-       and its "focus window" is also MINIBUF_WINDOW.  */
-    if (!EQ (prev, minibuf_window)
-	&& EQ (WINDOW_FRAME (XWINDOW (prev)),
-	       WINDOW_FRAME (XWINDOW (minibuf_window))))
-      Fset_frame_selected_window (selected_frame, prev, Qnil);
-  }
-  else
-    Fset_frame_selected_window (calling_frame, calling_window, Qnil);
+  if (NILP (XWINDOW (minibuf_window)->prev_buffers))
+    {
+      if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
+	{
+	  Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+	  /* PREV can be on a different frame when we have a minibuffer only
+	     frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+	     and its "focus window" is also MINIBUF_WINDOW.  */
+	  if (!EQ (prev, minibuf_window)
+	      && EQ (WINDOW_FRAME (XWINDOW (prev)),
+		     WINDOW_FRAME (XWINDOW (minibuf_window))))
+	    Fset_frame_selected_window (selected_frame, prev, Qnil);
+	}
+      else
+	Fset_frame_selected_window (calling_frame, calling_window, Qnil);
+    }
 }
+
+/* Replace the expired minibuffer in the selected frame with the next
+   less nested minibuffer, if any, stored in the minibuffer window.
+   Otherwise, replace it with the null minibuffer.  MINIBUF_WINDOW
+   gets set to the selected frame's minibuffer.  */
+static void
+minibuffer_unwind (void)
+{
+  struct frame *sf = XFRAME (selected_frame);
+  struct window *w;
+  Lisp_Object entry;
+
+  if (FRAMEP (selected_frame)
+      && FRAME_LIVE_P (sf))
+    {
+      minibuf_window = sf->minibuffer_window;
+      w = XWINDOW (minibuf_window);
+      if (!NILP (w->prev_buffers))
+	{
+	  entry = Fcar (w->prev_buffers);
+	  w->prev_buffers = Fcdr (w->prev_buffers);
+	  set_window_buffer (minibuf_window, Fcar (entry), 0, 0);
+	  Fset_window_start (minibuf_window, Fcar (Fcdr (entry)), Qnil);
+	  Fset_window_point (minibuf_window, Fcar (Fcdr (Fcdr (entry))));
+	  /* set-window-configuration may/will have unselected the
+	     mini-window as the selected window.  Restore it. */
+	  if (EQ (w->frame, selected_frame))
+	    Fset_frame_selected_window (selected_frame, minibuf_window, Qnil);
+	}
+      else
+	set_window_buffer (minibuf_window, nth_minibuffer (0), 0, 0);
+    }
+}
+
 \f
 
 void
diff --git a/src/window.c b/src/window.c
index eb16e2a433..cde53e8059 100644
--- a/src/window.c
+++ b/src/window.c
@@ -6958,7 +6960,8 @@ the return value is nil.  Otherwise the value is t.  */)
 
 	  if (BUFFERP (w->contents)
 	      && !EQ (w->contents, p->buffer)
-	      && BUFFER_LIVE_P (XBUFFER (p->buffer)))
+	      && BUFFER_LIVE_P (XBUFFER (p->buffer))
+	      && (NILP (Fminibufferp (p->buffer, Qnil))))
 	    /* If a window we restore gets another buffer, record the
 	       window's old buffer.  */
 	    call1 (Qrecord_window_buffer, window);
diff --git a/src/xdisp.c b/src/xdisp.c
index cc0a689ba3..a405d51f80 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12650,9 +12650,8 @@ gui_consider_frame_title (Lisp_Object frame)
 	 mode_line_noprop_buf; then display the title.  */
       record_unwind_protect (unwind_format_mode_line,
 			     format_mode_line_unwind_data
-			       (f, current_buffer, selected_window, false));
+			     (NULL, current_buffer, Qnil, false));
 
-      Fselect_window (f->selected_window, Qt);
       set_buffer_internal_1
 	(XBUFFER (XWINDOW (f->selected_window)->contents));
       fmt = FRAME_ICONIFIED_P (f) ? Vicon_title_format : Vframe_title_format;


>         Stefan


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

Hi Alan,

> I would be grateful indeed if either of you (or indeed, anybody else),
> would apply the patch and try it out, or indeed comment on it.  Thanks!

I'm not very familiar with this part of Emacs's code, but here are some
things I noticed:

> @@ -4416,7 +4416,8 @@ record-window-buffer
>         window (assq-delete-all buffer (window-prev-buffers window))))
>  
>      ;; Don't record insignificant buffers.
> -    (unless (eq (aref (buffer-name buffer) 0) ?\s)
> +    (when (or (not (eq (aref (buffer-name buffer) 0) ?\s))
> +              (string-match "^ \\*Minibuf" (buffer-name buffer)))

I think you want to use `minibufferp` here (and if not, then please add
a comment explaining why).

> @@ -4348,7 +4348,7 @@ extern void clear_regexp_cache (void);
>  
>  extern Lisp_Object Vminibuffer_list;
>  extern Lisp_Object last_minibuf_string;
> -extern void move_minibuffer_onto_frame (void);
> +extern void move_minibuffers_onto_frame (struct frame *, int);

Please use the `bool` type for booleans.

> +/* Get the next live buffer entry from a w->prev_buffer, setting the pertinent
> +  variables of `zip_minibuffer_stacks'.  The parameter P is either "d" for
> +  the destination structures, or "s" for the source structures.  When the
> +  ->prev_buffers list is exhausted, set di/si to -1.  */
> +#define NEXT_BUFFER_ENTRY(p)						\
> +  do									\
> +    {									\
> +      if (NILP (p##_bufs))						\
> +        {								\
> +	  p##b = Qnil;							\
> +	  p##_ent = Qnil;						\
> +	}								\
> +      else								\
> +	{								\
> +	  p##_ent = Fcar (p##_bufs);					\
> +	  p##b = Fcar (p##_ent);					\
> +	  p##_bufs = Fcdr (p##_bufs);					\
> +	}								\
> +      if (!NILP (p##b))							\
> +	p##i = this_minibuffer_depth (p##b);				\
> +      else								\
> +	p##i = -1;							\
> +    } while (p##i == 0)

Any chance we could make that into a function taking an argument `p`
that's a reference to a

   struct { Lisp_Object bufs; Lisp_Object b; Lisp_Object ent; int depth; }

?  I know we already use such longish macros in various places, but I'd
rather we use fewer of them rather than adding more of them, because
they're a pain to debug (and I find they make the code harder to read;
e.g. here we see a call to `NEXT_BUFFER_ENTRY` we can't know which
variables will be accessed/modified without looking at the definition of
the macro).

> +/* Move the ordered "stack" of minibuffers from SOURCE_WINDOW to
> +   DEST_WINDOW, interleaving those minibuffers with any in DEST_WINDOW
> +   to produce an ordered combination.  The ordering is by minibuffer
> +   depth.  A stack of minibuffers consists of the minibuffer currently
> +   in DEST/SOURCE_WINDOW together with any recorded in the
> +   ->prev_buffers field of the struct window.  */

This is actually the "merge" part of a merge sort, so we could use
`sort_list` or even just the `merge` function used by `sort_list`.

[ Tho maybe it is simpler and more robust (in case ELisp code can access
  (and hence modify) those lists) to leave those lists not sorted, and
  instead look for the deepest buffer in `minibuffer_unwind` rather than
  just picking the next.  ]

> +/* If `minibuffer_follows_selected_frame' is t, or we're about to
> +   delete a frame which potentially "contains" minibuffers, move them
> +   from the old frame to the selected frame.  This function is
> +   intended to be called from `do_switch_frame' in frame.c.  OF is the
> +   old frame, FOR_DELETION is self explanatory.  */

Actually, I suspect that the "self explanatory" part will not be true
when my daughter ends up having to fix that code 10 years from now.
[ Tho, it currently looks quite unlikely :-(  ]


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

Thanks for such a rapid and useful reply.

I'll put most of your suggestions (actually, probably all of them) into
my code this evening.

I didn't actually know there was a `sort_list' function, or a merge part
of it, so that should save quite a lot of code if I can use it (which I
probably can).

On Sat, Mar 13, 2021 at 14:39:28 -0500, Stefan Monnier wrote:
> Hi Alan,

> > I would be grateful indeed if either of you (or indeed, anybody else),
> > would apply the patch and try it out, or indeed comment on it.  Thanks!

> I'm not very familiar with this part of Emacs's code, but here are some
> things I noticed:

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> I didn't actually know there was a `sort_list' function, or a merge part
> of it, so that should save quite a lot of code if I can use it (which I
> probably can).

I didn't either, really, I found them by following the code from
`Fsort`.  Of course, this is meant for ELisp so the predicate has to be
an ELisp value rather than a C function, so it will probably force you
to define the predicate with DEFUN, which is not completely
satisfactory (tho not terribly harmful either, I guess).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

On Sat, Mar 13, 2021 at 15:52:51 -0500, Stefan Monnier wrote:
> > I didn't actually know there was a `sort_list' function, or a merge part
> > of it, so that should save quite a lot of code if I can use it (which I
> > probably can).

> I didn't either, really, I found them by following the code from
> `Fsort`.  Of course, this is meant for ELisp so the predicate has to be
> an ELisp value rather than a C function, so it will probably force you
> to define the predicate with DEFUN, which is not completely
> satisfactory (tho not terribly harmful either, I guess).

No, not completely satisfactory.  So, after spending an hour or so
trying to work out how to define a Lisp function in C without it being
visible in the Lisp world, I hit on a simpler solution - copy `merge' to
a new function `merge_c', replacing the Lisp predicate with a boolean C
function.  This works fine, at the small cost of a little code
duplication.

I think I've followed all your other suggestions from yesterday, now.

Anyhow, I think I've fixed the bugs that jakanakaevangeli pointed out
yesterday, so I'll post my updated patch in my reply to her/him.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sun, 14 Mar 2021 18:26:18 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: jakanakaevangeli <jakanakaevangeli@chiru.no>, emacs-devel@gnu.org
> 
> after spending an hour or so trying to work out how to define a Lisp
> function in C without it being visible in the Lisp world

Isn't defsubr sup[posed to do that?

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> No, not completely satisfactory.  So, after spending an hour or so
> trying to work out how to define a Lisp function in C without it being
> visible in the Lisp world,

Oh, I wasn't even thinking of trying to hide it from ELisp (AFAICT it's
not dangerous to expose it to ELisp).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stefan and jakanakaevangeli.
>
> On Thu, Feb 11, 2021 at 09:29:44 -0500, Stefan Monnier wrote:
>> > This is more involved.  What do we want to happen when a frame with open
>> > minibuffers is deleted?  I would say that these minibuffers should,
>> > except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
>> > together with any others in other frames whose nesting level makes this
>> > necessary.
>
>> I vote for moving those minibuffers elsewhere (anywhere else is fine by
>> me, really).  I assume it's no more complicated code-wise, and it should
>> suffer less from the risk of losing information.
>
> Just a quick recapitulation of the problem: when
> minibuffer-follows-selected-frame is nil, and
> enable-recursive-minibuffers t, it is possible to have several open
> minibuffers on several frames.  If one of these frames is deleted, its
> minibuffers continue to exist, but are wholly inaccessible - the only
> thing to do with them is to abort them, e.g. with C-].  This is
> suboptimal.
>
> The patch below tries to solve this by, when such a frame gets deleted,
> "zipping" its minibuffers into those of another frame.  The idea behind
> the patch is to use the mini-window's w->prev_buffers component to hold
> the list of its minibuffers.  This mini-window component was unused by
> the rest of Emacs, apart from accidentally by
> window--before-delete-windows, which I have now amended.
>
> I would be grateful indeed if either of you (or indeed, anybody else),
> would apply the patch and try it out, or indeed comment on it.  Thanks!

Great! I tested it and there still seem to be a few ways one can end up
with invisible active minibuffers, all of them with
minibuffer-follows-selected-frame set to nil:

1)
C-x C-f on frame A
C-x C-f on frame B
select frame A and press C-] (abort-recursive-edit)

This does quit only the inner minibuffer as expected but it hides the
outer one for some reason. This also seems to be a regression of this
patch, the minibuffer isn't hidden without this patch applied.

2) (Might depend on your window manager, I'm not sure)
Open frames A, B, and C
C-x C-f on frame A
C-x b on frame B
Close frame A

Both of the minibuffers are now moved to frame C and the outer C-x C-f
is shown in the mini-window, which is kind of annoying. If we now select
frame C and press C-], the same problem as in 1) occurs.

3)
In emacs daemon, evaluate
(run-at-time 5 nil #'make-frame '((window-system . x)))
and then open a minibuffer and close the last frame. When a new frame
appears, the same problem as in 1) occurs.

Hope this helps.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Jakanakaevangeli,

On Sat, Mar 13, 2021 at 21:53:05 +0100, jakanakaevangeli wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > I would be grateful indeed if either of you (or indeed, anybody else),
> > would apply the patch and try it out, or indeed comment on it.  Thanks!

> Great! I tested it and there still seem to be a few ways one can end up
> with invisible active minibuffers, all of them with
> minibuffer-follows-selected-frame set to nil:

> 1)
> C-x C-f on frame A
> C-x C-f on frame B
> select frame A and press C-] (abort-recursive-edit)

> This does quit only the inner minibuffer as expected but it hides the
> outer one for some reason. This also seems to be a regression of this
> patch, the minibuffer isn't hidden without this patch applied.

I think I've fixed that, now.  There was a call to
set-window-configuration which was replacing the wanted minibuffer with
a different one.  That's now fixed.

> 2) (Might depend on your window manager, I'm not sure)
> Open frames A, B, and C
> C-x C-f on frame A
> C-x b on frame B
> Close frame A

> Both of the minibuffers are now moved to frame C and the outer C-x C-f
> is shown in the mini-window, which is kind of annoying. If we now select
> frame C and press C-], the same problem as in 1) occurs.

This was a bit of dangling code from an earlier version which should
have been removed.  It was, again, overwriting "the" minibuffer (which
was still on frame B) with the null minibuffer, thus causing the C-x b
to be lost.

> 3)
> In emacs daemon, evaluate
> (run-at-time 5 nil #'make-frame '((window-system . x)))
> and then open a minibuffer and close the last frame. When a new frame
> appears, the same problem as in 1) occurs.

I think one of the two previous changes fixed this.

> Hope this helps.

It's been an enormous help, thanks!  Testing this is difficult because
there are so many different things which can interact with eachother in
so many unwanted ways.

Anyway, here's an updated patch, which should apply to master,
incorporating Stefan's suggestions from last night, and fixes to the
above bugs:




diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index f81e64bdf9..7da0a48b7c 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -82,7 +82,9 @@ Basic Minibuffer
 (@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
 (approximately) the behavior prior to Emacs 28.1.  Note that the
 effect of the command, when you finally finish using the minibuffer,
-always takes place in the frame where you first opened it.
+always takes place in the frame where you first opened it.  The sole
+exception is that when that frame no longer exists, the action takes
+place in the currently selected frame.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/lisp/window.el b/lisp/window.el
index cfd9876ed0..f27631bb86 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4158,7 +4158,7 @@ window--before-delete-windows
 
 This function is called only if `switch-to-buffer-preserve-window-point'
 evaluates non-nil."
-  (dolist (win (window-list))
+  (dolist (win (window-list nil 'no-minibuf))
     (let* ((buf   (window-buffer (or window win)))
            (start (window-start win))
            (pos   (window-point win))
@@ -4416,7 +4416,8 @@ record-window-buffer
        window (assq-delete-all buffer (window-prev-buffers window))))
 
     ;; Don't record insignificant buffers.
-    (unless (eq (aref (buffer-name buffer) 0) ?\s)
+    (when (or (not (eq (aref (buffer-name buffer) 0) ?\s))
+              (minibufferp buffer))
       ;; Add an entry for buffer to WINDOW's previous buffers.
       (with-current-buffer buffer
 	(let ((start (window-start window))
diff --git a/src/fns.c b/src/fns.c
index 7914bd4779..f9bd3913bb 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2227,6 +2227,52 @@ merge (Lisp_Object org_l1, Lisp_Object org_l2, Lisp_Object pred)
     }
 }
 
+Lisp_Object
+merge_c (Lisp_Object org_l1, Lisp_Object org_l2, bool (*less) (Lisp_Object, Lisp_Object))
+{
+  Lisp_Object l1 = org_l1;
+  Lisp_Object l2 = org_l2;
+  Lisp_Object tail = Qnil;
+  Lisp_Object value = Qnil;
+
+  while (1)
+    {
+      if (NILP (l1))
+	{
+	  if (NILP (tail))
+	    return l2;
+	  Fsetcdr (tail, l2);
+	  return value;
+	}
+      if (NILP (l2))
+	{
+	  if (NILP (tail))
+	    return l1;
+	  Fsetcdr (tail, l1);
+	  return value;
+	}
+
+      Lisp_Object tem;
+      if (less (Fcar (l1), Fcar (l2)))
+	{
+	  tem = l1;
+	  l1 = Fcdr (l1);
+	  org_l1 = l1;
+	}
+      else
+	{
+	  tem = l2;
+	  l2 = Fcdr (l2);
+	  org_l2 = l2;
+	}
+      if (NILP (tail))
+	value = tem;
+      else
+	Fsetcdr (tail, tem);
+      tail = tem;
+    }
+}
+
 \f
 /* This does not check for quits.  That is safe since it must terminate.  */
 
diff --git a/src/frame.c b/src/frame.c
index a62347c1fb..b9df5739dd 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1487,7 +1487,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
-  move_minibuffer_onto_frame ();
+  move_minibuffers_onto_frame (sf, for_deletion);
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index b95f389b89..c67c8b0857 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3610,6 +3610,7 @@ extern void validate_subarray (Lisp_Object, Lisp_Object, Lisp_Object,
 extern Lisp_Object substring_both (Lisp_Object, ptrdiff_t, ptrdiff_t,
 				   ptrdiff_t, ptrdiff_t);
 extern Lisp_Object merge (Lisp_Object, Lisp_Object, Lisp_Object);
+extern Lisp_Object merge_c (Lisp_Object, Lisp_Object, bool (*) (Lisp_Object, Lisp_Object));
 extern Lisp_Object do_yes_or_no_p (Lisp_Object);
 extern int string_version_cmp (Lisp_Object, Lisp_Object);
 extern Lisp_Object concat2 (Lisp_Object, Lisp_Object);
@@ -4348,7 +4349,7 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
-extern void move_minibuffer_onto_frame (void);
+extern void move_minibuffers_onto_frame (struct frame *, bool);
 extern bool is_minibuffer (EMACS_INT, Lisp_Object);
 extern EMACS_INT this_minibuffer_depth (Lisp_Object);
 extern EMACS_INT minibuf_level;
diff --git a/src/minibuf.c b/src/minibuf.c
index 4b1f4b1ff7..279dc67c33 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -67,6 +67,7 @@ static ptrdiff_t minibuf_prompt_width;
 static Lisp_Object nth_minibuffer (EMACS_INT depth);
 static EMACS_INT minibuf_c_loop_level (EMACS_INT depth);
 static void set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth);
+static bool live_minibuffer_p (Lisp_Object);
 
 \f
 /* Return TRUE when a frame switch causes a minibuffer on the old
@@ -78,6 +79,7 @@ minibuf_follows_frame (void)
              Qt);
 }
 
+#if 0
 /* Return TRUE when a minibuffer always remains on the frame where it
    was first invoked. */
 static bool
@@ -85,6 +87,7 @@ minibuf_stays_put (void)
 {
   return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
+#endif
 
 /* Return TRUE when opening a (recursive) minibuffer causes
    minibuffers on other frames to move to the selected frame.  */
@@ -112,84 +115,86 @@ choose_minibuf_frame (void)
 	emacs_abort ();
 
       minibuf_window = sf->minibuffer_window;
-      /* If we've still got another minibuffer open, use its mini-window
-         instead.  */
-      if (minibuf_level > 1 && minibuf_stays_put ())
-        {
-          Lisp_Object buffer = get_minibuffer (minibuf_level);
-          Lisp_Object tail, frame;
-
-          FOR_EACH_FRAME (tail, frame)
-            if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
-                    buffer))
-              {
-                minibuf_window = XFRAME (frame)->minibuffer_window;
-                break;
-              }
-        }
     }
+}
 
-  if (minibuf_moves_frame_when_opened ()
-      && FRAMEP (selected_frame)
-      && FRAME_LIVE_P (XFRAME (selected_frame)))
-    /* Make sure no other frame has a minibuffer as its selected window,
-       because the text would not be displayed in it, and that would be
-       confusing.  Only allow the selected frame to do this,
-       and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
-    struct frame *of;
-
-    FOR_EACH_FRAME (tail, frame)
-      if (!EQ (frame, selected_frame)
-          && minibuf_level > 1
-	  /* The frame's minibuffer can be on a different frame.  */
-	  && ! EQ (XWINDOW ((of = XFRAME (frame))->minibuffer_window)->frame,
-		   selected_frame))
-        {
-          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
-            Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                        Qnil);
-
-          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
-                   nth_minibuffer (0)))
-            set_window_buffer (of->minibuffer_window,
-                               nth_minibuffer (0), 0, 0);
-        }
-  }
+/* If ENT1 has a higher minibuffer index than ENT2, return true.  More
+precisely, compare the buffer components of each window->prev_buffers
+entry.  */
+static bool
+minibuffer_ent_greater (Lisp_Object ent1, Lisp_Object ent2)
+{
+  return this_minibuffer_depth (Fcar (ent1))
+    > this_minibuffer_depth (Fcar (ent2)) ;
 }
 
-/* If `minibuffer_follows_selected_frame' is t and we have a
-   minibuffer, move it from its current frame to the selected frame.
-   This function is intended to be called from `do_switch_frame' in
-   frame.c.  */
-void move_minibuffer_onto_frame (void)
+/* Move the ordered "stack" of minibuffers from SOURCE_WINDOW to
+   DEST_WINDOW, interleaving those minibuffers with any in DEST_WINDOW
+   to produce an ordered combination.  The ordering is by minibuffer
+   depth.  A stack of minibuffers consists of the minibuffer currently
+   in DEST/SOURCE_WINDOW together with any recorded in the
+   ->prev_buffers field of the struct window.  */
+static void
+zip_minibuffer_stacks (Lisp_Object dest_window, Lisp_Object source_window)
 {
-  if (!minibuf_level)
-    return;
-  if (!minibuf_follows_frame ())
+  struct window *dw = XWINDOW (dest_window);
+  struct window *sw = XWINDOW (source_window);
+  Lisp_Object acc;
+  Lisp_Object d_ent;	/* Entry from dw->prev_buffers */
+
+  if (!live_minibuffer_p (dw->contents)
+      && NILP (dw->prev_buffers))
+    {
+      set_window_buffer (dest_window, sw->contents, 0, 0);
+      Fset_window_start (dest_window, Fwindow_start (source_window), Qnil);
+      Fset_window_point (dest_window, Fwindow_point (source_window));
+      dw->prev_buffers = sw->prev_buffers;
+      set_window_buffer (source_window, get_minibuffer (0), 0, 0);
+      sw->prev_buffers = Qnil;
+      return;
+    }
+
+  if (live_minibuffer_p (dw->contents))
+    call1 (Qrecord_window_buffer, dest_window);
+  if (live_minibuffer_p (sw->contents))
+    call1 (Qrecord_window_buffer, source_window);
+
+  acc = merge_c (dw->prev_buffers, sw->prev_buffers, minibuffer_ent_greater);
+
+  if (!NILP (acc))
+    {
+      d_ent = Fcar (acc);
+      acc = Fcdr (acc);
+      set_window_buffer (dest_window, Fcar (d_ent), 0, 0);
+      Fset_window_start (dest_window, Fcar (Fcdr (d_ent)), Qnil);
+      Fset_window_point (dest_window, Fcar (Fcdr (Fcdr (d_ent))));
+    }
+  dw->prev_buffers = acc;
+  sw->prev_buffers = Qnil;
+  set_window_buffer (source_window, get_minibuffer (0), 0, 0);
+}
+
+/* If `minibuffer_follows_selected_frame' is t, or we're about to
+   delete a frame which potentially "contains" minibuffers, move them
+   from the old frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  OF is the
+   old frame, FOR_DELETION is true if OF is about to be deleted.  */
+void
+move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
+{
+  if (!for_deletion && (!minibuf_level || !minibuf_follows_frame ()))
     return;
   if (FRAMEP (selected_frame)
       && FRAME_LIVE_P (XFRAME (selected_frame))
-      && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+      && (for_deletion
+	  || !EQ (minibuf_window,
+		  XFRAME (selected_frame)->minibuffer_window)))
     {
-      EMACS_INT i;
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
-      struct frame *of = XFRAME (old_frame);
 
-      /* Stack up all the (recursively) open minibuffers on the selected
-         mini_window.  */
-      for (i = 1; i <= minibuf_level; i++)
-	set_window_buffer (sf->minibuffer_window, nth_minibuffer (i), 0, 0);
-      minibuf_window = sf->minibuffer_window;
-      if (of != sf)
-	{
-	  Lisp_Object temp = get_minibuffer (0);
-
-	  set_window_buffer (of->minibuffer_window, temp, 0, 0);
-	  set_minibuffer_mode (temp, 0);
-	}
+      if (minibuf_follows_frame () || for_deletion)
+	zip_minibuffer_stacks (sf->minibuffer_window,
+			       of->minibuffer_window);
     }
 }
 
@@ -221,6 +226,7 @@ without invoking the usual minibuffer commands.  */)
 /* Actual minibuffer invocation.  */
 
 static void read_minibuf_unwind (void);
+static void minibuffer_unwind (void);
 static void run_exit_minibuf_hook (void);
 
 
@@ -544,7 +550,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histval;
 
   Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
+  Lisp_Object old_minibuf_window = minibuf_window;
 
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
@@ -626,17 +632,23 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
 
   if (minibuf_level > 1
+      && (!EQ (minibuf_window, old_minibuf_window))
       && minibuf_moves_frame_when_opened ()
-      && (!minibuf_follows_frame ()
-	  || (!EQ (mini_frame, selected_frame))))
+      && (!minibuf_follows_frame ()))
     {
-      EMACS_INT i;
+      Lisp_Object old_frame = XWINDOW (old_minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
 
-      /* Stack up the existing minibuffers on the current mini-window */
-      for (i = 1; i < minibuf_level; i++)
-	set_window_buffer (minibuf_window, nth_minibuffer (i), 0, 0);
+      zip_minibuffer_stacks (minibuf_window, old_minibuf_window);
+      /* The frame's minibuffer can be on a different frame.  */
+      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+	Fset_frame_selected_window (old_frame,
+				    Fframe_first_window (old_frame), Qnil);
     }
+  if (live_minibuffer_p (XWINDOW (minibuf_window)->contents))
+    call1 (Qrecord_window_buffer, minibuf_window);
 
+  record_unwind_protect_void (minibuffer_unwind);
   record_unwind_protect (restore_window_configuration,
                          Fcons (Qt, Fcurrent_window_configuration (Qnil)));
 
@@ -771,23 +783,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   empty_minibuf = get_minibuffer (0);
   set_minibuffer_mode (empty_minibuf, 0);
 
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-      Lisp_Object buffer;
-
-      if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
-          && !NILP (Fwindow_minibuffer_p (mini_window)))
-        {
-          buffer = XWINDOW (mini_window)->contents;
-          if (!live_minibuffer_p (buffer))
-            /* Use set_window_buffer instead of Fset_window_buffer (see
-               discussion of bug#11984, bug#12025, bug#12026).  */
-            set_window_buffer (mini_window, empty_minibuf, 0, 0);
-        }
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -908,7 +903,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   unbind_to (count, Qnil);
 
   /* Switch the frame back to the calling frame.  */
-  if (!EQ (selected_frame, calling_frame)
+  if ((!EQ (selected_frame, calling_frame)
+       || !EQ (XWINDOW (XFRAME (calling_frame)->minibuffer_window)->frame,
+	       calling_frame))
       && FRAMEP (calling_frame)
       && FRAME_LIVE_P (XFRAME (calling_frame)))
     call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil);
@@ -1026,6 +1023,11 @@ run_exit_minibuf_hook (void)
   safe_run_hooks (Qminibuffer_exit_hook);
 }
 
+/* This variable preserves the minibuffer in the selected frame across
+   the call of restore_window_configuration.  It should be used only
+   by `read_minibuf_unwind' and `minibuffer_unwind'.  */
+static Lisp_Object selected_frame_MB;
+
 /* This function is called on exiting minibuffer, whether normally or
    not, and it restores the current window, buffer, etc.  */
 
@@ -1127,20 +1129,72 @@ read_minibuf_unwind (void)
      away from the expired minibuffer window, both in the current
      minibuffer's frame and the original calling frame.  */
   choose_minibuf_frame ();
-  if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
-  {
-    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
-    /* PREV can be on a different frame when we have a minibuffer only
-       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
-       and its "focus window" is also MINIBUF_WINDOW.  */
-    if (!EQ (prev, minibuf_window)
-	&& EQ (WINDOW_FRAME (XWINDOW (prev)),
-	       WINDOW_FRAME (XWINDOW (minibuf_window))))
-      Fset_frame_selected_window (selected_frame, prev, Qnil);
-  }
-  else
-    Fset_frame_selected_window (calling_frame, calling_window, Qnil);
+  selected_frame_MB = XWINDOW (minibuf_window)->contents;
+  if (NILP (XWINDOW (minibuf_window)->prev_buffers))
+    {
+      if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
+	{
+	  Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+	  /* PREV can be on a different frame when we have a minibuffer only
+	     frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+	     and its "focus window" is also MINIBUF_WINDOW.  */
+	  if (!EQ (prev, minibuf_window)
+	      && EQ (WINDOW_FRAME (XWINDOW (prev)),
+		     WINDOW_FRAME (XWINDOW (minibuf_window))))
+	    Fset_frame_selected_window (selected_frame, prev, Qnil);
+	}
+      else
+	Fset_frame_selected_window (calling_frame, calling_window, Qnil);
+    }
 }
+
+/* Replace the expired minibuffer in whatever frame it is now in with
+   the next less nested minibuffer in that frame, if any.  Otherwise,
+   replace it with the null minibuffer.  MINIBUF_WINDOW is not
+   changed.  */
+static void
+minibuffer_unwind (void)
+{
+  struct frame *f;
+  struct window *w;
+  Lisp_Object window, frame, frames;
+  Lisp_Object entry;
+
+  /* Locate the expired minibuffer.  */
+  FOR_EACH_FRAME (frames, frame)
+    {
+      f = XFRAME (frame);
+      window = f->minibuffer_window;
+      w = XWINDOW (window);
+      if (EQ (w->frame, frame)
+	  && EQ (EQ (frame, selected_frame)
+		 ? selected_frame_MB
+		 : w->contents,
+		 nth_minibuffer (minibuf_level + 1)))
+	goto found;
+    }
+  return; 			/* expired minibuffer not found */
+
+ found:
+  if (FRAME_LIVE_P (f))
+    {
+      /* minibuf_window = sf->minibuffer_window; */
+      if (!NILP (w->prev_buffers))
+	{
+	  entry = Fcar (w->prev_buffers);
+	  w->prev_buffers = Fcdr (w->prev_buffers);
+	  set_window_buffer (window, Fcar (entry), 0, 0);
+	  Fset_window_start (window, Fcar (Fcdr (entry)), Qnil);
+	  Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
+	  /* set-window-configuration may/will have unselected the
+	     mini-window as the selected window.  Restore it. */
+	  Fset_frame_selected_window (frame, window, Qnil);
+	}
+      else
+	set_window_buffer (window, nth_minibuffer (0), 0, 0);
+    }
+}
+
 \f
 
 void
@@ -2213,6 +2267,7 @@ syms_of_minibuf (void)
 {
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
+  staticpro (&selected_frame_MB);
 
   DEFSYM (Qminibuffer_follows_selected_frame,
           "minibuffer-follows-selected-frame");
diff --git a/src/window.c b/src/window.c
index eb16e2a433..cde53e8059 100644
--- a/src/window.c
+++ b/src/window.c
@@ -6958,7 +6960,8 @@ the return value is nil.  Otherwise the value is t.  */)
 
 	  if (BUFFERP (w->contents)
 	      && !EQ (w->contents, p->buffer)
-	      && BUFFER_LIVE_P (XBUFFER (p->buffer)))
+	      && BUFFER_LIVE_P (XBUFFER (p->buffer))
+	      && (NILP (Fminibufferp (p->buffer, Qnil))))
 	    /* If a window we restore gets another buffer, record the
 	       window's old buffer.  */
 	    call1 (Qrecord_window_buffer, window);
diff --git a/src/xdisp.c b/src/xdisp.c
index cc0a689ba3..a405d51f80 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12650,9 +12650,8 @@ gui_consider_frame_title (Lisp_Object frame)
 	 mode_line_noprop_buf; then display the title.  */
       record_unwind_protect (unwind_format_mode_line,
 			     format_mode_line_unwind_data
-			       (f, current_buffer, selected_window, false));
+			     (NULL, current_buffer, Qnil, false));
 
-      Fselect_window (f->selected_window, Qt);
       set_buffer_internal_1
 	(XBUFFER (XWINDOW (f->selected_window)->contents));
       fmt = FRAME_ICONIFIED_P (f) ? Vicon_title_format : Vframe_title_format;


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Miha Rihtaršič]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Jakanakaevangeli,
>
> On Sat, Mar 13, 2021 at 21:53:05 +0100, jakanakaevangeli wrote:
>
> [ .... ]
>
>> 3)
>> In emacs daemon, evaluate
>> (run-at-time 5 nil #'make-frame '((window-system . x)))
>> and then open a minibuffer and close the last frame. When a new frame
>> appears, the same problem as in 1) occurs.
>
> I think one of the two previous changes fixed this.

Sorry, this still doesn't seem to be fixed. Just in case I wasn't clear
enough, I'll try to reiterate.

When a frame is closed, it's active minibuffer should now be moved to
another frame. What I wanted to test then was, what happens if we have
only a single frame with a minibuffer and we decide to close it, which
is possible with emacs daemon. Immediately, there will be no frames left
for the minibuffer to take refuge in and this seems to cause some
problems.

And two new regressions. These require minibuffer-follows-selected-frame
to be set to t.

1)
C-x C-f on frame A
select frame B
select frame A
Minibuffer is moved to B, but not back to A.

2)
Have two frames open
open a minibuffer on a frame
close this frame
The other frame does have the miniwindow selected, but the
minibuffer isn't shown in it.

Best.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Miha.

On Sun, Mar 14, 2021 at 22:23:02 +0100, Miha Rihtaršič wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Jakanakaevangeli,

> > On Sat, Mar 13, 2021 at 21:53:05 +0100, jakanakaevangeli wrote:

> > [ .... ]

> >> 3)
> >> In emacs daemon, evaluate
> >> (run-at-time 5 nil #'make-frame '((window-system . x)))
> >> and then open a minibuffer and close the last frame. When a new frame
> >> appears, the same problem as in 1) occurs.

> > I think one of the two previous changes fixed this.

> Sorry, this still doesn't seem to be fixed. Just in case I wasn't clear
> enough, I'll try to reiterate.

> When a frame is closed, it's active minibuffer should now be moved to
> another frame. What I wanted to test then was, what happens if we have
> only a single frame with a minibuffer and we decide to close it, which
> is possible with emacs daemon. Immediately, there will be no frames left
> for the minibuffer to take refuge in and this seems to cause some
> problems.

My apologies.  I hadn't understood what the bug is, and can confirm it's
still there.  My patch below doesn't address it.

This could be difficult to fix.  I don't think that clicking on the last
frame's close button goes through `delete-frame' - it just closes the
program, whether that's emacs or emacsclient.  Maybe there's some "close
program" hook that could be used to save any stack of open minibuffers.
I just don't know the code in this area.  At least, not yet.  ;-)

> And two new regressions. These require minibuffer-follows-selected-frame
> to be set to t.

Yes.  Sorry about these.  This time around, I've tried to be more
careful and done more testing myself - hence me taking a few days longer
than I have up till now.  I've found and corrected another ~two bugs
myself.

> 1)
> C-x C-f on frame A
> select frame B
> select frame A
> Minibuffer is moved to B, but not back to A.

> 2)
> Have two frames open
> open a minibuffer on a frame
> close this frame
> The other frame does have the miniwindow selected, but the
> minibuffer isn't shown in it.

I think I've corrected these two, now.

Here's another patch, this time to be applied on top of the last patch.



--- minibuf.20210315.see	2021-03-16 10:36:40.058109894 +0000
+++ minibuf.c	2021-03-17 19:15:33.586176135 +0000
@@ -59,6 +59,12 @@
 
 static Lisp_Object minibuf_prompt;
 
+/* The frame containinug the most recently opened Minibuffer.  This is
+   used only when `minibuffer-follows-selected-frame' is neither nil
+   nor t.  */
+
+static Lisp_Object MB_frame;
+
 /* Width of current mini-buffer prompt.  Only set after display_line
    of the line that contains the prompt.  */
 
@@ -182,19 +188,17 @@
 void
 move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
 {
+  struct frame *f = XFRAME (selected_frame);
+
+  minibuf_window = f->minibuffer_window;
   if (!for_deletion && (!minibuf_level || !minibuf_follows_frame ()))
     return;
-  if (FRAMEP (selected_frame)
-      && FRAME_LIVE_P (XFRAME (selected_frame))
-      && (for_deletion
-	  || !EQ (minibuf_window,
-		  XFRAME (selected_frame)->minibuffer_window)))
+  if (FRAME_LIVE_P (f)
+      && !EQ (f->minibuffer_window, of->minibuffer_window))
     {
-      struct frame *sf = XFRAME (selected_frame);
-
-      if (minibuf_follows_frame () || for_deletion)
-	zip_minibuffer_stacks (sf->minibuffer_window,
-			       of->minibuffer_window);
+      zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window);
+      if (for_deletion && EQ (XFRAME (MB_frame), of))
+	MB_frame = selected_frame;
     }
 }
 
@@ -550,7 +554,6 @@
   Lisp_Object histval;
 
   Lisp_Object empty_minibuf;
-  Lisp_Object old_minibuf_window = minibuf_window;
 
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
@@ -632,19 +635,20 @@
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
 
   if (minibuf_level > 1
-      && (!EQ (minibuf_window, old_minibuf_window))
+      && !EQ (XWINDOW (XFRAME (selected_frame)->minibuffer_window)->frame,
+	      MB_frame)
       && minibuf_moves_frame_when_opened ()
       && (!minibuf_follows_frame ()))
     {
-      Lisp_Object old_frame = XWINDOW (old_minibuf_window)->frame;
-      struct frame *of = XFRAME (old_frame);
+      struct frame *of = XFRAME (MB_frame);
 
-      zip_minibuffer_stacks (minibuf_window, old_minibuf_window);
-      /* The frame's minibuffer can be on a different frame.  */
+      zip_minibuffer_stacks (minibuf_window, of->minibuffer_window);
+      /* MB_frame's minibuffer can be on a different frame.  */
       if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
-	Fset_frame_selected_window (old_frame,
-				    Fframe_first_window (old_frame), Qnil);
+	Fset_frame_selected_window (MB_frame,
+				    Fframe_first_window (MB_frame), Qnil);
     }
+  MB_frame = XWINDOW (XFRAME (selected_frame)->minibuffer_window)->frame;
   if (live_minibuffer_p (XWINDOW (minibuf_window)->contents))
     call1 (Qrecord_window_buffer, minibuf_window);
 
@@ -1023,10 +1027,13 @@
   safe_run_hooks (Qminibuffer_exit_hook);
 }
 
-/* This variable preserves the minibuffer in the selected frame across
-   the call of restore_window_configuration.  It should be used only
-   by `read_minibuf_unwind' and `minibuffer_unwind'.  */
-static Lisp_Object selected_frame_MB;
+/* This variable records the expired minibuffer's frame between the
+   calls of `read_minibuf_unwind' and `minibuffer_unwind'.  It should
+   be used only by these two functions.  Note that the same search
+   method for the MB's frame won't always work in `minibuffer_unwind'
+   because the intervening `restore-window-configuration' will have
+   changed the buffer in the mini-window.  */
+static Lisp_Object exp_MB_frame;
 
 /* This function is called on exiting minibuffer, whether normally or
    not, and it restores the current window, buffer, etc.  */
@@ -1038,6 +1045,28 @@
   Lisp_Object calling_frame;
   Lisp_Object calling_window;
   Lisp_Object future_mini_window;
+  Lisp_Object saved_selected_frame = selected_frame;
+  Lisp_Object window, frames;
+  struct window *w;
+  struct frame *f;
+
+  /* Locate the expired minibuffer.  */
+  FOR_EACH_FRAME (frames, exp_MB_frame)
+    {
+      f = XFRAME (exp_MB_frame);
+      window = f->minibuffer_window;
+      w = XWINDOW (window);
+      if (EQ (w->frame, exp_MB_frame)
+	  && EQ (w->contents, nth_minibuffer (minibuf_level)))
+	goto found;
+    }
+  return; /* expired minibuffer not found.  Maybe we should output an
+	     error, here. */
+
+ found:
+  if (!EQ (exp_MB_frame, saved_selected_frame))
+    do_switch_frame (exp_MB_frame, 0, 0, Qt); /* This also sets
+					     minibuff_window */
 
   /* To keep things predictable, in case it matters, let's be in the
      minibuffer when we reset the relevant variables.  Don't depend on
@@ -1129,7 +1158,6 @@
      away from the expired minibuffer window, both in the current
      minibuffer's frame and the original calling frame.  */
   choose_minibuf_frame ();
-  selected_frame_MB = XWINDOW (minibuf_window)->contents;
   if (NILP (XWINDOW (minibuf_window)->prev_buffers))
     {
       if (!EQ (WINDOW_FRAME (XWINDOW (minibuf_window)), calling_frame))
@@ -1146,36 +1174,26 @@
       else
 	Fset_frame_selected_window (calling_frame, calling_window, Qnil);
     }
+
+  /* Restore the selected frame. */
+  if (!EQ (exp_MB_frame, saved_selected_frame))
+    do_switch_frame (saved_selected_frame, 0, 0, Qt);
 }
 
-/* Replace the expired minibuffer in whatever frame it is now in with
-   the next less nested minibuffer in that frame, if any.  Otherwise,
-   replace it with the null minibuffer.  MINIBUF_WINDOW is not
-   changed.  */
+/* Replace the expired minibuffer in frame exp_MB_frame with the next less
+   nested minibuffer in that frame, if any.  Otherwise, replace it
+   with the null minibuffer.  MINIBUF_WINDOW is not changed.  */
 static void
 minibuffer_unwind (void)
 {
   struct frame *f;
   struct window *w;
-  Lisp_Object window, frame, frames;
+  Lisp_Object window;
   Lisp_Object entry;
 
-  /* Locate the expired minibuffer.  */
-  FOR_EACH_FRAME (frames, frame)
-    {
-      f = XFRAME (frame);
-      window = f->minibuffer_window;
-      w = XWINDOW (window);
-      if (EQ (w->frame, frame)
-	  && EQ (EQ (frame, selected_frame)
-		 ? selected_frame_MB
-		 : w->contents,
-		 nth_minibuffer (minibuf_level + 1)))
-	goto found;
-    }
-  return; 			/* expired minibuffer not found */
-
- found:
+  f = XFRAME (exp_MB_frame);
+  window = f->minibuffer_window;
+  w = XWINDOW (window);
   if (FRAME_LIVE_P (f))
     {
       /* minibuf_window = sf->minibuffer_window; */
@@ -1188,7 +1206,7 @@
 	  Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
 	  /* set-window-configuration may/will have unselected the
 	     mini-window as the selected window.  Restore it. */
-	  Fset_frame_selected_window (frame, window, Qnil);
+	  Fset_frame_selected_window (exp_MB_frame, window, Qnil);
 	}
       else
 	set_window_buffer (window, nth_minibuffer (0), 0, 0);
@@ -2267,7 +2285,9 @@
 {
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
-  staticpro (&selected_frame_MB);
+  staticpro (&MB_frame);
+  MB_frame = Qnil;
+  staticpro (&exp_MB_frame);
 
   DEFSYM (Qminibuffer_follows_selected_frame,
           "minibuffer-follows-selected-frame");


> Best.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 17 Mar 2021 19:32:37 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> > When a frame is closed, it's active minibuffer should now be moved to
> > another frame. What I wanted to test then was, what happens if we have
> > only a single frame with a minibuffer and we decide to close it, which
> > is possible with emacs daemon. Immediately, there will be no frames left
> > for the minibuffer to take refuge in and this seems to cause some
> > problems.
> 
> My apologies.  I hadn't understood what the bug is, and can confirm it's
> still there.  My patch below doesn't address it.
> 
> This could be difficult to fix.  I don't think that clicking on the last
> frame's close button goes through `delete-frame' - it just closes the
> program, whether that's emacs or emacsclient.

I'm not sure I understand completely what you say here, but clicking
on the frame's close button does invoke delete-frame, see the handling
of DELETE_FRAME_EVENT in keyboard.c.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 17 Mar 2021 21:55:38 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> 
> > This could be difficult to fix.  I don't think that clicking on the last
> > frame's close button goes through `delete-frame' - it just closes the
> > program, whether that's emacs or emacsclient.
> 
> I'm not sure I understand completely what you say here, but clicking
> on the frame's close button does invoke delete-frame, see the handling
> of DELETE_FRAME_EVENT in keyboard.c.

And if you are talking about the last live frame of an Emacs session,
then look at handle-delete-frame, which is called when you click that
close button: it will call save-buffers-kill-emacs (which has a hook)
and then kill-emacs (which also has a hook).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Mar 17, 2021 at 22:19:10 +0200, Eli Zaretskii wrote:
> > Date: Wed, 17 Mar 2021 21:55:38 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org

> > > This could be difficult to fix.  I don't think that clicking on the last
> > > frame's close button goes through `delete-frame' - it just closes the
> > > program, whether that's emacs or emacsclient.

> > I'm not sure I understand completely what you say here, but clicking
> > on the frame's close button does invoke delete-frame, see the handling
> > of DELETE_FRAME_EVENT in keyboard.c.

> And if you are talking about the last live frame of an Emacs session,
> then look at handle-delete-frame, which is called when you click that
> close button: it will call save-buffers-kill-emacs (which has a hook)
> and then kill-emacs (which also has a hook).

Thank you, that is very helpful.  I was indeed talking about the last
live frame, specifically in an emacsclient session when the Emacs daemon
is running.

The problem that Miha highlighted is that when there is an open
minibuffer when that last frame is deleted, that open minibuffer remains
in existence, fouling up the next emacsclient session.

Maybe such open minibuffers should just be aborted (along with any other
recursive edits) when the last frame gets deleted.  This would be
simpler to code than preserving those minibuffers somewhere, and
restoring them at the next emacsclient session.  Aborting them also
seems more natural, since their contents are unlikely to have any
relevance to the next emacsclient session.

Incidentally, there doesn't seem to be anything in the Elisp manual
about the handling of Emacs daemon sessions.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Thu, 18 Mar 2021 11:27:18 +0000
> Cc: monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> The problem that Miha highlighted is that when there is an open
> minibuffer when that last frame is deleted, that open minibuffer remains
> in existence, fouling up the next emacsclient session.
> 
> Maybe such open minibuffers should just be aborted (along with any other
> recursive edits) when the last frame gets deleted.  This would be
> simpler to code than preserving those minibuffers somewhere, and
> restoring them at the next emacsclient session.  Aborting them also
> seems more natural, since their contents are unlikely to have any
> relevance to the next emacsclient session.

Martin, can you comment on this, please?

> Incidentally, there doesn't seem to be anything in the Elisp manual
> about the handling of Emacs daemon sessions.

Please be more specific: which aspects of the daemon sessions would
you like to be described that aren't already described?

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> The problem that Miha highlighted is that when there is an open
 >> minibuffer when that last frame is deleted, that open minibuffer remains
 >> in existence, fouling up the next emacsclient session.
 >>
 >> Maybe such open minibuffers should just be aborted (along with any other
 >> recursive edits) when the last frame gets deleted.  This would be
 >> simpler to code than preserving those minibuffers somewhere, and
 >> restoring them at the next emacsclient session.  Aborting them also
 >> seems more natural, since their contents are unlikely to have any
 >> relevance to the next emacsclient session.
 >
 > Martin, can you comment on this, please?

What about answering questions about unsaved buffers, running processes
...  in such a situation?  I never use emacsclient so I have no idea how
this should behave in practice.  But any non-crucial dialog should be
aborted IMHO.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin and Eli.

On Thu, Mar 18, 2021 at 16:51:32 +0100, martin rudalics wrote:
>  >> The problem that Miha highlighted is that when there is an open
>  >> minibuffer when that last frame is deleted, that open minibuffer remains
>  >> in existence, fouling up the next emacsclient session.
>  >>
>  >> Maybe such open minibuffers should just be aborted (along with any other
>  >> recursive edits) when the last frame gets deleted.  This would be
>  >> simpler to code than preserving those minibuffers somewhere, and
>  >> restoring them at the next emacsclient session.  Aborting them also
>  >> seems more natural, since their contents are unlikely to have any
>  >> relevance to the next emacsclient session.
>  >
>  > Martin, can you comment on this, please?

> What about answering questions about unsaved buffers, running processes
> ...  in such a situation?  I never use emacsclient so I have no idea how
> this should behave in practice.

I don't use emacsclient either.  But questions about unsaved buffers
seem to prevent Emacs terminating until they get answered.  The same for
running processes (at least, for gdb).

> But any non-crucial dialog should be aborted IMHO.

Are the any uses of the minibuffer which count as crucial, in this
sense?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Thu, 18 Mar 2021 16:58:25 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>   jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> >  >> Maybe such open minibuffers should just be aborted (along with any other
> >  >> recursive edits) when the last frame gets deleted.  This would be
> >  >> simpler to code than preserving those minibuffers somewhere, and
> >  >> restoring them at the next emacsclient session.  Aborting them also
> >  >> seems more natural, since their contents are unlikely to have any
> >  >> relevance to the next emacsclient session.
> >  >
> >  > Martin, can you comment on this, please?
> 
> > What about answering questions about unsaved buffers, running processes
> > ...  in such a situation?  I never use emacsclient so I have no idea how
> > this should behave in practice.
> 
> I don't use emacsclient either.  But questions about unsaved buffers
> seem to prevent Emacs terminating until they get answered.  The same for
> running processes (at least, for gdb).

Are we shutting down Emacs, or are we returning to a headless daemon
state?  If the former, we need to ask all those questions before we
shut down Emacs.  Why is it a problem to ask them?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Thu, Mar 18, 2021 at 20:44:12 +0200, Eli Zaretskii wrote:
> > Date: Thu, 18 Mar 2021 16:58:25 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> >   jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > >  >> Maybe such open minibuffers should just be aborted (along with any other
> > >  >> recursive edits) when the last frame gets deleted.  This would be
> > >  >> simpler to code than preserving those minibuffers somewhere, and
> > >  >> restoring them at the next emacsclient session.  Aborting them also
> > >  >> seems more natural, since their contents are unlikely to have any
> > >  >> relevance to the next emacsclient session.

> > >  > Martin, can you comment on this, please?

> > > What about answering questions about unsaved buffers, running processes
> > > ...  in such a situation?  I never use emacsclient so I have no idea how
> > > this should behave in practice.

> > I don't use emacsclient either.  But questions about unsaved buffers
> > seem to prevent Emacs terminating until they get answered.  The same for
> > running processes (at least, for gdb).

> Are we shutting down Emacs, or are we returning to a headless daemon
> state?

Returning to a headless daemon state.

> If the former, we need to ask all those questions before we shut down
> Emacs.  Why is it a problem to ask them?

Sorry, I didn't mean to imply these things were problems; it was just an
observation, comparing the question about unsaved buffers with the lack
of a question on open minibuffers.

In the following, I'm using my not yet committed version of minibuf.c,
etc.:

When I now try Miha's recipe:
   (In last frame of emacsclient:)
   M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
   C-x C-f foo
   Close the frame by clicking on its close button
   <Wait the remainder of the 10 seconds>

, the new frame comes up _with_ the minibuffer visible.  I don't
understand how the mini window survived with its contents, and it
worries me.  The minibuffers are stored in the frames'
->minibuffer_window components, as well as existing as buffers in their
own right.  When the last frame is deleted, I would expect the MB to
survive, but NOT to be put back into the mini window of the newly
created frame.

Could it be that the last frame isn't actually deleted from the Emacs
daemon when clicking on its close button?  Merely that the emacsclient
program is closed, leaving its window inactive/invisible/whatever?  In
fact running M-: (frame-list) shows two frames, one of which is called "
*Minibuf-1*", though it isn't displayed in X-Windows.

This is the sort of thing I would like to be able to read about in the
Elisp manual, along with basic questions like "How can one test whether
one is in an emacsclient session rather than an ordinary Emacs?".

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 19 Mar 2021 11:40:52 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > What about answering questions about unsaved buffers, running processes
> > > > ...  in such a situation?  I never use emacsclient so I have no idea how
> > > > this should behave in practice.
> 
> > > I don't use emacsclient either.  But questions about unsaved buffers
> > > seem to prevent Emacs terminating until they get answered.  The same for
> > > running processes (at least, for gdb).
> 
> > Are we shutting down Emacs, or are we returning to a headless daemon
> > state?
> 
> Returning to a headless daemon state.

Then I think there's no need to ask those questions at all.  Emacs is
not going away, so it's okay to leave unsaved edits in the session
that continues to run.

> When I now try Miha's recipe:
>    (In last frame of emacsclient:)
>    M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
>    C-x C-f foo
>    Close the frame by clicking on its close button
>    <Wait the remainder of the 10 seconds>
> 
> , the new frame comes up _with_ the minibuffer visible.  I don't
> understand how the mini window survived with its contents, and it
> worries me.

Why does it worry you?  You've asked Emacs to create a frame, and a
frame by default has a mini-window.  Right?

> Could it be that the last frame isn't actually deleted from the Emacs
> daemon when clicking on its close button?

I think indeed that's what happens, because otherwise clicking there
would have shut down Emacs -- which it doesn't in the daemon case.

> This is the sort of thing I would like to be able to read about in the
> Elisp manual

You expect the ELisp manual to describe the internals to this detail?
That's stuff for comments in the code (adding which will be very
welcome), not for the ELisp reference.

> along with basic questions like "How can one test whether one is in
> an emacsclient session rather than an ordinary Emacs?".

This seems to be a matter of improving indexing: see the variable
mode-line-client and how it is computed.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Fri, Mar 19, 2021 at 14:33:20 +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Mar 2021 11:40:52 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > > What about answering questions about unsaved buffers, running processes
> > > > > ...  in such a situation?  I never use emacsclient so I have no idea how
> > > > > this should behave in practice.

> > > > I don't use emacsclient either.  But questions about unsaved buffers
> > > > seem to prevent Emacs terminating until they get answered.  The same for
> > > > running processes (at least, for gdb).

> > > Are we shutting down Emacs, or are we returning to a headless daemon
> > > state?

> > Returning to a headless daemon state.

> Then I think there's no need to ask those questions at all.  Emacs is
> not going away, so it's okay to leave unsaved edits in the session
> that continues to run.

Yes, I think that's right.

> > When I now try Miha's recipe:
> >    (In last frame of emacsclient:)
> >    M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
> >    C-x C-f foo
> >    Close the frame by clicking on its close button
> >    <Wait the remainder of the 10 seconds>

> > , the new frame comes up _with_ the minibuffer visible.  I don't
> > understand how the mini window survived with its contents, and it
> > worries me.

> Why does it worry you?  You've asked Emacs to create a frame, and a
> frame by default has a mini-window.  Right?

I understand it a lot better now.  The new mini-window gets the
minibuffers only because I had minibuffer-follows-selected-frame set to
t.  With either of the other values, the minibuffers remain on the old
inaccessible frame.  This is not good.

> > Could it be that the last frame isn't actually deleted from the Emacs
> > daemon when clicking on its close button?

> I think indeed that's what happens, because otherwise clicking there
> would have shut down Emacs -- which it doesn't in the daemon case.

Yes, this is the case.  I would dearly like to find a way of determining
if this last frame is still visible, or iconified, or whatever, as
opposed to inaccessible.  The old frame in the above recipe was a -nw
frame, effectively a TTY, and `frame-visible-p' returns t for it, even
though it is not even displayable (it's containing shell has gone).

> > This is the sort of thing I would like to be able to read about in the
> > Elisp manual

> You expect the ELisp manual to describe the internals to this detail?
> That's stuff for comments in the code (adding which will be very
> welcome), not for the ELisp reference.

Hmm.  There is effectively nothing about the effect of Emacs as a daemon
in Elisp.

> > along with basic questions like "How can one test whether one is in
> > an emacsclient session rather than an ordinary Emacs?".

> This seems to be a matter of improving indexing: see the variable
> mode-line-client and how it is computed.

OK, thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 19 Mar 2021 15:35:13 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > , the new frame comes up _with_ the minibuffer visible.  I don't
> > > understand how the mini window survived with its contents, and it
> > > worries me.
> 
> > Why does it worry you?  You've asked Emacs to create a frame, and a
> > frame by default has a mini-window.  Right?
> 
> I understand it a lot better now.  The new mini-window gets the
> minibuffers only because I had minibuffer-follows-selected-frame set to
> t.  With either of the other values, the minibuffers remain on the old
> inaccessible frame.  This is not good.

Can't you move them from those inaccessible frames to this one?

> > > Could it be that the last frame isn't actually deleted from the Emacs
> > > daemon when clicking on its close button?
> 
> > I think indeed that's what happens, because otherwise clicking there
> > would have shut down Emacs -- which it doesn't in the daemon case.
> 
> Yes, this is the case.  I would dearly like to find a way of determining
> if this last frame is still visible, or iconified, or whatever, as
> opposed to inaccessible.

I think this is the initial frame that exists in every Emacs session
when it starts, except that in the daemon we don't delete it.  It's a
non-GUI frame which exists just to keep code that expects some frame
to exist happy.

> The old frame in the above recipe was a -nw frame, effectively a
> TTY, and `frame-visible-p' returns t for it, even though it is not
> even displayable (it's containing shell has gone).

We don't have a means of knowing whether a TTY frame is displayed, it
conceptually always is.

> Hmm.  There is effectively nothing about the effect of Emacs as a daemon
> in Elisp.

There's nothing special about that, just some implementation details.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Fri, Mar 19, 2021 at 17:59:45 +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Mar 2021 15:35:13 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > , the new frame comes up _with_ the minibuffer visible.  I don't
> > > > understand how the mini window survived with its contents, and it
> > > > worries me.

> > > Why does it worry you?  You've asked Emacs to create a frame, and a
> > > frame by default has a mini-window.  Right?

> > I understand it a lot better now.  The new mini-window gets the
> > minibuffers only because I had minibuffer-follows-selected-frame set to
> > t.  With either of the other values, the minibuffers remain on the old
> > inaccessible frame.  This is not good.

> Can't you move them from those inaccessible frames to this one?

The actual moving of the minibuffers isn't the problem ....

> > > > Could it be that the last frame isn't actually deleted from the Emacs
> > > > daemon when clicking on its close button?

> > > I think indeed that's what happens, because otherwise clicking there
> > > would have shut down Emacs -- which it doesn't in the daemon case.

> > Yes, this is the case.  I would dearly like to find a way of determining
> > if this last frame is still visible, or iconified, or whatever, as
> > opposed to inaccessible.

> I think this is the initial frame that exists in every Emacs session
> when it starts, except that in the daemon we don't delete it.  It's a
> non-GUI frame which exists just to keep code that expects some frame
> to exist happy.

This initial frame gets used as a normal frame when one calls

    $ emacsclient foo

for the first time.  It stays in use until one clicks on its close
button (I think this is actually the close button of the containing
xterm).  When a new GUI frame is brought up by

    M-: (run-at-time 10 nil #'make-frame '((window-system . x)))

, the initial frame may or may not have been "closed" by clicking its
close button.  I think you're telling me that it's not possible to
distinguish these two cases.  If so, that's surely a defect in Emacs.

> > The old frame in the above recipe was a -nw frame, effectively a
> > TTY, and `frame-visible-p' returns t for it, even though it is not
> > even displayable (it's containing shell has gone).

> We don't have a means of knowing whether a TTY frame is displayed, it
> conceptually always is.

Perhaps we should create some means of knowing this?  Maybe in
handle-delete-frame, where Emacs has determined there is only one frame
left, before calling save-buffers-kill-emacs we could mark the last
frame's f->visible to "not visible".  Or maybe set up a special non-zero
dummy value for f->terminal.  Or something like that.

> > Hmm.  There is effectively nothing about the effect of Emacs as a daemon
> > in Elisp.

> There's nothing special about that, just some implementation details.

OK.  I'm not sure I agree, but it's not really a big point.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 20 Mar 2021 10:28:26 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I think this is the initial frame that exists in every Emacs session
> > when it starts, except that in the daemon we don't delete it.  It's a
> > non-GUI frame which exists just to keep code that expects some frame
> > to exist happy.
> 
> This initial frame gets used as a normal frame when one calls
> 
>     $ emacsclient foo
> 
> for the first time.

Are you sure?  ISTR that we create a new frame on the terminal from
which emacsclient was invoked.  The initial frame is never used except
at startup and when the daemon should do something while it has no
clients.

> It stays in use until one clicks on its close
> button (I think this is actually the close button of the containing
> xterm).  When a new GUI frame is brought up by
> 
>     M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
> 
> , the initial frame may or may not have been "closed" by clicking its
> close button.  I think you're telling me that it's not possible to
> distinguish these two cases.  If so, that's surely a defect in Emacs.

No, I'm saying that the initial frame is never deleted.  At least
that's my recollection.

> > We don't have a means of knowing whether a TTY frame is displayed, it
> > conceptually always is.
> 
> Perhaps we should create some means of knowing this?  Maybe in
> handle-delete-frame, where Emacs has determined there is only one frame
> left, before calling save-buffers-kill-emacs we could mark the last
> frame's f->visible to "not visible".

You mean, for a frame that is about to be deleted anyway? what purpose
would that serve?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sat, Mar 20, 2021 at 12:49:05 +0200, Eli Zaretskii wrote:
> > Date: Sat, 20 Mar 2021 10:28:26 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I think this is the initial frame that exists in every Emacs session
> > > when it starts, except that in the daemon we don't delete it.  It's a
> > > non-GUI frame which exists just to keep code that expects some frame
> > > to exist happy.

> > This initial frame gets used as a normal frame when one calls

> >     $ emacsclient foo

> > for the first time.

> Are you sure?  ISTR that we create a new frame on the terminal from
> which emacsclient was invoked.  The initial frame is never used except
> at startup and when the daemon should do something while it has no
> clients.

Apologies, I was wrong.  On the first emacsclient call, a second frame
gets created.  The initial frame is marked in some way so that, e.g., C-x
5 o doesn't see it.

> > It stays in use until one clicks on its close
> > button (I think this is actually the close button of the containing
> > xterm).  When a new GUI frame is brought up by

> >     M-: (run-at-time 10 nil #'make-frame '((window-system . x)))

> > , the initial frame may or may not have been "closed" by clicking its
> > close button.  I think you're telling me that it's not possible to
> > distinguish these two cases.  If so, that's surely a defect in Emacs.

> No, I'm saying that the initial frame is never deleted.  At least
> that's my recollection.

So, when a new frame is created (possibly with emacsclient), and there
are now exactly two frames, we want to copy any minibuffers from the
other frame to the new one when that other frame is the initial frame.

I still can't find a way of identifying the initial frame for sure - it
lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
lacks a 'client frame parameter, but so do ordinary frames when Emacs is
started normally and M-x server-start invoked.

Would it, perhaps, be useful to add another frame parameter
'initial-frame to identify this frame?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Miha Rihtaršič]

Alan Mackenzie <acm@muc.de> writes:

>> No, I'm saying that the initial frame is never deleted.  At least
>> that's my recollection.
>
> So, when a new frame is created (possibly with emacsclient), and there
> are now exactly two frames, we want to copy any minibuffers from the
> other frame to the new one when that other frame is the initial frame.

Just giving a heads up that trouble may arise when moving a minibuffer
from one terminal to another (from tty to X for example).
This is judging from the following comment that I stumbled upon when
reading function `server-goto-toplevel':

;; We're inside a minibuffer already, so if the emacs-client is trying
;; to open a frame on a new display, we might end up with an unusable
;; frame because input from that display will be blocked (until exiting
;; the minibuffer).  Better exit this minibuffer right away.

`emacsclient ~/foo' causes a throw to top-level in most cases before
spawning a new frame to avoid some trouble, but I'm not sure if this
trouble applies for our case.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> Just giving a heads up that trouble may arise when moving a minibuffer
> from one terminal to another (from tty to X for example).

Actually that comment from server.el is not about the difficulty of
moving minibuffers but about the problem caused by the lack of minibuffer
movement: if a minibuffer is active in terminal 1, then Emacs is in
a special mode where input from other terminals is ignored, so an
emacsclient opening a frame on a new terminal will display a "dead"
frame (in the sense that it doesn't respond to user input until the
minibuffer in terminal 1 is exited).

Alan's recent changes could actually be used to improve that behavior of
server.el by moving the active minibuffer(s) to the new frame instead of
aborting those minibuffers.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Miha.

On Sat, Mar 20, 2021 at 13:49:19 +0100, Miha Rihtaršič wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> No, I'm saying that the initial frame is never deleted.  At least
> >> that's my recollection.

> > So, when a new frame is created (possibly with emacsclient), and there
> > are now exactly two frames, we want to copy any minibuffers from the
> > other frame to the new one when that other frame is the initial frame.

> Just giving a heads up that trouble may arise when moving a minibuffer
> from one terminal to another (from tty to X for example).
> This is judging from the following comment that I stumbled upon when
> reading function `server-goto-toplevel':

Thanks.

> ;; We're inside a minibuffer already, so if the emacs-client is trying
> ;; to open a frame on a new display, we might end up with an unusable
> ;; frame because input from that display will be blocked (until exiting
> ;; the minibuffer).  Better exit this minibuffer right away.

That looks like a bug which ought to be fixed, but I've no idea where to
start looking for the problem.

> `emacsclient ~/foo' causes a throw to top-level in most cases before
> spawning a new frame to avoid some trouble, but I'm not sure if this
> trouble applies for our case.

When starting emacsclient, I've seen minibuffers being preserved, but I
think I've also seen them being aborted.  By trouble, I think you mean
that described in the comment above.

On a slightly different note, do you see any reason not to commit the
latest state of src/minibuf.c etc., as amended by my patch from
Wednesday?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sun, 21 Mar 2021 10:30:39 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > ;; We're inside a minibuffer already, so if the emacs-client is trying
> > ;; to open a frame on a new display, we might end up with an unusable
> > ;; frame because input from that display will be blocked (until exiting
> > ;; the minibuffer).  Better exit this minibuffer right away.
> 
> That looks like a bug which ought to be fixed, but I've no idea where to
> start looking for the problem.

It's a "feature" we only allow a single frame to be in the "input"
state at any given time.

> > `emacsclient ~/foo' causes a throw to top-level in most cases before
> > spawning a new frame to avoid some trouble, but I'm not sure if this
> > trouble applies for our case.
> 
> When starting emacsclient, I've seen minibuffers being preserved, but I
> think I've also seen them being aborted.  By trouble, I think you mean
> that described in the comment above.

I confess that I don't have a clear idea of what is the problem you
are trying to solve in the context of this discussion.  Why do you
want to "move" the minibuffer when emacsclient starts a new frame (or
is it when it closes a frame?), and what does "move" mean in this
context?

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sun, 21 Mar 2021 12:38:34 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> 
> > Date: Sun, 21 Mar 2021 10:30:39 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > 
> > > ;; We're inside a minibuffer already, so if the emacs-client is trying
> > > ;; to open a frame on a new display, we might end up with an unusable
> > > ;; frame because input from that display will be blocked (until exiting
> > > ;; the minibuffer).  Better exit this minibuffer right away.
> > 
> > That looks like a bug which ought to be fixed, but I've no idea where to
> > start looking for the problem.
> 
> It's a "feature" we only allow a single frame to be in the "input"
> state at any given time.

Sorry, my sloppy wording made this misleading.  Instead of "frame"
please read "display" or "terminal".

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

[ "frame" replaced by "terminal" where appropriate ]

Hello, Eli.

On Sun, Mar 21, 2021 at 12:38:34 +0200, Eli Zaretskii wrote:
> > Date: Sun, 21 Mar 2021 10:30:39 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org

> > > ;; We're inside a minibuffer already, so if the emacs-client is trying
> > > ;; to open a frame on a new display, we might end up with an unusable
> > > ;; frame because input from that display will be blocked (until exiting
> > > ;; the minibuffer).  Better exit this minibuffer right away.

> > That looks like a bug which ought to be fixed, but I've no idea where to
> > start looking for the problem.

> It's a "feature" we only allow a single terminal to be in the "input"
> state at any given time.

Er, OK.  There surely must be good reasons for this.

> > > `emacsclient ~/foo' causes a throw to top-level in most cases before
> > > spawning a new frame to avoid some trouble, but I'm not sure if this
> > > trouble applies for our case.

> > When starting emacsclient, I've seen minibuffers being preserved, but I
> > think I've also seen them being aborted.  By trouble, I think you mean
> > that described in the comment above.

> I confess that I don't have a clear idea of what is the problem you
> are trying to solve in the context of this discussion.  Why do you
> want to "move" the minibuffer when emacsclient starts a new frame (or
> is it when it closes a frame?), and what does "move" mean in this
> context?

The following description includes things which aren't yet committed.

"Move" means to move the minibuffer from frame F1 to frame F2, as for
example, C-x 5 o requires when minibuffer-follows-selected-frame is t
(the default).  When enable-recursive-minibuffers is t, there can be a
"stack" of minibuffers on a frame.  The entire stack gets moved.  The top
minibuffer in the stack is at f->minibuffer_window, any lower elements
are stored in w->prev_buffers, where w is XWINDOW (f->minibuffer_window).

It is also required to move minibuffers when the frame containing them
gets deleted.  Otherwise the minibuffers would continue to be active, yet
be inaccessible from any frame - this would be undesirable.

When the (second) last frame in a --daemon Emacs gets deleted, any
minibuffers it contains get moved to the initial frame.  When calling
emacsclient opens a new frame, these minibuffers need to be moved onto
that new frame (or else be aborted, somehow).

The problem I'm trying to solve here is to understand what happens when
emacsclient opens a frame on a different terminal from where emacs
--daemon was started, when there are active minibuffers on the original
terminal.  What would be nice would be for these minibuffers to be moved
onto the new frame (when minibuffer-follows-selected-frame is t) or left
on the other non-initial frame (otherwise).  It appears, from Miha's
observation yesterday, that any active minibuffers would get aborted in
this case, to prevent the old frame blocking the new one.

It may well be that further work in this area isn't worthwhile - just how
often is somebody going to create a frame in a different terminal whilst
a minibuffer is active, anyway?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> The problem I'm trying to solve here is to understand what happens when
> emacsclient opens a frame on a different terminal from where emacs
> --daemon was started, when there are active minibuffers on the original
> terminal.  What would be nice would be for these minibuffers to be moved
> onto the new frame (when minibuffer-follows-selected-frame is t) or left
> on the other non-initial frame (otherwise).

Leaving them on the other non-initial frame is OK if the new frame is on
the same display.  If it is on another display it can be a problem
because that other display may be inaccessible to the user at
that moment.

That's why I added `server-goto-toplevel`.

> It appears, from Miha's observation yesterday, that any active
> minibuffers would get aborted in this case, to prevent the old frame
> blocking the new one.

Of course, if you could move the active minibuffers to the new frame
(when minibuffer-follows-selected-frame is t), then we could change
`server-goto-toplevel` so as not to abort them.

> It may well be that further work in this area isn't worthwhile - just how
> often is somebody going to create a frame in a different terminal whilst
> a minibuffer is active, anyway?

I implemented `server-goto-toplevel` because it happened to me quite
a few times ;-)


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sun, 21 Mar 2021 14:49:56 +0000
> Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > It's a "feature" we only allow a single terminal to be in the "input"
> > state at any given time.
> 
> Er, OK.  There surely must be good reasons for this.

The "good reasons" are that we are unable to handle input from two or
more keyboards: they will mix up into a single garbled stream of input
events.  That's because there's only one channel through which Emacs
reads input -- the single event queue we have in keyboard.c.

> The following description includes things which aren't yet committed.
> 
> "Move" means to move the minibuffer from frame F1 to frame F2, as for
> example, C-x 5 o requires when minibuffer-follows-selected-frame is t
> (the default).  When enable-recursive-minibuffers is t, there can be a
> "stack" of minibuffers on a frame.  The entire stack gets moved.  The top
> minibuffer in the stack is at f->minibuffer_window, any lower elements
> are stored in w->prev_buffers, where w is XWINDOW (f->minibuffer_window).
> 
> It is also required to move minibuffers when the frame containing them
> gets deleted.  Otherwise the minibuffers would continue to be active, yet
> be inaccessible from any frame - this would be undesirable.
> 
> When the (second) last frame in a --daemon Emacs gets deleted, any
> minibuffers it contains get moved to the initial frame.  When calling
> emacsclient opens a new frame, these minibuffers need to be moved onto
> that new frame (or else be aborted, somehow).

AFAIU, this just means copying the data that describes the stack of
the minibuffers, is that right?  If so, what is left on the frame that
is the source of that: a single empty minibuffer? or the entire
original stack? or something else?

> The problem I'm trying to solve here is to understand what happens when
> emacsclient opens a frame on a different terminal from where emacs
> --daemon was started, when there are active minibuffers on the original
> terminal.  What would be nice would be for these minibuffers to be moved
> onto the new frame (when minibuffer-follows-selected-frame is t) or left
> on the other non-initial frame (otherwise).  It appears, from Miha's
> observation yesterday, that any active minibuffers would get aborted in
> this case, to prevent the old frame blocking the new one.

And what's wrong with aborting the active minibuffer in this case?
isn't that what the user wants?

Re: Stop frames stealing eachothers' minibuffers!

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem I'm trying to solve here is to understand what happens when
>> emacsclient opens a frame on a different terminal from where emacs
>> --daemon was started, when there are active minibuffers on the original
>> terminal.  What would be nice would be for these minibuffers to be moved
>> onto the new frame (when minibuffer-follows-selected-frame is t) or left
>> on the other non-initial frame (otherwise).  It appears, from Miha's
>> observation yesterday, that any active minibuffers would get aborted in
>> this case, to prevent the old frame blocking the new one.
>
> And what's wrong with aborting the active minibuffer in this case?
> isn't that what the user wants?

I see two use cases here.  

1) I've purposefully killed that last active frame.  In this case any
   remaining open minibuffers are probably a mistake.

2) My connection to a remote machine went down, taking my last frame
   with it.  I reconnect and I might want my minibuffer state back.

I'm personally of the opinion that just aborting the minibuffers is good
enough.  Minibuffers should not generally be long-lived with state
anyway.  Under almost all circumstances, I believe any lost minibuffer
state should be recoverable manually.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sun, Mar 21, 2021 at 17:43:02 +0200, Eli Zaretskii wrote:
> > Date: Sun, 21 Mar 2021 14:49:56 +0000
> > Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > It's a "feature" we only allow a single terminal to be in the "input"
> > > state at any given time.

> > Er, OK.  There surely must be good reasons for this.

> The "good reasons" are that we are unable to handle input from two or
> more keyboards: they will mix up into a single garbled stream of input
> events.  That's because there's only one channel through which Emacs
> reads input -- the single event queue we have in keyboard.c.

Thanks, that's very clear.

> > The following description includes things which aren't yet committed.

> > "Move" means to move the minibuffer from frame F1 to frame F2, as for
> > example, C-x 5 o requires when minibuffer-follows-selected-frame is t
> > (the default).  When enable-recursive-minibuffers is t, there can be a
> > "stack" of minibuffers on a frame.  The entire stack gets moved.  The top
> > minibuffer in the stack is at f->minibuffer_window, any lower elements
> > are stored in w->prev_buffers, where w is XWINDOW (f->minibuffer_window).

> > It is also required to move minibuffers when the frame containing them
> > gets deleted.  Otherwise the minibuffers would continue to be active, yet
> > be inaccessible from any frame - this would be undesirable.

> > When the (second) last frame in a --daemon Emacs gets deleted, any
> > minibuffers it contains get moved to the initial frame.  When calling
> > emacsclient opens a new frame, these minibuffers need to be moved onto
> > that new frame (or else be aborted, somehow).

> AFAIU, this just means copying the data that describes the stack of
> the minibuffers, is that right?

Not quite: if there're also minibuffers in the destination frame (with
minibuffer-follows-selected-frame set to nil), the two minibuffer stacks
get combined in the destination.

> If so, what is left on the frame that is the source of that: a single
> empty minibuffer? or the entire original stack? or something else?

What is left on the source frame is a single minibuffer, " *Minibuf-0*",
which functions as the null minibuffer.

> > The problem I'm trying to solve here is to understand what happens when
> > emacsclient opens a frame on a different terminal from where emacs
> > --daemon was started, when there are active minibuffers on the original
> > terminal.  What would be nice would be for these minibuffers to be moved
> > onto the new frame (when minibuffer-follows-selected-frame is t) or left
> > on the other non-initial frame (otherwise).  It appears, from Miha's
> > observation yesterday, that any active minibuffers would get aborted in
> > this case, to prevent the old frame blocking the new one.

> And what's wrong with aborting the active minibuffer in this case?

I don't think there's all that much wrong with aborting it.  It is a
little inconsistent with creating a new emacsclient frame on the same
terminal - here, any existing minibuffers survive.

> isn't that what the user wants?

I honestly don't know.  But as long as the code ends up doing something
consistent and reasonable (and this aborting the minibuffers _is_
reasonable), I don't think it's worth spending too much time on.  Given
how there's just one keyboard input stream, it would be a LOT of work to
make that one input stream per terminal.  We surely don't really need
this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 20 Mar 2021 12:24:55 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> So, when a new frame is created (possibly with emacsclient), and there
> are now exactly two frames, we want to copy any minibuffers from the
> other frame to the new one when that other frame is the initial frame.
> 
> I still can't find a way of identifying the initial frame for sure - it
> lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
> lacks a 'client frame parameter, but so do ordinary frames when Emacs is
> started normally and M-x server-start invoked.
> 
> Would it, perhaps, be useful to add another frame parameter
> 'initial-frame to identify this frame?

Can you tell how you are trying to "identify this frame"?  I'm afraid
I don't see what is your difficulties in this regard.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sat, Mar 20, 2021 at 14:50:19 +0200, Eli Zaretskii wrote:
> > Date: Sat, 20 Mar 2021 12:24:55 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > So, when a new frame is created (possibly with emacsclient), and there
> > are now exactly two frames, we want to copy any minibuffers from the
> > other frame to the new one when that other frame is the initial frame.

> > I still can't find a way of identifying the initial frame for sure - it
> > lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
> > lacks a 'client frame parameter, but so do ordinary frames when Emacs is
> > started normally and M-x server-start invoked.

> > Would it, perhaps, be useful to add another frame parameter
> > 'initial-frame to identify this frame?

> Can you tell how you are trying to "identify this frame"?  I'm afraid
> I don't see what is your difficulties in this regard.

The problem is that I can't come up with any way to identify the initial
frame reliably.  I can't see how to write

    bool initial_frame_p (struct frame *f) { .... }

That's why I suggested a new frame property.

Do you know of any means to identify this frame?  If so, please tell me
about it!  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> I still can't find a way of identifying the initial frame for sure - it
> lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
> lacks a 'client frame parameter, but so do ordinary frames when Emacs is
> started normally and M-x server-start invoked.

xdisp.c uses

    FRAME_INITIAL_P (SELECTED_FRAME ())


-- Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 20 Mar 2021 09:55:02 -0400
> Cc: rudalics@gmx.at, Eli Zaretskii <eliz@gnu.org>, jakanakaevangeli@chiru.no,
>  emacs-devel@gnu.org
> 
> > I still can't find a way of identifying the initial frame for sure - it
> > lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
> > lacks a 'client frame parameter, but so do ordinary frames when Emacs is
> > started normally and M-x server-start invoked.
> 
> xdisp.c uses
> 
>     FRAME_INITIAL_P (SELECTED_FRAME ())

Right.  Just use a frame pointer argument instead of SELECTED_FRAME(),
i.e.

   struct frame *f;
   ...
   if (FRAME_INITIAL_P (f))
     ...

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

On Sat, Mar 20, 2021 at 09:55:02 -0400, Stefan Monnier wrote:
> > I still can't find a way of identifying the initial frame for sure - it
> > lacks a 'display frame parameter, but so do ordinary frames on a tty.  It
> > lacks a 'client frame parameter, but so do ordinary frames when Emacs is
> > started normally and M-x server-start invoked.

> xdisp.c uses

>     FRAME_INITIAL_P (SELECTED_FRAME ())

Thanks, that's exactly what I need.

> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Miha Rihtaršič]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Miha.

Hello

> Yes.  Sorry about these.  This time around, I've tried to be more
> careful and done more testing myself - hence me taking a few days longer
> than I have up till now.  I've found and corrected another ~two bugs
> myself.
>
>> 1)
>> C-x C-f on frame A
>> select frame B
>> select frame A
>> Minibuffer is moved to B, but not back to A.
>
>> 2)
>> Have two frames open
>> open a minibuffer on a frame
>> close this frame
>> The other frame does have the miniwindow selected, but the
>> minibuffer isn't shown in it.
>
> I think I've corrected these two, now.
>
> Here's another patch, this time to be applied on top of the last patch.
> [...]
> do you see any reason not to commit this?

Sorry for the late reply. During my testing I didn't encounter any new
problems. Thanks.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Miha.

On Sun, Mar 21, 2021 at 16:44:53 +0100, Miha Rihtaršič wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > Here's another patch, this time to be applied on top of the last patch.
> > [...]
> > do you see any reason not to commit this?

> Sorry for the late reply. During my testing I didn't encounter any new
> problems. Thanks.

Many thanks for the testing!  I've now committed the patches to savannah.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> > Do you have a bug#nb for it?
> 
> Nice try.

Always with the snarky sarcasm, hostility, and ad
hominem, eh Eli?

It's really not necessary - or helpful, you know.  

Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Emacs.

In recent versions of master (and, I believe the emacs-27 branch) frames
steal eachothers' minibuffers.

By this I mean:
(i) Have two frames open displaying buffers.
(ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
(iii) Move to F2.
(iv) Do C-x 8 RET <enter some character>.

F1's minibuffer is now on F2.  This is bad.

Seeing as how a minibuffer often has a strong association with its frame
(e.g., C-x C-f opens a buffer in the same frame it was invoked from),
this shifting of minibuffers from one frame to another is confusing.

The following patch is a first attempt at fixing this.  Note that it
adds no code, it merely takes away code which was hindering the desired
operation, and simplifies minibuf.c appreciably.  I might well have
missed subtle points in this proposed change.

It has also changed (?improved) the error handling behaviour somewhat.
In the above scenario, after applying the patch:
(v) in F2 do M-x.

This errors with "Command attempted to use minibuffer while in
minibuffer", yet no longers aborts the command which has opened the
(first) minibuffer.  Personally, I think this is less confusing and
potentially less annoying than the current behaviour.

Comments?



diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..10e58cc86b 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -76,37 +76,13 @@ choose_minibuf_frame (void)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object buffer;
-
       /* I don't think that any frames may validly have a null minibuffer
 	 window anymore.  */
       if (NILP (sf->minibuffer_window))
 	emacs_abort ();
 
-      /* Under X, we come here with minibuf_window being the
-	 minibuffer window of the unused termcap window created in
-	 init_window_once.  That window doesn't have a buffer.  */
-      buffer = XWINDOW (minibuf_window)->contents;
-      if (BUFFERP (buffer))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
       minibuf_window = sf->minibuffer_window;
     }
-
-  /* Make sure no other frame has a minibuffer as its selected window,
-     because the text would not be displayed in it, and that would be
-     confusing.  Only allow the selected frame to do this,
-     and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
-
-    FOR_EACH_FRAME (tail, frame)
-      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-	  && !(EQ (frame, selected_frame)
-	       && minibuf_level > 0))
-	Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
-  }
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,
@@ -362,9 +338,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histstring;
   Lisp_Object histval;
 
-  Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
-
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
@@ -416,11 +389,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object str
 	= build_string ("Command attempted to use minibuffer while in minibuffer");
-      if (EQ (selected_window, minibuf_window))
-	Fsignal (Quser_error, (list1 (str)));
-      else
-	/* If we're in another window, cancel the minibuffer that's active.  */
-	Fthrow (Qexit, str);
+      Fsignal (Quser_error, (list1 (str)));
     }
 
   if ((noninteractive
@@ -566,23 +535,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
-     Set them to point to ` *Minibuf-0*', which is always empty.  */
-  empty_minibuf = get_minibuffer (0);
-
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Tue, 13 Oct 2020 19:02:55 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Seeing as how a minibuffer often has a strong association with its frame
> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
> this shifting of minibuffers from one frame to another is confusing.

Is it?  It makes sure the minibuffer is on the selected frame, which
is natural in many/most use cases.  Forcing the user to go back to a
non-selected frame _is_ IMO confusing and inconvenient, at least in
the usual cases.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Tue, Oct 13, 2020 at 22:20:15 +0300, Eli Zaretskii wrote:
> > Date: Tue, 13 Oct 2020 19:02:55 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Seeing as how a minibuffer often has a strong association with its frame
> > (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
> > this shifting of minibuffers from one frame to another is confusing.

> Is it?

It is (or was) to me.  Seeing it for the first time, a user wouldn't
know whether the C-x C-f would open the buffer in the current frame or
the one she issued the command from.

> It makes sure the minibuffer is on the selected frame, which is
> natural in many/most use cases.

It only does this sometimes.  If the command using the minibuffer is
given on frame F1, and the selected frame becomes F2, the minibuffer
sometimes moves, sometimes doesn't, depending on what the user does.
For example, C-s in F2 doesn't usually move the minibuffer, but it will
if you use C-x 8 RET.  This is inconsistent.

> Forcing the user to go back to a non-selected frame _is_ IMO confusing
> and inconvenient, at least in the usual cases.

I don't find it so.  The frame you complete a minibuffer command in
should be the one you started it from.  IMNSHO.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> If the command using the minibuffer is given on frame F1, and the 
> selected frame becomes F2, the minibuffer sometimes moves, sometimes 
> doesn't, depending on what the user does. For example, C-s in F2 doesn't 
> usually move the minibuffer, but it will if you use C-x 8 RET.  This is 
> inconsistent.
>

You are confusing two things here: the minibuffer (for interactive use) 
and the echo area (for messages).  C-s uses the echo area, C-x C-f and C-x 
8 RET use the minibuffer.

I agree with you on one thing: C-x 8 RET should raise a "Command attempted 
to use minibuffer while in minibuffer" error in this case (when 
enable-recursive-minibuffers is nil, which is its default value).  I'm not 
sure why it doesn't.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Tue, Oct 13, 2020 at 20:25:04 +0000, Gregory Heytings wrote:

> > If the command using the minibuffer is given on frame F1, and the
> > selected frame becomes F2, the minibuffer sometimes moves, sometimes
> > doesn't, depending on what the user does. For example, C-s in F2
> > doesn't usually move the minibuffer, but it will if you use C-x 8
> > RET.  This is inconsistent.

> You are confusing two things here: the minibuffer (for interactive use)
> and the echo area (for messages).  C-s uses the echo area, C-x C-f and
> C-x 8 RET use the minibuffer.

Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
usually C-s will not suck in an active minibuffer, but it will if you
have to type foreign characters into your search string.  This is
inconsistent.

> I agree with you on one thing: C-x 8 RET should raise a "Command attempted 
> to use minibuffer while in minibuffer" error in this case .....

You do not agree with me.  ;-)  C-x 8 RET is essentially a command using
recursive minibuffers.  Otherwise, how could you type in a foreign
character while using C-x C-f?  To make C-x 8 RET sometimes recursive,
other times not, would be too complicated.

> .... (when enable-recursive-minibuffers is nil, which is its default
> value).  I'm not sure why it doesn't.

See above.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> You do not agree with me.  ;-)  C-x 8 RET is essentially a command using
> recursive minibuffers.  Otherwise, how could you type in a foreign
> character while using C-x C-f?  To make C-x 8 RET sometimes recursive,
> other times not, would be too complicated.

Yes, `C-x 8 RET' is bound in `isearch-mode-map' to
`isearch-char-by-name', which, like `M-e', uses
`with-isearch-suspended' to temporarily read a
character with the minibuffer.

That's done with `read-char-by-name', which, yes,
binds `enable-recursive-minibuffers' to t.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Tue, 13 Oct 2020 20:44:08 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > If the command using the minibuffer is given on frame F1, and the
> > > selected frame becomes F2, the minibuffer sometimes moves, sometimes
> > > doesn't, depending on what the user does. For example, C-s in F2
> > > doesn't usually move the minibuffer, but it will if you use C-x 8
> > > RET.  This is inconsistent.
> 
> > You are confusing two things here: the minibuffer (for interactive use)
> > and the echo area (for messages).  C-s uses the echo area, C-x C-f and
> > C-x 8 RET use the minibuffer.
> 
> Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
> usually C-s will not suck in an active minibuffer, but it will if you
> have to type foreign characters into your search string.  This is
> inconsistent.

So maybe we should fix this inconsistency, not disable the switch to
the selected frame where that is useful and expected?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 17:34:56 +0300, Eli Zaretskii wrote:
> > Date: Tue, 13 Oct 2020 20:44:08 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > If the command using the minibuffer is given on frame F1, and the
> > > > selected frame becomes F2, the minibuffer sometimes moves, sometimes
> > > > doesn't, depending on what the user does. For example, C-s in F2
> > > > doesn't usually move the minibuffer, but it will if you use C-x 8
> > > > RET.  This is inconsistent.

> > > You are confusing two things here: the minibuffer (for interactive use)
> > > and the echo area (for messages).  C-s uses the echo area, C-x C-f and
> > > C-x 8 RET use the minibuffer.

> > Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
> > usually C-s will not suck in an active minibuffer, but it will if you
> > have to type foreign characters into your search string.  This is
> > inconsistent.

> So maybe we should fix this inconsistency, not disable the switch to
> the selected frame where that is useful and expected?

Well, my patch _does_ fix the inconsistency, by tying each minibuffer
absolutely to the frame it acts on.  It never occurred to me, until a
few days ago, that anybody might find that strategy strange or awkward.

Otherwise, to fix this inconsistency in Isearch (when there's a
minibuffer open in another frame), we must either always pull the
minibuffer into the Isearch frame, or never.

I favour the "never" option of course, but going with "always", the
logical endpoint is surely that an open minibuffer will always be
displayed on the currently selected frame.  It is only slightly more
extreme to display that minibuffer on _every_ frame.

That would be consistent, but I don't think I would like it very much.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 16:02:40 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
> > > usually C-s will not suck in an active minibuffer, but it will if you
> > > have to type foreign characters into your search string.  This is
> > > inconsistent.
> 
> > So maybe we should fix this inconsistency, not disable the switch to
> > the selected frame where that is useful and expected?
> 
> Well, my patch _does_ fix the inconsistency, by tying each minibuffer
> absolutely to the frame it acts on.  It never occurred to me, until a
> few days ago, that anybody might find that strategy strange or awkward.

To me, consistent behavior would be to switch to the mini-window of
the selected frame.

So if we cannot reconcile our preferences, maybe we should have a user
option to decide which behavior to choose.

> Otherwise, to fix this inconsistency in Isearch (when there's a
> minibuffer open in another frame), we must either always pull the
> minibuffer into the Isearch frame, or never.

I don't think I follow: Isearch doesn't use the minibuffer.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 19:14:35 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 16:02:40 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
> > > > usually C-s will not suck in an active minibuffer, but it will if you
> > > > have to type foreign characters into your search string.  This is
> > > > inconsistent.

> > > So maybe we should fix this inconsistency, not disable the switch to
> > > the selected frame where that is useful and expected?

> > Well, my patch _does_ fix the inconsistency, by tying each minibuffer
> > absolutely to the frame it acts on.  It never occurred to me, until a
> > few days ago, that anybody might find that strategy strange or awkward.

> To me, consistent behavior would be to switch to the mini-window of
> the selected frame.

I'm not quite sure what a mini-window is.  Does it mean the window within
which the minibuffer is displayed?  As in max-mini-window-height?

> So if we cannot reconcile our preferences, maybe we should have a user
> option to decide which behavior to choose.

Perhaps.  If we can formulate the two (or several) options in a
non-confusing way.  This is a fairly arcane matter.

> > Otherwise, to fix this inconsistency in Isearch (when there's a
> > minibuffer open in another frame), we must either always pull the
> > minibuffer into the Isearch frame, or never.

> I don't think I follow: Isearch doesn't use the minibuffer.

My apologies for being unclear.  I was thinking about what happens after
the Isearch is over.  Currently the minibuffer is pulled in if the
Isearch has used the minibuffer for any reason.  With my patch, this
would never happen after an Isearch.

What I meant was that with the "always" variation, after an Isearch, an
open minibuffer would always be pulled over from another frame.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 16:35:34 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > To me, consistent behavior would be to switch to the mini-window of
> > the selected frame.
> 
> I'm not quite sure what a mini-window is.  Does it mean the window within
> which the minibuffer is displayed?  As in max-mini-window-height?

The mini-window is the small window at the bottom of the frame which
is used to display the echo area and the minibuffer.

> My apologies for being unclear.  I was thinking about what happens after
> the Isearch is over.  Currently the minibuffer is pulled in if the
> Isearch has used the minibuffer for any reason.  With my patch, this
> would never happen after an Isearch.
> 
> What I meant was that with the "always" variation, after an Isearch, an
> open minibuffer would always be pulled over from another frame.

Would you please describe the recipe to try, and then describe how you
would like to change the current behavior in that recipe?  I feel that
I don't really understand what you are trying to say (e.g., what does
"minibuffer is pulled in" mean?).

Thanks.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 20:05:36 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 16:35:34 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > To me, consistent behavior would be to switch to the mini-window of
> > > the selected frame.

> > I'm not quite sure what a mini-window is.  Does it mean the window within
> > which the minibuffer is displayed?  As in max-mini-window-height?

> The mini-window is the small window at the bottom of the frame which
> is used to display the echo area and the minibuffer.

Thanks.

> > My apologies for being unclear.  I was thinking about what happens after
> > the Isearch is over.  Currently the minibuffer is pulled in if the
> > Isearch has used the minibuffer for any reason.  With my patch, this
> > would never happen after an Isearch.

> > What I meant was that with the "always" variation, after an Isearch, an
> > open minibuffer would always be pulled over from another frame.

> Would you please describe the recipe to try, and then describe how you
> would like to change the current behavior in that recipe?  I feel that
> I don't really understand what you are trying to say (e.g., what does
> "minibuffer is pulled in" mean?).

Calling the frames F1 and F2:

(i) On F1, C-x b  ; Leaves a minibuffer open.
(ii) Move to F2.
(iii) C-s foo RET

On the current master, and with my patch, the minibuffer is still on F1.
With my "always" variation, the minibuffer would now be on F2 (or,
possibly on all frames).

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Starting again from a vanilla state:
(iv) On F1, C-x b ; Leaves a minibuffer open.
(v) Move to F2.
(vi) C-s foo ; Leaves an Isearch active.
(vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
the search string.
(viii) RET ; Terminates Isearch.

On the current master, the minibuffer has been moved to F2.  With my
patch, it would still be on F1.  With the "always" variation it would be
on F2 (or, possibly on all frames).

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

The current master seems to me to be inconsistent, in that whether the
minibuffer moves from F1 to F2 depends on whether the Isearch used a
(recursive) minibuffer.

With my patch, a minibuffer would remain on the frame it was opened on,
no matter what.

With the "always" variation, a minibuffer would always be on the
currently selected frame; selecting a frame, no matter how, would cause
any current minibuffer to move to that frame.

Thus, I would suggest the following new option (written here as defvar
rather than defcustom for ease of writing):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defvar minibuffer-follows-frame 'hybrid
  "How a minibuffer moves on selecting a different frame.
It takes one of the following values:
nil: Minibuffers remain on the frame they were opened on.
t: A minibuffers is moved onto the newly selected frame.
The symbol `hybrid': A minibuffer is moved on onto the current frame when
a recursive minibuffer opened on this frame terminates.

`hybrid' corresponds with the standard behavior from Emacs 27 and earlier."
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I think you are proposing the equivalent of (eq minibuffer-follows-frame
t), but I'm not sure.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 18:45:23 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Calling the frames F1 and F2:
> 
> (i) On F1, C-x b  ; Leaves a minibuffer open.
> (ii) Move to F2.
> (iii) C-s foo RET
> 
> On the current master, and with my patch, the minibuffer is still on F1.
> With my "always" variation, the minibuffer would now be on F2 (or,
> possibly on all frames).
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> Starting again from a vanilla state:
> (iv) On F1, C-x b ; Leaves a minibuffer open.
> (v) Move to F2.
> (vi) C-s foo ; Leaves an Isearch active.
> (vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
> the search string.
> (viii) RET ; Terminates Isearch.
> 
> On the current master, the minibuffer has been moved to F2.  With my
> patch, it would still be on F1.  With the "always" variation it would be
> on F2 (or, possibly on all frames).

You should try this with the emacs-27 branch, because Gregory's patch
installed there (and will be soon merged to master) changes the
behavior quite a bit.

> The current master seems to me to be inconsistent, in that whether the
> minibuffer moves from F1 to F2 depends on whether the Isearch used a
> (recursive) minibuffer.

AFAICT, this no longer happens.

> With my patch, a minibuffer would remain on the frame it was opened on,
> no matter what.

That's a separate issue, I believe.  I'm not sure I like the behavior
you suggest.  If the user switched to a different frame, why should
the minibuffer prompt stay on the non-selected frame?

> (defvar minibuffer-follows-frame 'hybrid
>   "How a minibuffer moves on selecting a different frame.
> It takes one of the following values:
> nil: Minibuffers remain on the frame they were opened on.
> t: A minibuffers is moved onto the newly selected frame.
> The symbol `hybrid': A minibuffer is moved on onto the current frame when
> a recursive minibuffer opened on this frame terminates.
> 
> `hybrid' corresponds with the standard behavior from Emacs 27 and earlier."

I think 'hybrid' is no longer needed (and makes little sense as useful
behavior to me).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 21:58:35 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 18:45:23 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Calling the frames F1 and F2:

[ .... ]

> > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> > Starting again from a vanilla state:
> > (iv) On F1, C-x b ; Leaves a minibuffer open.
> > (v) Move to F2.
> > (vi) C-s foo ; Leaves an Isearch active.
> > (vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
> > the search string.
> > (viii) RET ; Terminates Isearch.

> > On the current master, the minibuffer has been moved to F2.  With my
> > patch, it would still be on F1.  With the "always" variation it would be
> > on F2 (or, possibly on all frames).

> You should try this with the emacs-27 branch, because Gregory's patch
> installed there (and will be soon merged to master) changes the
> behavior quite a bit.

I've just tried it.  The behaviour is indeed that which I noted above -
the minibuffer moves to F2 if and only if a minibuffer has been used in
Isearch.

> > The current master seems to me to be inconsistent, in that whether the
> > minibuffer moves from F1 to F2 depends on whether the Isearch used a
> > (recursive) minibuffer.

> AFAICT, this no longer happens.

Oh, but it does.

> > With my patch, a minibuffer would remain on the frame it was opened on,
> > no matter what.

> That's a separate issue, I believe.  I'm not sure I like the behavior
> you suggest.  If the user switched to a different frame, why should
> the minibuffer prompt stay on the non-selected frame?

Because the action which the minibuffer will invoke usually takes place
in that now non-selected frame.  I feel a bit of a jolt when I hit RET in
F2, but the effect (of switch-to-buffer) takes place in F1.  This applies
to C-x C-f, C-x C-w, C-x b, M-x imenu, .....

> > (defvar minibuffer-follows-frame 'hybrid
> >   "How a minibuffer moves on selecting a different frame.
> > It takes one of the following values:
> > nil: Minibuffers remain on the frame they were opened on.
> > t: A minibuffers is moved onto the newly selected frame.
> > The symbol `hybrid': A minibuffer is moved on onto the current frame when
> > a recursive minibuffer opened on this frame terminates.

> > `hybrid' corresponds with the standard behavior from Emacs 27 and earlier."

> I think 'hybrid' is no longer needed (and makes little sense as useful
> behavior to me).

I agree, but for backward compatibility....  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 19:49:04 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Starting again from a vanilla state:
> > > (iv) On F1, C-x b ; Leaves a minibuffer open.
> > > (v) Move to F2.
> > > (vi) C-s foo ; Leaves an Isearch active.
> > > (vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
> > > the search string.
> > > (viii) RET ; Terminates Isearch.
> 
> > > On the current master, the minibuffer has been moved to F2.  With my
> > > patch, it would still be on F1.  With the "always" variation it would be
> > > on F2 (or, possibly on all frames).
> 
> > You should try this with the emacs-27 branch, because Gregory's patch
> > installed there (and will be soon merged to master) changes the
> > behavior quite a bit.
> 
> I've just tried it.  The behaviour is indeed that which I noted above -
> the minibuffer moves to F2 if and only if a minibuffer has been used in
> Isearch.
> 
> > > The current master seems to me to be inconsistent, in that whether the
> > > minibuffer moves from F1 to F2 depends on whether the Isearch used a
> > > (recursive) minibuffer.
> 
> > AFAICT, this no longer happens.
> 
> Oh, but it does.

We are talking past each other.  This behavior of the current emacs-27
branchlooks correct to me:

  On F1, C-x b
  Move to F2
  C-s foo ; Isearch prompt appears in F2's echo area
  C-x 8 RET <some character> RET; editing is in F2's minibuffer
  RET ; terminates Isearch and leaves the active minibuffer on F2

This behavior is wrong:

  On F1, C-x b
  Move to F2
  C-s foo ; Isearch prompt appears in F2's echo area
  RET ; terminates Isearch and leaves the active minibuffer on F1

The latter is correct, except for the last step: the active minibuffer
should have switched to F2, which is now the selected frame.

> > > With my patch, a minibuffer would remain on the frame it was opened on,
> > > no matter what.
> 
> > That's a separate issue, I believe.  I'm not sure I like the behavior
> > you suggest.  If the user switched to a different frame, why should
> > the minibuffer prompt stay on the non-selected frame?
> 
> Because the action which the minibuffer will invoke usually takes place
> in that now non-selected frame.

There's no guarantee of that.  Moreover, a non-selected frame could
have been iconified or even deleted.  The only sane place to continue
interaction is on the selected frame (and let's leave the use case of
separate minibuffer-only frame aside, okay?).

> I feel a bit of a jolt when I hit RET in F2, but the effect (of
> switch-to-buffer) takes place in F1.  This applies to C-x C-f, C-x
> C-w, C-x b, M-x imenu, .....

Not clear why: you switched to another frame, so continue using that.
If you want to continue using the original frame, switch back there.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 15, 2020 at 16:44:42 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 19:49:04 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Starting again from a vanilla state:
> > > > (iv) On F1, C-x b ; Leaves a minibuffer open.
> > > > (v) Move to F2.
> > > > (vi) C-s foo ; Leaves an Isearch active.
> > > > (vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
> > > > the search string.
> > > > (viii) RET ; Terminates Isearch.

> > > > On the current master, the minibuffer has been moved to F2.  With my
> > > > patch, it would still be on F1.  With the "always" variation it would be
> > > > on F2 (or, possibly on all frames).

> > > You should try this with the emacs-27 branch, because Gregory's patch
> > > installed there (and will be soon merged to master) changes the
> > > behavior quite a bit.

> > I've just tried it.  The behaviour is indeed that which I noted above -
> > the minibuffer moves to F2 if and only if a minibuffer has been used in
> > Isearch.

> > > > The current master seems to me to be inconsistent, in that whether the
> > > > minibuffer moves from F1 to F2 depends on whether the Isearch used a
> > > > (recursive) minibuffer.

> > > AFAICT, this no longer happens.

> > Oh, but it does.

> We are talking past each other.  This behavior of the current emacs-27
> branch looks correct to me:

>   On F1, C-x b
>   Move to F2
>   C-s foo ; Isearch prompt appears in F2's echo area
>   C-x 8 RET <some character> RET; editing is in F2's minibuffer
>   RET ; terminates Isearch and leaves the active minibuffer on F2

> This behavior is wrong:

>   On F1, C-x b
>   Move to F2
>   C-s foo ; Isearch prompt appears in F2's echo area
>   RET ; terminates Isearch and leaves the active minibuffer on F1

> The latter is correct, except for the last step: the active minibuffer
> should have switched to F2, which is now the selected frame.

OK, but I disagree.  We seem to have different mental models of the
minibuffer.  For you, the MB, I think, is what demands immediate
attention, therefore should be on the selected frame.  For me, the MB is
an integral part of the frame on which it was opened.

Is there any chance we could implement an option for this (which has been
mentioned already)?

> > > > With my patch, a minibuffer would remain on the frame it was
> > > > opened on, no matter what.

> > > That's a separate issue, I believe.  I'm not sure I like the
> > > behavior you suggest.  If the user switched to a different frame,
> > > why should the minibuffer prompt stay on the non-selected frame?

> > Because the action which the minibuffer will invoke usually takes place
> > in that now non-selected frame.

> There's no guarantee of that.  Moreover, a non-selected frame could
> have been iconified or even deleted.

Yes, that needs consideration.  An iconified frame could be restored, but
I'm not sure about a deleted frame.  Maybe deleting a frame with an open
MB on it should kill the MB together with the command which is using it.
Or something like that.

> The only sane place to continue interaction is on the selected frame
> ...

I don't think I agree with "only".  We have problems if, say, the frame
is an ediff frame detached from what it's working on.  We have problems
if the frame is too small to hold the MB's prompt.

> .... (and let's leave the use case of separate minibuffer-only frame
> aside, okay?).

Well, we'll need to deal with it at some stage.

> > I feel a bit of a jolt when I hit RET in F2, but the effect (of
> > switch-to-buffer) takes place in F1.  This applies to C-x C-f, C-x
> > C-w, C-x b, M-x imenu, .....

> Not clear why: you switched to another frame, so continue using that.
> If you want to continue using the original frame, switch back there.

The problem happens to me when I've forgotten I've still got an open
minibuffer on the other frame.  This happens, for example, when I need to
search a buffer to find out what to type into, say, M-x imenu, and then
get distracted by whatever.

Anyhow, back to practicalities.  I think we agreed last night (talking
about the "hybrid" option) that the current way of doing things isn't
very good.  I think, but I'm not sure, that you're saying the MB, if
open, should always be present on the currently selected frame and
nowhere else.  If I'm wrong here, could you possibly give a precise
description of when you say the MB should be moved to a different frame.

From a C coding point of view, if nothing special is done, the MB remains
on the frame it was opened on.  (My patch was nothing but the removal of
code which moved the MB.)  The code I removed was somewhat tangled.  If
we're going to implement "MB follows selected frame", we may well want to
add a call to minibuf.c from frame.c.  This will need doing with care.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Thu, 15 Oct 2020 18:01:43 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > The latter is correct, except for the last step: the active minibuffer
> > should have switched to F2, which is now the selected frame.
> 
> OK, but I disagree.  We seem to have different mental models of the
> minibuffer.  For you, the MB, I think, is what demands immediate
> attention, therefore should be on the selected frame.  For me, the MB is
> an integral part of the frame on which it was opened.
> 
> Is there any chance we could implement an option for this (which has been
> mentioned already)?

I'm okay with such an option.  I think I already said that.

> > > I feel a bit of a jolt when I hit RET in F2, but the effect (of
> > > switch-to-buffer) takes place in F1.  This applies to C-x C-f, C-x
> > > C-w, C-x b, M-x imenu, .....
> 
> > Not clear why: you switched to another frame, so continue using that.
> > If you want to continue using the original frame, switch back there.
> 
> The problem happens to me when I've forgotten I've still got an open
> minibuffer on the other frame.

The frame's title will help, as it shows "*Minibuf-1*" or somesuch.

> Anyhow, back to practicalities.  I think we agreed last night (talking
> about the "hybrid" option) that the current way of doing things isn't
> very good.  I think, but I'm not sure, that you're saying the MB, if
> open, should always be present on the currently selected frame and
> nowhere else.  If I'm wrong here, could you possibly give a precise
> description of when you say the MB should be moved to a different frame.

IMO, the minibuffer should _always_ be on the selected frame, unless
it has its own minibuffer-only frame (in which case it is always
there).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 15, 2020 at 21:18:10 +0300, Eli Zaretskii wrote:
> > Date: Thu, 15 Oct 2020 18:01:43 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > The latter is correct, except for the last step: the active minibuffer
> > > should have switched to F2, which is now the selected frame.

> > OK, but I disagree.  We seem to have different mental models of the
> > minibuffer.  For you, the MB, I think, is what demands immediate
> > attention, therefore should be on the selected frame.  For me, the MB is
> > an integral part of the frame on which it was opened.

> > Is there any chance we could implement an option for this (which has been
> > mentioned already)?

> I'm okay with such an option.  I think I already said that.

I too think you did.  There's a proposed patch below.

[ .... ]

> > Anyhow, back to practicalities.  I think we agreed last night (talking
> > about the "hybrid" option) that the current way of doing things isn't
> > very good.  I think, but I'm not sure, that you're saying the MB, if
> > open, should always be present on the currently selected frame and
> > nowhere else.  If I'm wrong here, could you possibly give a precise
> > description of when you say the MB should be moved to a different frame.

> IMO, the minibuffer should _always_ be on the selected frame, unless
> it has its own minibuffer-only frame (in which case it is always
> there).

OK.  I've implemented a new variable `minibuffer-follows-frame' which is
t by default.  For safety's sake, only the default-toplevel-value of this
variable is consulted, to stop funny things happening should it be
dynamically bound or if there might be a buffer local value.

For minibuffer-follows-frame nil, the error "Command attempted to use
minibuffer while in minibuffer" no longer aborts an enclosing minibuffer
command.  There doesn't seem any need or benefit - the enclosing command
can carry on later.

Here's my patch (including amendments to the Emacs manual and a NEWS
entry).  Comments would be most appreciated.



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index 54f046a7e0..0e6d86f3b8 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -69,6 +69,16 @@ Basic Minibuffer
 the minibuffer comes back.  While the minibuffer is in use, Emacs does
 not echo keystrokes.
 
+  Whilst using the minibuffer, you can switch to a different frame,
+perhaps to note text you need to enter (@pxref{Frame Commands}).  By
+default, the minibuffer moves to this new frame.  If you set the user
+option @code{minibuffer-follows-frame} to @code{nil}, then the
+minibuffer stays in the frame where it was opened, and you must switch
+back to that frame in order to complete (or abort) the current
+command.  Note that the effect of the command, when you finally finish
+using the minibuffer, always takes place in the frame where you first
+opened it.
+
 @node Minibuffer File
 @section Minibuffers for File Names
 
diff --git a/etc/NEWS b/etc/NEWS
index f3e3d9a1b6..95b5d7ffd0 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -86,6 +86,19 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 * Changes in Emacs 28.1
 
 +++
+** Switching frames when a minibuffer is active has been rationalized.
+By default, the minibuffer is moved to the newly selected frame.  When
+the current command is continued (by completing the minibuffer
+action), it takes effect in the frame the minibuffer was first opened
+in.  An alternative behavior is available by customizing
+'minibuffer-follows-frame' to nil; here, the minibuffer stays on the
+frame it was first opened on, and you must switch back to this frame
+to continue or abort the current command.  The old (pre 28.1),
+somewhat chaotic behavior is no longer available.
+
++++
+*** A new system for displaying documentation for groups of function is added.
+
 ** New system for displaying documentation for groups of function.
 This can either be used by saying 'M-x shortdoc-display-group' and
 choosing a group, or clicking a button in the *Help* buffers when
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 3fd6ac031c..2120f5a627 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,6 +394,7 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
+             (minibuffer-follows-frame minibuffer boolean "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/src/frame.c b/src/frame.c
index 0b707c2af8..361a7119c5 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1482,6 +1482,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
+  move_minibuffer_onto_frame ();
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index 45353fbef3..5b00252f24 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4336,6 +4336,7 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
+extern void move_minibuffer_onto_frame (void);
 extern Lisp_Object get_minibuffer (EMACS_INT);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..61863af538 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -64,6 +64,12 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 \f
+static bool
+minibuf_follows_frame (void)
+{
+  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_frame));
+}
+
 /* Put minibuf on currently selected frame's minibuffer.
    We do this whenever the user starts a new minibuffer
    or when a minibuffer exits.  */
@@ -76,37 +82,74 @@ choose_minibuf_frame (void)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object buffer;
-
       /* I don't think that any frames may validly have a null minibuffer
 	 window anymore.  */
       if (NILP (sf->minibuffer_window))
 	emacs_abort ();
 
-      /* Under X, we come here with minibuf_window being the
-	 minibuffer window of the unused termcap window created in
-	 init_window_once.  That window doesn't have a buffer.  */
-      buffer = XWINDOW (minibuf_window)->contents;
-      if (BUFFERP (buffer))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
-      minibuf_window = sf->minibuffer_window;
+      if (minibuf_follows_frame ())
+        minibuf_window = sf->minibuffer_window;
+      else if (minibuf_level)
+        {
+          Lisp_Object buffer = get_minibuffer (minibuf_level);
+          Lisp_Object tail, frame;
+
+          FOR_EACH_FRAME (tail, frame)
+            {
+              if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
+                      buffer))
+                {
+                  minibuf_window = XFRAME (frame)->minibuffer_window;
+                  goto after_set;
+                }
+              minibuf_window = sf->minibuffer_window;
+            after_set: ;
+            }
+        }
+      else
+        minibuf_window = Qnil;
     }
 
-  /* Make sure no other frame has a minibuffer as its selected window,
-     because the text would not be displayed in it, and that would be
-     confusing.  Only allow the selected frame to do this,
-     and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
+  if (minibuf_follows_frame ())
+    /* Make sure no other frame has a minibuffer as its selected window,
+       because the text would not be displayed in it, and that would be
+       confusing.  Only allow the selected frame to do this,
+       and that only if the minibuffer is active.  */
+    {
+      Lisp_Object tail, frame;
 
-    FOR_EACH_FRAME (tail, frame)
-      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-	  && !(EQ (frame, selected_frame)
-	       && minibuf_level > 0))
-	Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
-  }
+      FOR_EACH_FRAME (tail, frame)
+        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
+            && !(EQ (frame, selected_frame)
+                 && minibuf_level > 0))
+          Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
+    }
+}
+
+/* If `minibuffer_follows_frame' and we have a minibuffer, move it
+   from its current frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  */
+void move_minibuffer_onto_frame (void)
+{
+  if (!minibuf_level)
+    return;
+  if (!minibuf_follows_frame ())
+    return;
+  if (FRAMEP (selected_frame)
+        && FRAME_LIVE_P (XFRAME (selected_frame))
+        && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+    {
+      struct frame *sf = XFRAME (selected_frame);
+      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
+      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
+
+      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      minibuf_window = sf->minibuffer_window;
+      Fset_frame_selected_window (selected_frame, sf->minibuffer_window,
+                                  Qnil);
+      set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+    }
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,
@@ -362,9 +405,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histstring;
   Lisp_Object histval;
 
-  Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
-
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
@@ -416,11 +456,15 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object str
 	= build_string ("Command attempted to use minibuffer while in minibuffer");
-      if (EQ (selected_window, minibuf_window))
-	Fsignal (Quser_error, (list1 (str)));
+      /* OLD STOUGH, 2020-10-21 */
+      if (!minibuf_follows_frame ()
+          || EQ (selected_window, minibuf_window))
+        Fsignal (Quser_error, (list1 (str)));
       else
-	/* If we're in another window, cancel the minibuffer that's active.  */
-	Fthrow (Qexit, str);
+        /* If we're in another window, cancel the minibuffer that's active.  */
+        Fthrow (Qexit, str);
+      /* END OF OLD STOUGH */
+      Fsignal (Quser_error, (list1 (str)));
     }
 
   if ((noninteractive
@@ -433,6 +477,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
       return unbind_to (count, val);
     }
 
+  minibuf_level++;         /* Before calling choose_minibuf_frame.  */
+
   /* Choose the minibuffer window and frame, and take action on them.  */
 
   /* Prepare for restoring the current buffer since choose_minibuf_frame
@@ -484,7 +530,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     = Fcons (Fthis_command_keys_vector (), minibuf_save_list);
 
   record_unwind_protect_void (read_minibuf_unwind);
-  minibuf_level++;
   /* We are exiting the minibuffer one way or the other, so run the hook.
      It should be run before unwinding the minibuf settings.  Do it
      separately from read_minibuf_unwind because we need to make sure that
@@ -566,23 +611,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
-     Set them to point to ` *Minibuf-0*', which is always empty.  */
-  empty_minibuf = get_minibuffer (0);
-
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -1911,6 +1939,8 @@ syms_of_minibuf (void)
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
 
+  DEFSYM (Qminibuffer_follows_frame,
+          "minibuffer-follows-frame");
   DEFSYM (Qcompletion_ignore_case, "completion-ignore-case");
   DEFSYM (Qminibuffer_default, "minibuffer-default");
   Fset (Qminibuffer_default, Qnil);
@@ -1954,6 +1984,14 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
+  DEFVAR_BOOL ("minibuffer-follows-frame", minibuffer_follows_frame,
+               doc: /* Non-nil means an open minibuffer will move to a newly selected frame.
+Nil means that a minibuffer will appear only in the frame which created it.
+
+Any buffer local or dynamic binding of this variable is ignored.  Only the
+default top level value is used.  */);
+  minibuffer_follows_frame = 1;
+
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,
 	       doc: /* Non-nil means completion ignores case when reading a buffer name.  */);



-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

(Minor)

"Whilst" ->
"While" (Amerenglish)

"the minibuffer moves" ->
"the active minibuffer moves"

"in the frame the minibuffer was first opened in" ->
"in the frame where the minibuffer was first opened"

"on the frame it was first opened on" ->
"in the frame where it was first opened"

(And decide whether a minibuffer - and a window in
general, is in or on a frame.  I don't know what the
convention might be.)

Consider splitting this sentence:

"An alternative behavior is available by customizing
'minibuffer-follows-frame' to nil; here, the
minibuffer stays on the frame it was first opened on,
and you must switch back to this frame to continue or
abort the current command."

Consider removing this gratuitous bit: "somewhat chaotic".

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Drew, 

thanks very much for eyeballing my English text.

On Wed, Oct 21, 2020 at 09:49:36 -0700, Drew Adams wrote:
> (Minor)

> "Whilst" ->
> "While" (Amerenglish)

> "the minibuffer moves" ->
> "the active minibuffer moves"

> "in the frame the minibuffer was first opened in" ->
> "in the frame where the minibuffer was first opened"

> "on the frame it was first opened on" ->
> "in the frame where it was first opened"

> (And decide whether a minibuffer - and a window in
> general, is in or on a frame.  I don't know what the
> convention might be.)

> Consider splitting this sentence:

> "An alternative behavior is available by customizing
> 'minibuffer-follows-frame' to nil; here, the
> minibuffer stays on the frame it was first opened on,
> and you must switch back to this frame to continue or
> abort the current command."

I've made all of these adjustments now, thanks, with a window being "in"
a frame.

> Consider removing this gratuitous bit: "somewhat chaotic".

OK, with the benefit of somebody else looking at it, that's too
pejorative.  I've changed it to "somewhat unsystematic", which I think
is gentler, yet still gives a reason why the former behaviour is no
longer available.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

Thanks Alan,

This looks pretty good to me (haven't tried it yet).
Some comments/questions below,


        Stefan


> @@ -86,6 +86,19 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
>  * Changes in Emacs 28.1
>  
>  +++
> +** Switching frames when a minibuffer is active has been rationalized.
> +By default, the minibuffer is moved to the newly selected frame.  When
> +the current command is continued (by completing the minibuffer
> +action), it takes effect in the frame the minibuffer was first opened
> +in.  An alternative behavior is available by customizing
> +'minibuffer-follows-frame' to nil; here, the minibuffer stays on the
> +frame it was first opened on, and you must switch back to this frame
> +to continue or abort the current command.  The old (pre 28.1),
> +somewhat chaotic behavior is no longer available.
> +
> ++++
> +*** A new system for displaying documentation for groups of function is added.
> +
>  ** New system for displaying documentation for groups of function.
>  This can either be used by saying 'M-x shortdoc-display-group' and
>  choosing a group, or clicking a button in the *Help* buffers when

Looks like a chunk of Lars's shortdoc got brought along.

> +static bool
> +minibuf_follows_frame (void)
> +{
> +  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_frame));
> +}

I can't think of any reason why we'd need to bother with
`Fdefault_toplevel_value` here.  I think the only justification would be
if using some other value could result in a crash or in garbled display,
but AFAICT it could only result (in the worst case) in a vaguely
unexpected behavior where the mininbuffer follows the frame when it
shouldn't or vice versa.

> +          FOR_EACH_FRAME (tail, frame)
> +            {
> +              if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
> +                      buffer))
> +                {
> +                  minibuf_window = XFRAME (frame)->minibuffer_window;
> +                  goto after_set;
> +                }
> +              minibuf_window = sf->minibuffer_window;
> +            after_set: ;
> +            }

I don't understand the:

    minibuf_window = sf->minibuffer_window

Won't this undo the

    minibuf_window = XFRAME (frame)->minibuffer_window;

executed in a previous iteration?
Should this be moved to just before the loop maybe?

> +      /* OLD STOUGH, 2020-10-21 */

Not sure how useful this is.  I'd either remove this comment or replace
it with an actual explanation of what's going on and/or how the code
used to work.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan,

thanks for the review.  In detail:

On Wed, Oct 21, 2020 at 14:32:21 -0400, Stefan Monnier wrote:
> Thanks Alan,

> This looks pretty good to me (haven't tried it yet).
> Some comments/questions below,


>         Stefan


> > @@ -86,6 +86,19 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
> >  * Changes in Emacs 28.1
> >  
> >  +++
> > +** Switching frames when a minibuffer is active has been rationalized.
> > +By default, the minibuffer is moved to the newly selected frame.  When
> > +the current command is continued (by completing the minibuffer
> > +action), it takes effect in the frame the minibuffer was first opened
> > +in.  An alternative behavior is available by customizing
> > +'minibuffer-follows-frame' to nil; here, the minibuffer stays on the
> > +frame it was first opened on, and you must switch back to this frame
> > +to continue or abort the current command.  The old (pre 28.1),
> > +somewhat chaotic behavior is no longer available.
> > +
> > ++++
> > +*** A new system for displaying documentation for groups of function is added.
> > +
> >  ** New system for displaying documentation for groups of function.
> >  This can either be used by saying 'M-x shortdoc-display-group' and
> >  choosing a group, or clicking a button in the *Help* buffers when

> Looks like a chunk of Lars's shortdoc got brought along.

Yes, sorry.  I made a mess of hand editing the result of the merge.  Now
fixed.

> > +static bool
> > +minibuf_follows_frame (void)
> > +{
> > +  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_frame));
> > +}

> I can't think of any reason why we'd need to bother with
> `Fdefault_toplevel_value` here.  I think the only justification would be
> if using some other value could result in a crash or in garbled display,
> but AFAICT it could only result (in the worst case) in a vaguely
> unexpected behavior where the mininbuffer follows the frame when it
> shouldn't or vice versa.

Maybe I'm being a bit too careful, but I've got bad feelings about what
might happen if a buffer local value was different from the canonical
value.  I simply can't picture what might happen, but like you say, it
could well end up with a mini-window being displayed on two frames, and
there being no way to fix that situation.

> > +          FOR_EACH_FRAME (tail, frame)
> > +            {
> > +              if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
> > +                      buffer))
> > +                {
> > +                  minibuf_window = XFRAME (frame)->minibuffer_window;
> > +                  goto after_set;
> > +                }
> > +              minibuf_window = sf->minibuffer_window;
> > +            after_set: ;
> > +            }

> I don't understand the:

>     minibuf_window = sf->minibuffer_window

> Won't this undo the

>     minibuf_window = XFRAME (frame)->minibuffer_window;

> executed in a previous iteration?
> Should this be moved to just before the loop maybe?

Yes, you're right.  I put the "catch-all" setting of minibuf_window
wrongly inside the FOR_EACH_FRAME loop.  Like you say, a neater way of
expressing this is to put the "catch-all" setting before the loop, and
allow it to get overwritten by anything found in the loop.

> > +      /* OLD STOUGH, 2020-10-21 */

> Not sure how useful this is.  I'd either remove this comment or replace
> it with an actual explanation of what's going on and/or how the code
> used to work.

It's my own personal comment for restoring changes, and it should not
have found it's way into the patch.  Sorry.

I'll repost the patch, with your and Drew's corrections separately.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 21, 2020 at 15:19:45 +0000, Alan Mackenzie wrote:
> On Thu, Oct 15, 2020 at 21:18:10 +0300, Eli Zaretskii wrote:
> > > Date: Thu, 15 Oct 2020 18:01:43 +0000
> > > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> OK.  I've implemented a new variable `minibuffer-follows-frame' which is
> t by default.  For safety's sake, only the default-toplevel-value of this
> variable is consulted, to stop funny things happening should it be
> dynamically bound or if there might be a buffer local value.

> For minibuffer-follows-frame nil, the error "Command attempted to use
> minibuffer while in minibuffer" no longer aborts an enclosing minibuffer
> command.  There doesn't seem any need or benefit - the enclosing command
> can carry on later.

> Here's my patch (including amendments to the Emacs manual and a NEWS
> entry).  Comments would be most appreciated.

Here's a corrected version of the patch, incorporating fixes and
suggestions from Stefan and Drew:



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index 54f046a7e0..176d0df14e 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -69,6 +69,16 @@ Basic Minibuffer
 the minibuffer comes back.  While the minibuffer is in use, Emacs does
 not echo keystrokes.
 
+  While using the minibuffer, you can switch to a different frame,
+perhaps to note text you need to enter (@pxref{Frame Commands}).  By
+default, the active minibuffer moves to this new frame.  If you set
+the user option @code{minibuffer-follows-frame} to @code{nil}, then
+the minibuffer stays in the frame where it was opened, and you must
+switch back to that frame in order to complete (or abort) the current
+command.  Note that the effect of the command, when you finally finish
+using the minibuffer, always takes place in the frame where you first
+opened it.
+
 @node Minibuffer File
 @section Minibuffers for File Names
 
diff --git a/etc/NEWS b/etc/NEWS
index f3e3d9a1b6..0aef5ec2f6 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -85,6 +85,17 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 \f
 * Changes in Emacs 28.1
 
++++
+** Switching frames when a minibuffer is active has been rationalized.
+By default, the active minibuffer is moved to the newly selected
+frame.  When the current command is continued (by completing the
+minibuffer action), it takes effect in the frame where the minibuffer
+was first opened.  An alternative behavior is available by customizing
+'minibuffer-follows-frame' to nil.  Here, the minibuffer stays in the
+frame where it was first opened, and you must switch back to this
+frame to continue or abort the current command.  The old (pre Emacs
+28.1) somewhat unsystematic behavior is no longer available.
+
 +++
 ** New system for displaying documentation for groups of function.
 This can either be used by saying 'M-x shortdoc-display-group' and
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 3fd6ac031c..2120f5a627 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,6 +394,7 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
+             (minibuffer-follows-frame minibuffer boolean "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/src/frame.c b/src/frame.c
index 0b707c2af8..361a7119c5 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1482,6 +1482,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
+  move_minibuffer_onto_frame ();
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index 45353fbef3..5b00252f24 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4336,6 +4336,7 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
+extern void move_minibuffer_onto_frame (void);
 extern Lisp_Object get_minibuffer (EMACS_INT);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..8269e251ae 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -64,6 +64,12 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 \f
+static bool
+minibuf_follows_frame (void)
+{
+  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_frame));
+}
+
 /* Put minibuf on currently selected frame's minibuffer.
    We do this whenever the user starts a new minibuffer
    or when a minibuffer exits.  */
@@ -76,37 +82,71 @@ choose_minibuf_frame (void)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object buffer;
-
       /* I don't think that any frames may validly have a null minibuffer
 	 window anymore.  */
       if (NILP (sf->minibuffer_window))
 	emacs_abort ();
 
-      /* Under X, we come here with minibuf_window being the
-	 minibuffer window of the unused termcap window created in
-	 init_window_once.  That window doesn't have a buffer.  */
-      buffer = XWINDOW (minibuf_window)->contents;
-      if (BUFFERP (buffer))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
-      minibuf_window = sf->minibuffer_window;
+      if (minibuf_follows_frame ())
+        minibuf_window = sf->minibuffer_window;
+      else if (minibuf_level)
+        {
+          Lisp_Object buffer = get_minibuffer (minibuf_level);
+          Lisp_Object tail, frame;
+
+          minibuf_window = sf->minibuffer_window;
+          FOR_EACH_FRAME (tail, frame)
+            if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
+                    buffer))
+              {
+                minibuf_window = XFRAME (frame)->minibuffer_window;
+                break;
+              }
+        }
+      else
+        minibuf_window = Qnil;
     }
 
-  /* Make sure no other frame has a minibuffer as its selected window,
-     because the text would not be displayed in it, and that would be
-     confusing.  Only allow the selected frame to do this,
-     and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
+  if (minibuf_follows_frame ())
+    /* Make sure no other frame has a minibuffer as its selected window,
+       because the text would not be displayed in it, and that would be
+       confusing.  Only allow the selected frame to do this,
+       and that only if the minibuffer is active.  */
+    {
+      Lisp_Object tail, frame;
 
-    FOR_EACH_FRAME (tail, frame)
-      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-	  && !(EQ (frame, selected_frame)
-	       && minibuf_level > 0))
-	Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
-  }
+      FOR_EACH_FRAME (tail, frame)
+        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
+            && !(EQ (frame, selected_frame)
+                 && minibuf_level > 0))
+          Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
+    }
+}
+
+/* If `minibuffer_follows_frame' and we have a minibuffer, move it
+   from its current frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  */
+void move_minibuffer_onto_frame (void)
+{
+  if (!minibuf_level)
+    return;
+  if (!minibuf_follows_frame ())
+    return;
+  if (FRAMEP (selected_frame)
+        && FRAME_LIVE_P (XFRAME (selected_frame))
+        && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+    {
+      struct frame *sf = XFRAME (selected_frame);
+      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
+      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
+
+      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      minibuf_window = sf->minibuffer_window;
+      Fset_frame_selected_window (selected_frame, sf->minibuffer_window,
+                                  Qnil);
+      set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+    }
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,
@@ -362,9 +402,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histstring;
   Lisp_Object histval;
 
-  Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
-
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
@@ -416,11 +453,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object str
 	= build_string ("Command attempted to use minibuffer while in minibuffer");
-      if (EQ (selected_window, minibuf_window))
-	Fsignal (Quser_error, (list1 (str)));
+      if (!minibuf_follows_frame ()
+          || EQ (selected_window, minibuf_window))
+        Fsignal (Quser_error, (list1 (str)));
       else
-	/* If we're in another window, cancel the minibuffer that's active.  */
-	Fthrow (Qexit, str);
+        /* If we're in another window, cancel the minibuffer that's active.  */
+        Fthrow (Qexit, str);
     }
 
   if ((noninteractive
@@ -433,6 +471,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
       return unbind_to (count, val);
     }
 
+  minibuf_level++;         /* Before calling choose_minibuf_frame.  */
+
   /* Choose the minibuffer window and frame, and take action on them.  */
 
   /* Prepare for restoring the current buffer since choose_minibuf_frame
@@ -484,7 +524,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     = Fcons (Fthis_command_keys_vector (), minibuf_save_list);
 
   record_unwind_protect_void (read_minibuf_unwind);
-  minibuf_level++;
   /* We are exiting the minibuffer one way or the other, so run the hook.
      It should be run before unwinding the minibuf settings.  Do it
      separately from read_minibuf_unwind because we need to make sure that
@@ -566,23 +605,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
-     Set them to point to ` *Minibuf-0*', which is always empty.  */
-  empty_minibuf = get_minibuffer (0);
-
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -1911,6 +1933,8 @@ syms_of_minibuf (void)
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
 
+  DEFSYM (Qminibuffer_follows_frame,
+          "minibuffer-follows-frame");
   DEFSYM (Qcompletion_ignore_case, "completion-ignore-case");
   DEFSYM (Qminibuffer_default, "minibuffer-default");
   Fset (Qminibuffer_default, Qnil);
@@ -1954,6 +1978,14 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
+  DEFVAR_BOOL ("minibuffer-follows-frame", minibuffer_follows_frame,
+               doc: /* Non-nil means an open minibuffer will move to a newly selected frame.
+Nil means that a minibuffer will appear only in the frame which created it.
+
+Any buffer local or dynamic binding of this variable is ignored.  Only the
+default top level value is used.  */);
+  minibuffer_follows_frame = 1;
+
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,
 	       doc: /* Non-nil means completion ignores case when reading a buffer name.  */);




-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 21 Oct 2020 20:04:38 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Here's a corrected version of the patch, incorporating fixes and
> suggestions from Stefan and Drew:

Thanks, I have a few minor comments:

> +the user option @code{minibuffer-follows-frame} to @code{nil}, then

I'd prefer to name the option minibuffer-follows-selected-frame.

> ++++
> +** Switching frames when a minibuffer is active has been rationalized.

"Rationalized"?  How about

  Minibuffer behavior when selected frame changes can now be controlled.

?

> +By default, the active minibuffer is moved to the newly selected
> +frame.  When the current command is continued (by completing the
> +minibuffer action), it takes effect in the frame where the minibuffer
> +was first opened.  An alternative behavior is available by customizing
> +'minibuffer-follows-frame' to nil.  Here, the minibuffer stays in the
> +frame where it was first opened, and you must switch back to this
> +frame to continue or abort the current command.  The old (pre Emacs
> +28.1) somewhat unsystematic behavior is no longer available.

Can you reword to use less of passive tense here?

I may be missing something: where does this code handles the case of
minibuffer-only frames?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 22, 2020 at 19:14:09 +0300, Eli Zaretskii wrote:
> > Date: Wed, 21 Oct 2020 20:04:38 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Here's a corrected version of the patch, incorporating fixes and
> > suggestions from Stefan and Drew:

And below is a further amended patch.

> Thanks, I have a few minor comments:

> > +the user option @code{minibuffer-follows-frame} to @code{nil}, then

> I'd prefer to name the option minibuffer-follows-selected-frame.

OK.  I've changed it.

> > ++++
> > +** Switching frames when a minibuffer is active has been rationalized.

> "Rationalized"?  How about

>   Minibuffer behavior when selected frame changes can now be controlled.

> ?

What I've put in is

    ** Improved handling of minibuffers on switching frames.

.  How about that?

> > +By default, the active minibuffer is moved to the newly selected
> > +frame.  When the current command is continued (by completing the
> > +minibuffer action), it takes effect in the frame where the minibuffer
> > +was first opened.  An alternative behavior is available by customizing
> > +'minibuffer-follows-frame' to nil.  Here, the minibuffer stays in the
> > +frame where it was first opened, and you must switch back to this
> > +frame to continue or abort the current command.  The old (pre Emacs
> > +28.1) somewhat unsystematic behavior is no longer available.

> Can you reword to use less of passive tense here?

DONE.

> I may be missing something: where does this code handles the case of
> minibuffer-only frames?

The previous version didn't, really, very much.  The current version of
the patch contains quite a few changes, for example to suppress the
display of a ghost cursor in what had been a miniwindow.  I've tested a
little bit with an unusual configuration, 4 frames, of which 2 are
without minibuffers, one is a MB, and the last is a "normal" frame.  I
don't see anything untoward except, perhaps, the action of C-x o when
there are minibuffers open.  But that wasn't entirely predictable on the
unchanged master branch either.

Here's the latest version of the patch.  Comments would be appreciated:



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index 54f046a7e0..ede95a28d4 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -69,6 +69,17 @@ Basic Minibuffer
 the minibuffer comes back.  While the minibuffer is in use, Emacs does
 not echo keystrokes.
 
+@vindex minibuffer-follows-selected-frame
+  While using the minibuffer, you can switch to a different frame,
+perhaps to note text you need to enter (@pxref{Frame Commands}).  By
+default, the active minibuffer moves to this new frame.  If you set
+the user option @code{minibuffer-follows-selected-frame} to
+@code{nil}, then the minibuffer stays in the frame where you opened
+it, and you must switch back to that frame in order to complete (or
+abort) the current command.  Note that the effect of the command, when
+you finally finish using the minibuffer, always takes place in the
+frame where you first opened it.
+
 @node Minibuffer File
 @section Minibuffers for File Names
 
diff --git a/etc/NEWS b/etc/NEWS
index 4cc66aef6b..2489706d89 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -85,6 +85,17 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 \f
 * Changes in Emacs 28.1
 
++++
+** Improved handling of minibuffers on switching frames.
+By default, an active minibuffer now moves to a newly selected frame.
+When continuing the current command (by completing the minibuffer
+action), the effect happens in the frame where the minibuffer was
+first opened.  An alternative behavior is available by customizing
+'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
+stays in the frame where you first opened it, and you must switch back
+to this frame to continue or abort its command.  The old, somewhat
+unsystematic behavior is no longer available.
+
 +++
 ** New system for displaying documentation for groups of function.
 This can either be used by saying 'M-x shortdoc-display-group' and
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 6927b6df6b..04fb1dc6d0 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,6 +394,7 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
+             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5a41e2f30b..9d57a817b2 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -701,7 +701,7 @@ minibuffer-message
 or until the next input event arrives, whichever comes first.
 Enclose MESSAGE in [...] if this is not yet the case.
 If ARGS are provided, then pass MESSAGE through `format-message'."
-  (if (not (minibufferp (current-buffer)))
+  (if (not (minibufferp (current-buffer) t))
       (progn
         (if args
             (apply #'message message args)
diff --git a/src/frame.c b/src/frame.c
index 7c377da445..512aaf5f45 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1482,6 +1482,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
+  move_minibuffer_onto_frame ();
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index 45353fbef3..548eebc9c7 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4336,6 +4336,8 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
+extern void move_minibuffer_onto_frame (void);
+extern bool is_minibuffer (EMACS_INT, Lisp_Object);
 extern Lisp_Object get_minibuffer (EMACS_INT);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..11b5eec236 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -64,6 +64,12 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 \f
+static bool
+minibuf_follows_frame (void)
+{
+  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
 /* Put minibuf on currently selected frame's minibuffer.
    We do this whenever the user starts a new minibuffer
    or when a minibuffer exits.  */
@@ -76,37 +82,73 @@ choose_minibuf_frame (void)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object buffer;
-
       /* I don't think that any frames may validly have a null minibuffer
 	 window anymore.  */
       if (NILP (sf->minibuffer_window))
 	emacs_abort ();
 
-      /* Under X, we come here with minibuf_window being the
-	 minibuffer window of the unused termcap window created in
-	 init_window_once.  That window doesn't have a buffer.  */
-      buffer = XWINDOW (minibuf_window)->contents;
-      if (BUFFERP (buffer))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
-      minibuf_window = sf->minibuffer_window;
+      if (minibuf_follows_frame ())
+        minibuf_window = sf->minibuffer_window;
+      else if (minibuf_level)
+        {
+          Lisp_Object buffer = get_minibuffer (minibuf_level);
+          Lisp_Object tail, frame;
+
+          minibuf_window = sf->minibuffer_window;
+          FOR_EACH_FRAME (tail, frame)
+            if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
+                    buffer))
+              {
+                minibuf_window = XFRAME (frame)->minibuffer_window;
+                break;
+              }
+        }
+      else
+        minibuf_window = Qnil;
     }
 
-  /* Make sure no other frame has a minibuffer as its selected window,
-     because the text would not be displayed in it, and that would be
-     confusing.  Only allow the selected frame to do this,
-     and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
+  if (minibuf_follows_frame ())
+    /* Make sure no other frame has a minibuffer as its selected window,
+       because the text would not be displayed in it, and that would be
+       confusing.  Only allow the selected frame to do this,
+       and that only if the minibuffer is active.  */
+    {
+      Lisp_Object tail, frame;
 
-    FOR_EACH_FRAME (tail, frame)
-      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-	  && !(EQ (frame, selected_frame)
-	       && minibuf_level > 0))
-	Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
-  }
+      FOR_EACH_FRAME (tail, frame)
+        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
+            && !(EQ (frame, selected_frame)
+                 && minibuf_level > 0))
+          Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
+    }
+}
+
+/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
+   from its current frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  */
+void move_minibuffer_onto_frame (void)
+{
+  if (!minibuf_level)
+    return;
+  if (!minibuf_follows_frame ())
+    return;
+  if (FRAMEP (selected_frame)
+      && FRAME_LIVE_P (XFRAME (selected_frame))
+      && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+    {
+      struct frame *sf = XFRAME (selected_frame);
+      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
+      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
+
+      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      minibuf_window = sf->minibuffer_window;
+      if (XWINDOW (minibuf_window)->frame == selected_frame)
+        /* The minibuffer might be on another frame. */
+        Fset_frame_selected_window (selected_frame, sf->minibuffer_window,
+                                    Qnil);
+      set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+    }
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,
@@ -262,13 +304,15 @@ read_minibuf_noninteractive (Lisp_Object prompt, bool expflag,
 }
 \f
 DEFUN ("minibufferp", Fminibufferp,
-       Sminibufferp, 0, 1, 0,
+       Sminibufferp, 0, 2, 0,
        doc: /* Return t if BUFFER is a minibuffer.
 No argument or nil as argument means use current buffer as BUFFER.
-BUFFER can be a buffer or a buffer name.  */)
-  (Lisp_Object buffer)
+BUFFER can be a buffer or a buffer name.  If LIVE is non-nil, then
+t will be returned only if BUFFER is an active minibuffer.  */)
+  (Lisp_Object buffer, Lisp_Object live)
 {
   Lisp_Object tem;
+  EMACS_INT i;
 
   if (NILP (buffer))
     buffer = Fcurrent_buffer ();
@@ -277,8 +321,22 @@ BUFFER can be a buffer or a buffer name.  */)
   else
     CHECK_BUFFER (buffer);
 
-  tem = Fmemq (buffer, Vminibuffer_list);
-  return ! NILP (tem) ? Qt : Qnil;
+  /* tem = Fmemq (buffer, Vminibuffer_list); */
+  /* return (!NILP (tem) && !EQ (tem, Vminibuffer_list)) ? Qt : Qnil; */
+  if (!NILP (live))
+    return !NILP (Fmemq (buffer, Vminibuffer_list)) ? Qt : Qnil;
+  if (EQ (buffer, Fcar (Vminibuffer_list)))
+    /*  *Minibuf-0* is never active.  */
+    return Qnil;
+  tem = Fcdr (Vminibuffer_list);
+  for (i = 1; i <= minibuf_level; i++)
+    {
+      if (NILP (tem))
+        return Qnil;
+      if (EQ (Fcar (tem), buffer))
+        return Qt;
+    }
+  return Qnil;
 }
 
 DEFUN ("minibuffer-prompt-end", Fminibuffer_prompt_end,
@@ -362,9 +420,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histstring;
   Lisp_Object histval;
 
-  Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
-
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
@@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object str
 	= build_string ("Command attempted to use minibuffer while in minibuffer");
-      if (EQ (selected_window, minibuf_window))
-	Fsignal (Quser_error, (list1 (str)));
+      if (!minibuf_follows_frame ()
+          || EQ (selected_window, minibuf_window))
+        Fsignal (Quser_error, (list1 (str)));
       else
-	/* If we're in another window, cancel the minibuffer that's active.  */
-	Fthrow (Qexit, str);
+        /* If we're in another window, cancel the minibuffer that's active.  */
+        Fthrow (Qexit, str);
     }
 
   if ((noninteractive
@@ -433,6 +489,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
       return unbind_to (count, val);
     }
 
+  minibuf_level++;         /* Before calling choose_minibuf_frame.  */
+
   /* Choose the minibuffer window and frame, and take action on them.  */
 
   /* Prepare for restoring the current buffer since choose_minibuf_frame
@@ -484,7 +542,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     = Fcons (Fthis_command_keys_vector (), minibuf_save_list);
 
   record_unwind_protect_void (read_minibuf_unwind);
-  minibuf_level++;
   /* We are exiting the minibuffer one way or the other, so run the hook.
      It should be run before unwinding the minibuf settings.  Do it
      separately from read_minibuf_unwind because we need to make sure that
@@ -566,23 +623,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
-     Set them to point to ` *Minibuf-0*', which is always empty.  */
-  empty_minibuf = get_minibuffer (0);
-
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -714,6 +754,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   return val;
 }
 
+/* Returns whether a Lisp_Object is a particular existing minibuffer.  */
+bool
+is_minibuffer (EMACS_INT depth, Lisp_Object buf)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return
+    !NILP (tail)
+    && EQ (Fcar (tail), buf);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -775,6 +825,7 @@ read_minibuf_unwind (void)
 {
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
+  Lisp_Object future_mini_window;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -809,6 +860,7 @@ read_minibuf_unwind (void)
   if (FRAME_LIVE_P (XFRAME (WINDOW_FRAME (XWINDOW (temp)))))
     minibuf_window = temp;
 #endif
+  future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
@@ -825,7 +877,8 @@ read_minibuf_unwind (void)
 
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
-  if (minibuf_level == 0)
+  if (minibuf_level == 0
+      || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
     resize_mini_window (XWINDOW (window), 0);
 
   /* Deal with frames that should be removed when exiting the
@@ -1911,6 +1964,8 @@ syms_of_minibuf (void)
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
 
+  DEFSYM (Qminibuffer_follows_selected_frame,
+          "minibuffer-follows-selected-frame");
   DEFSYM (Qcompletion_ignore_case, "completion-ignore-case");
   DEFSYM (Qminibuffer_default, "minibuffer-default");
   Fset (Qminibuffer_default, Qnil);
@@ -1954,6 +2009,14 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
+  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* Non-nil means an open minibuffer will move to a newly selected frame.
+Nil means that a minibuffer will appear only in the frame which created it.
+
+Any buffer local or dynamic binding of this variable is ignored.  Only the
+default top level value is used.  */);
+  minibuffer_follows_selected_frame = 1;
+
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,
 	       doc: /* Non-nil means completion ignores case when reading a buffer name.  */);
diff --git a/src/window.c b/src/window.c
index e7433969d2..2eba509727 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2643,8 +2643,10 @@ candidate_window_p (Lisp_Object window, Lisp_Object owindow,
     /* 	To qualify as candidate, it's not sufficient for WINDOW's frame
 	to just share the minibuffer window - it must be active as well
 	(see Bug#24500).  */
-    candidate_p = (EQ (XWINDOW (all_frames)->frame, w->frame)
-		   || EQ (XWINDOW (all_frames)->frame, FRAME_FOCUS_FRAME (f)));
+    candidate_p = ((EQ (XWINDOW (all_frames)->frame, w->frame)
+                    || (EQ (f->minibuffer_window, all_frames)
+                        && EQ (XWINDOW (all_frames)->frame, FRAME_FOCUS_FRAME (f))))
+                   && !is_minibuffer (0, XWINDOW (all_frames)->contents));
   else if (FRAMEP (all_frames))
     candidate_p = EQ (all_frames, w->frame);
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 0e5dffbe00..0dfe34a011 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31220,7 +31220,9 @@ get_window_cursor_type (struct window *w, struct glyph *glyph, int *width,
     {
       *active_cursor = false;
 
-      if (MINI_WINDOW_P (w) && minibuf_level == 0)
+      if (MINI_WINDOW_P (w) &&
+          (minibuf_level == 0
+           || is_minibuffer (0, w->contents)))
 	return NO_CURSOR;
 
       non_selected = true;


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 22:09:17 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
>  DEFUN ("minibufferp", Fminibufferp,
> -       Sminibufferp, 0, 1, 0,
> +       Sminibufferp, 0, 2, 0,
>         doc: /* Return t if BUFFER is a minibuffer.
>  No argument or nil as argument means use current buffer as BUFFER.
> -BUFFER can be a buffer or a buffer name.  */)
> -  (Lisp_Object buffer)
> +BUFFER can be a buffer or a buffer name.  If LIVE is non-nil, then
> +t will be returned only if BUFFER is an active minibuffer.  */)
> +  (Lisp_Object buffer, Lisp_Object live)
>  {

This uses passive tense in the last sentence.

> +  /* tem = Fmemq (buffer, Vminibuffer_list); */
> +  /* return (!NILP (tem) && !EQ (tem, Vminibuffer_list)) ? Qt : Qnil; */

This seems to be a leftover from developing the new code

> +  if (!NILP (live))
> +    return !NILP (Fmemq (buffer, Vminibuffer_list)) ? Qt : Qnil;
> +  if (EQ (buffer, Fcar (Vminibuffer_list)))
> +    /*  *Minibuf-0* is never active.  */
> +    return Qnil;
> +  tem = Fcdr (Vminibuffer_list);
> +  for (i = 1; i <= minibuf_level; i++)
> +    {
> +      if (NILP (tem))
> +        return Qnil;

Why is this test inside the loop?

> @@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>      {
>        Lisp_Object str
>  	= build_string ("Command attempted to use minibuffer while in minibuffer");
> -      if (EQ (selected_window, minibuf_window))
> -	Fsignal (Quser_error, (list1 (str)));
> +      if (!minibuf_follows_frame ()
> +          || EQ (selected_window, minibuf_window))
> +        Fsignal (Quser_error, (list1 (str)));

I don't think I understand this change: what does
minibuffer-follows-selected-frame have to do with recursive minibuffer
usage?  They are two independent features.

> -  /* Empty out the minibuffers of all frames other than the one
> -     where we are going to display one now.
> -     Set them to point to ` *Minibuf-0*', which is always empty.  */
> -  empty_minibuf = get_minibuffer (0);
> -
> -  FOR_EACH_FRAME (dummy, frame)
> -    {
> -      Lisp_Object root_window = Fframe_root_window (frame);
> -      Lisp_Object mini_window = XWINDOW (root_window)->next;
> -
> -      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
> -	  && !NILP (Fwindow_minibuffer_p (mini_window)))
> -	/* Use set_window_buffer instead of Fset_window_buffer (see
> -	   discussion of bug#11984, bug#12025, bug#12026).  */
> -	set_window_buffer (mini_window, empty_minibuf, 0, 0);
> -    }

Does this mean the minibuffers on other frames will now not be emptied?

> +/* Returns whether a Lisp_Object is a particular existing minibuffer.  */

Our style of comments in these cases is like this:

  "Return non-zero if BUF is a particular existing minibuffer."

> +  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
> +               doc: /* Non-nil means an open minibuffer will move to a newly selected frame.

Talking about "moving" and "newly selected" here might come as a
surprise, because the context was not described.  How about

  Non-nil means active minibuffer always displays on the selected frame.

Thanks.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

Thanks for such a quick reply to my last post.

On Sat, Oct 31, 2020 at 09:25:00 +0200, Eli Zaretskii wrote:
> > Date: Fri, 30 Oct 2020 22:09:17 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> >  DEFUN ("minibufferp", Fminibufferp,
> > -       Sminibufferp, 0, 1, 0,
> > +       Sminibufferp, 0, 2, 0,
> >         doc: /* Return t if BUFFER is a minibuffer.
> >  No argument or nil as argument means use current buffer as BUFFER.
> > -BUFFER can be a buffer or a buffer name.  */)
> > -  (Lisp_Object buffer)
> > +BUFFER can be a buffer or a buffer name.  If LIVE is non-nil, then
> > +t will be returned only if BUFFER is an active minibuffer.  */)
> > +  (Lisp_Object buffer, Lisp_Object live)
> >  {

> This uses passive tense in the last sentence.

Fixed.  I've also added a bit to lispref/minibuf.texi for the new
argument.  (See amended patch below).

> > +  /* tem = Fmemq (buffer, Vminibuffer_list); */
> > +  /* return (!NILP (tem) && !EQ (tem, Vminibuffer_list)) ? Qt : Qnil; */

> This seems to be a leftover from developing the new code

Yes, sorry about that.  I've now removed it.

> > +  if (!NILP (live))
> > +    return !NILP (Fmemq (buffer, Vminibuffer_list)) ? Qt : Qnil;
> > +  if (EQ (buffer, Fcar (Vminibuffer_list)))
> > +    /*  *Minibuf-0* is never active.  */
> > +    return Qnil;
> > +  tem = Fcdr (Vminibuffer_list);
> > +  for (i = 1; i <= minibuf_level; i++)
> > +    {
> > +      if (NILP (tem))
> > +        return Qnil;

> Why is this test inside the loop?

What was wrong here was forgetting to (cdr tem) each time through the
loop.  I've fixed that.  I've also removed the test, since it really
isn't needed.

Also in that snippet, the (!NILP (live)) was the wrong way round, and
I've corrected it to (NILP (live)).

> > @@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> >      {
> >        Lisp_Object str
> >  	= build_string ("Command attempted to use minibuffer while in minibuffer");
> > -      if (EQ (selected_window, minibuf_window))
> > -	Fsignal (Quser_error, (list1 (str)));
> > +      if (!minibuf_follows_frame ()
> > +          || EQ (selected_window, minibuf_window))
> > +        Fsignal (Quser_error, (list1 (str)));

> I don't think I understand this change: what does
> minibuffer-follows-selected-frame have to do with recursive minibuffer
> usage?  They are two independent features.

They're not as independent as all that.  The existing logic appeared to
say "if we're in the miniwindow, just abort the current command,
otherwise abort all nested commands.".  Extending that logic to when we
have several miniwindows, we'd (perhaps) get "if we're in _A_ miniwindow
just abort the current command.".

Which, further extended, goes "if we're in ANY window, just abort the
current command.".  I agree, this is an independent feature from the
main one.  But it brings consistency (and, possibly, usability) to this
abort facility.  I can put this back to more or less what it was.  But
why do we abort the whole command stack when there's just a single
error?

> > -  /* Empty out the minibuffers of all frames other than the one
> > -     where we are going to display one now.
> > -     Set them to point to ` *Minibuf-0*', which is always empty.  */
> > -  empty_minibuf = get_minibuffer (0);
> > -
> > -  FOR_EACH_FRAME (dummy, frame)
> > -    {
> > -      Lisp_Object root_window = Fframe_root_window (frame);
> > -      Lisp_Object mini_window = XWINDOW (root_window)->next;
> > -
> > -      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
> > -	  && !NILP (Fwindow_minibuffer_p (mini_window)))
> > -	/* Use set_window_buffer instead of Fset_window_buffer (see
> > -	   discussion of bug#11984, bug#12025, bug#12026).  */
> > -	set_window_buffer (mini_window, empty_minibuf, 0, 0);
> > -    }

> Does this mean the minibuffers on other frames will now not be emptied?

Yes, indeed.  If minibuffer-follows-selected-frame, there'll only be a
single mini-window, which we're about to write into, so there's no point
emptying out a null set of other windows.  If
!minibuffer-follows-selected-frame, we don't want to empty these other
mini-windows.  They're there for when the user eventually comes back to
them.

> > +/* Returns whether a Lisp_Object is a particular existing minibuffer.  */

> Our style of comments in these cases is like this:

>   "Return non-zero if BUF is a particular existing minibuffer."

Fixed.

> > +  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
> > +               doc: /* Non-nil means an open minibuffer will move to a newly selected frame.

> Talking about "moving" and "newly selected" here might come as a
> surprise, because the context was not described.  How about

>   Non-nil means active minibuffer always displays on the selected frame.

OK, I've put that in with a "the" before "active minibuffer", to be
definite we're only talking about the innermost minibuffer.

> Thanks.

OK, here's the amended patch:



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index 54f046a7e0..ede95a28d4 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -69,6 +69,17 @@ Basic Minibuffer
 the minibuffer comes back.  While the minibuffer is in use, Emacs does
 not echo keystrokes.
 
+@vindex minibuffer-follows-selected-frame
+  While using the minibuffer, you can switch to a different frame,
+perhaps to note text you need to enter (@pxref{Frame Commands}).  By
+default, the active minibuffer moves to this new frame.  If you set
+the user option @code{minibuffer-follows-selected-frame} to
+@code{nil}, then the minibuffer stays in the frame where you opened
+it, and you must switch back to that frame in order to complete (or
+abort) the current command.  Note that the effect of the command, when
+you finally finish using the minibuffer, always takes place in the
+frame where you first opened it.
+
 @node Minibuffer File
 @section Minibuffers for File Names
 
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index e5a0233b3c..b6a3434d15 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -2586,10 +2586,12 @@ Recursive Mini
 @node Minibuffer Misc
 @section Minibuffer Miscellany
 
-@defun minibufferp &optional buffer-or-name
+@defun minibufferp &optional buffer-or-name live
 This function returns non-@code{nil} if @var{buffer-or-name} is a
-minibuffer.  If @var{buffer-or-name} is omitted, it tests the current
-buffer.
+minibuffer.  If @var{buffer-or-name} is omitted or @code{nil}, it
+tests the current buffer.  When @var{live} is non-@code{nil}, the
+function returns non-@code{nil} only when @var{buffer-or-name} is an
+active minibuffer.
 @end defun
 
 @defvar minibuffer-setup-hook
diff --git a/etc/NEWS b/etc/NEWS
index 4cc66aef6b..2489706d89 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -85,6 +85,17 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 \f
 * Changes in Emacs 28.1
 
++++
+** Improved handling of minibuffers on switching frames.
+By default, an active minibuffer now moves to a newly selected frame.
+When continuing the current command (by completing the minibuffer
+action), the effect happens in the frame where the minibuffer was
+first opened.  An alternative behavior is available by customizing
+'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
+stays in the frame where you first opened it, and you must switch back
+to this frame to continue or abort its command.  The old, somewhat
+unsystematic behavior is no longer available.
+
 +++
 ** New system for displaying documentation for groups of function.
 This can either be used by saying 'M-x shortdoc-display-group' and
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 6927b6df6b..04fb1dc6d0 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,6 +394,7 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
+             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5a41e2f30b..9d57a817b2 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -701,7 +701,7 @@ minibuffer-message
 or until the next input event arrives, whichever comes first.
 Enclose MESSAGE in [...] if this is not yet the case.
 If ARGS are provided, then pass MESSAGE through `format-message'."
-  (if (not (minibufferp (current-buffer)))
+  (if (not (minibufferp (current-buffer) t))
       (progn
         (if args
             (apply #'message message args)
diff --git a/src/frame.c b/src/frame.c
index 7c377da445..512aaf5f45 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1482,6 +1482,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
 #endif
     internal_last_event_frame = Qnil;
 
+  move_minibuffer_onto_frame ();
   return frame;
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index 45353fbef3..548eebc9c7 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4336,6 +4336,8 @@ extern void clear_regexp_cache (void);
 
 extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
+extern void move_minibuffer_onto_frame (void);
+extern bool is_minibuffer (EMACS_INT, Lisp_Object);
 extern Lisp_Object get_minibuffer (EMACS_INT);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..ff3201b4ae 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -64,6 +64,12 @@ static Lisp_Object minibuf_prompt;
 static ptrdiff_t minibuf_prompt_width;
 
 \f
+static bool
+minibuf_follows_frame (void)
+{
+  return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
 /* Put minibuf on currently selected frame's minibuffer.
    We do this whenever the user starts a new minibuffer
    or when a minibuffer exits.  */
@@ -76,37 +82,72 @@ choose_minibuf_frame (void)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      Lisp_Object buffer;
-
       /* I don't think that any frames may validly have a null minibuffer
 	 window anymore.  */
       if (NILP (sf->minibuffer_window))
 	emacs_abort ();
 
-      /* Under X, we come here with minibuf_window being the
-	 minibuffer window of the unused termcap window created in
-	 init_window_once.  That window doesn't have a buffer.  */
-      buffer = XWINDOW (minibuf_window)->contents;
-      if (BUFFERP (buffer))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
       minibuf_window = sf->minibuffer_window;
+      /* If we've still got another minibuffer open, use its mini-window
+         instead.  */
+      if (minibuf_level && !minibuf_follows_frame ())
+        {
+          Lisp_Object buffer = get_minibuffer (minibuf_level);
+          Lisp_Object tail, frame;
+
+          FOR_EACH_FRAME (tail, frame)
+            if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
+                    buffer))
+              {
+                minibuf_window = XFRAME (frame)->minibuffer_window;
+                break;
+              }
+        }
     }
 
-  /* Make sure no other frame has a minibuffer as its selected window,
-     because the text would not be displayed in it, and that would be
-     confusing.  Only allow the selected frame to do this,
-     and that only if the minibuffer is active.  */
-  {
-    Lisp_Object tail, frame;
+  if (minibuf_follows_frame ())
+    /* Make sure no other frame has a minibuffer as its selected window,
+       because the text would not be displayed in it, and that would be
+       confusing.  Only allow the selected frame to do this,
+       and that only if the minibuffer is active.  */
+    {
+      Lisp_Object tail, frame;
+
+      FOR_EACH_FRAME (tail, frame)
+        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
+            && !(EQ (frame, selected_frame)
+                 && minibuf_level > 0))
+          Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                      Qnil);
+    }
+}
 
-    FOR_EACH_FRAME (tail, frame)
-      if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-	  && !(EQ (frame, selected_frame)
-	       && minibuf_level > 0))
-	Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
-  }
+/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
+   from its current frame to the selected frame.  This function is
+   intended to be called from `do_switch_frame' in frame.c.  */
+void move_minibuffer_onto_frame (void)
+{
+  if (!minibuf_level)
+    return;
+  if (!minibuf_follows_frame ())
+    return;
+  if (FRAMEP (selected_frame)
+      && FRAME_LIVE_P (XFRAME (selected_frame))
+      && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
+    {
+      struct frame *sf = XFRAME (selected_frame);
+      Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
+      struct frame *of = XFRAME (old_frame);
+      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
+
+      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      minibuf_window = sf->minibuffer_window;
+      if (XWINDOW (minibuf_window)->frame == selected_frame)
+        /* The minibuffer might be on another frame. */
+        Fset_frame_selected_window (selected_frame, sf->minibuffer_window,
+                                    Qnil);
+      set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+    }
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,
@@ -262,13 +303,15 @@ read_minibuf_noninteractive (Lisp_Object prompt, bool expflag,
 }
 \f
 DEFUN ("minibufferp", Fminibufferp,
-       Sminibufferp, 0, 1, 0,
+       Sminibufferp, 0, 2, 0,
        doc: /* Return t if BUFFER is a minibuffer.
 No argument or nil as argument means use current buffer as BUFFER.
-BUFFER can be a buffer or a buffer name.  */)
-  (Lisp_Object buffer)
+BUFFER can be a buffer or a buffer name.  If LIVE is non-nil, then
+return t only if BUFFER is an active minibuffer.  */)
+  (Lisp_Object buffer, Lisp_Object live)
 {
   Lisp_Object tem;
+  EMACS_INT i;
 
   if (NILP (buffer))
     buffer = Fcurrent_buffer ();
@@ -277,8 +320,16 @@ BUFFER can be a buffer or a buffer name.  */)
   else
     CHECK_BUFFER (buffer);
 
-  tem = Fmemq (buffer, Vminibuffer_list);
-  return ! NILP (tem) ? Qt : Qnil;
+  if (NILP (live))
+    return !NILP (Fmemq (buffer, Vminibuffer_list)) ? Qt : Qnil;
+  if (EQ (buffer, Fcar (Vminibuffer_list)))
+    /*  *Minibuf-0* is never active.  */
+    return Qnil;
+  tem = Fcdr (Vminibuffer_list);
+  for (i = 1; i <= minibuf_level; i++, tem = Fcdr (tem))
+    if (EQ (Fcar (tem), buffer))
+      return Qt;
+  return Qnil;
 }
 
 DEFUN ("minibuffer-prompt-end", Fminibuffer_prompt_end,
@@ -362,9 +413,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object histstring;
   Lisp_Object histval;
 
-  Lisp_Object empty_minibuf;
-  Lisp_Object dummy, frame;
-
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
@@ -416,11 +464,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object str
 	= build_string ("Command attempted to use minibuffer while in minibuffer");
-      if (EQ (selected_window, minibuf_window))
-	Fsignal (Quser_error, (list1 (str)));
+      if (!minibuf_follows_frame ()
+          || EQ (selected_window, minibuf_window))
+        Fsignal (Quser_error, (list1 (str)));
       else
-	/* If we're in another window, cancel the minibuffer that's active.  */
-	Fthrow (Qexit, str);
+        /* If we're in another window, cancel the minibuffer that's active.  */
+        Fthrow (Qexit, str);
     }
 
   if ((noninteractive
@@ -433,6 +482,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
       return unbind_to (count, val);
     }
 
+  minibuf_level++;         /* Before calling choose_minibuf_frame.  */
+
   /* Choose the minibuffer window and frame, and take action on them.  */
 
   /* Prepare for restoring the current buffer since choose_minibuf_frame
@@ -484,7 +535,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     = Fcons (Fthis_command_keys_vector (), minibuf_save_list);
 
   record_unwind_protect_void (read_minibuf_unwind);
-  minibuf_level++;
   /* We are exiting the minibuffer one way or the other, so run the hook.
      It should be run before unwinding the minibuf settings.  Do it
      separately from read_minibuf_unwind because we need to make sure that
@@ -566,23 +616,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
-     Set them to point to ` *Minibuf-0*', which is always empty.  */
-  empty_minibuf = get_minibuffer (0);
-
-  FOR_EACH_FRAME (dummy, frame)
-    {
-      Lisp_Object root_window = Fframe_root_window (frame);
-      Lisp_Object mini_window = XWINDOW (root_window)->next;
-
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
-    }
-
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -714,6 +747,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   return val;
 }
 
+/* Return true if BUF is a particular existing minibuffer.  */
+bool
+is_minibuffer (EMACS_INT depth, Lisp_Object buf)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return
+    !NILP (tail)
+    && EQ (Fcar (tail), buf);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -775,6 +818,7 @@ read_minibuf_unwind (void)
 {
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
+  Lisp_Object future_mini_window;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -809,6 +853,7 @@ read_minibuf_unwind (void)
   if (FRAME_LIVE_P (XFRAME (WINDOW_FRAME (XWINDOW (temp)))))
     minibuf_window = temp;
 #endif
+  future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
@@ -825,7 +870,8 @@ read_minibuf_unwind (void)
 
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
-  if (minibuf_level == 0)
+  if (minibuf_level == 0
+      || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
     resize_mini_window (XWINDOW (window), 0);
 
   /* Deal with frames that should be removed when exiting the
@@ -1911,6 +1957,8 @@ syms_of_minibuf (void)
   staticpro (&minibuf_prompt);
   staticpro (&minibuf_save_list);
 
+  DEFSYM (Qminibuffer_follows_selected_frame,
+          "minibuffer-follows-selected-frame");
   DEFSYM (Qcompletion_ignore_case, "completion-ignore-case");
   DEFSYM (Qminibuffer_default, "minibuffer-default");
   Fset (Qminibuffer_default, Qnil);
@@ -1954,6 +2002,14 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
+  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+Nil means that a minibuffer will appear only in the frame which created it.
+
+Any buffer local or dynamic binding of this variable is ignored.  Only the
+default top level value is used.  */);
+  minibuffer_follows_selected_frame = 1;
+
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,
 	       doc: /* Non-nil means completion ignores case when reading a buffer name.  */);
diff --git a/src/window.c b/src/window.c
index e7433969d2..2eba509727 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2643,8 +2643,10 @@ candidate_window_p (Lisp_Object window, Lisp_Object owindow,
     /* 	To qualify as candidate, it's not sufficient for WINDOW's frame
 	to just share the minibuffer window - it must be active as well
 	(see Bug#24500).  */
-    candidate_p = (EQ (XWINDOW (all_frames)->frame, w->frame)
-		   || EQ (XWINDOW (all_frames)->frame, FRAME_FOCUS_FRAME (f)));
+    candidate_p = ((EQ (XWINDOW (all_frames)->frame, w->frame)
+                    || (EQ (f->minibuffer_window, all_frames)
+                        && EQ (XWINDOW (all_frames)->frame, FRAME_FOCUS_FRAME (f))))
+                   && !is_minibuffer (0, XWINDOW (all_frames)->contents));
   else if (FRAMEP (all_frames))
     candidate_p = EQ (all_frames, w->frame);
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 0e5dffbe00..0dfe34a011 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31220,7 +31220,9 @@ get_window_cursor_type (struct window *w, struct glyph *glyph, int *width,
     {
       *active_cursor = false;
 
-      if (MINI_WINDOW_P (w) && minibuf_level == 0)
+      if (MINI_WINDOW_P (w) &&
+          (minibuf_level == 0
+           || is_minibuffer (0, w->contents)))
 	return NO_CURSOR;
 
       non_selected = true;


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 16:14:22 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > @@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> > >      {
> > >        Lisp_Object str
> > >  	= build_string ("Command attempted to use minibuffer while in minibuffer");
> > > -      if (EQ (selected_window, minibuf_window))
> > > -	Fsignal (Quser_error, (list1 (str)));
> > > +      if (!minibuf_follows_frame ()
> > > +          || EQ (selected_window, minibuf_window))
> > > +        Fsignal (Quser_error, (list1 (str)));
> 
> > I don't think I understand this change: what does
> > minibuffer-follows-selected-frame have to do with recursive minibuffer
> > usage?  They are two independent features.
> 
> They're not as independent as all that.  The existing logic appeared to
> say "if we're in the miniwindow, just abort the current command,
> otherwise abort all nested commands.".  Extending that logic to when we
> have several miniwindows, we'd (perhaps) get "if we're in _A_ miniwindow
> just abort the current command.".
> 
> Which, further extended, goes "if we're in ANY window, just abort the
> current command.".  I agree, this is an independent feature from the
> main one.  But it brings consistency (and, possibly, usability) to this
> abort facility.  I can put this back to more or less what it was.  But
> why do we abort the whole command stack when there's just a single
> error?

Sorry, you've lost me here.  The existing logic is: if we are in a
minibuffer with minibuf_level > 1, then we throw to top-level, either
by signaling a user-error or silently.  Your change introduced the
call to minibuf_follows_frame into this equation, and I just cannot
understand what business does it have here?  Recursive minibuffers
should be "verboten" regardless of whether the minibuffer follows the
selected frame or not.  What am I missing here?

> > > -  /* Empty out the minibuffers of all frames other than the one
> > > -     where we are going to display one now.
> > > -     Set them to point to ` *Minibuf-0*', which is always empty.  */
> > > -  empty_minibuf = get_minibuffer (0);
> > > -
> > > -  FOR_EACH_FRAME (dummy, frame)
> > > -    {
> > > -      Lisp_Object root_window = Fframe_root_window (frame);
> > > -      Lisp_Object mini_window = XWINDOW (root_window)->next;
> > > -
> > > -      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
> > > -	  && !NILP (Fwindow_minibuffer_p (mini_window)))
> > > -	/* Use set_window_buffer instead of Fset_window_buffer (see
> > > -	   discussion of bug#11984, bug#12025, bug#12026).  */
> > > -	set_window_buffer (mini_window, empty_minibuf, 0, 0);
> > > -    }
> 
> > Does this mean the minibuffers on other frames will now not be emptied?
> 
> Yes, indeed.  If minibuffer-follows-selected-frame, there'll only be a
> single mini-window, which we're about to write into, so there's no point
> emptying out a null set of other windows.

That's the intention, perhaps, but are we really 110% sure this will
happen?  And where's the alternative code which will make sure the
other minibuffers are cleared in this case?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello again, Eli.

On Sat, Oct 31, 2020 at 18:45:19 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 16:14:22 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > @@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> > > >      {
> > > >        Lisp_Object str
> > > >  	= build_string ("Command attempted to use minibuffer while in minibuffer");
> > > > -      if (EQ (selected_window, minibuf_window))
> > > > -	Fsignal (Quser_error, (list1 (str)));
> > > > +      if (!minibuf_follows_frame ()
> > > > +          || EQ (selected_window, minibuf_window))
> > > > +        Fsignal (Quser_error, (list1 (str)));

> > > I don't think I understand this change: what does
> > > minibuffer-follows-selected-frame have to do with recursive minibuffer
> > > usage?  They are two independent features.

> > They're not as independent as all that.  The existing logic appeared to
> > say "if we're in the miniwindow, just abort the current command,
> > otherwise abort all nested commands.".  Extending that logic to when we
> > have several miniwindows, we'd (perhaps) get "if we're in _A_ miniwindow
> > just abort the current command.".

> > Which, further extended, goes "if we're in ANY window, just abort the
> > current command.".  I agree, this is an independent feature from the
> > main one.  But it brings consistency (and, possibly, usability) to this
> > abort facility.  I can put this back to more or less what it was.  But
> > why do we abort the whole command stack when there's just a single
> > error?

> Sorry, you've lost me here.  The existing logic is: if we are in a
> minibuffer with minibuf_level > 1, then we throw to top-level, either
> by signaling a user-error or silently.  Your change introduced the
> call to minibuf_follows_frame into this equation, and I just cannot
> understand what business does it have here?  Recursive minibuffers
> should be "verboten" regardless of whether the minibuffer follows the
> selected frame or not.  What am I missing here?

Maybe I'm not being coherent.  I think it would be better not to abort
the first command when a user accidentally tries to invoke a recursive
minibuffer.  But it's not a big point.

I can't remember very clearly, but I think I made this change early on in
the project because the Fthrow (Qexit, str); left some mini-windows in a
messy state; or something like that.  That doesn't happen any more.

So, maybe I should just remove this hunk from the proposed patch.  It
doesn't seem that important any more.

> > > > -  /* Empty out the minibuffers of all frames other than the one
> > > > -     where we are going to display one now.
> > > > -     Set them to point to ` *Minibuf-0*', which is always empty.  */
> > > > -  empty_minibuf = get_minibuffer (0);
> > > > -
> > > > -  FOR_EACH_FRAME (dummy, frame)
> > > > -    {
> > > > -      Lisp_Object root_window = Fframe_root_window (frame);
> > > > -      Lisp_Object mini_window = XWINDOW (root_window)->next;
> > > > -
> > > > -      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
> > > > -	  && !NILP (Fwindow_minibuffer_p (mini_window)))
> > > > -	/* Use set_window_buffer instead of Fset_window_buffer (see
> > > > -	   discussion of bug#11984, bug#12025, bug#12026).  */
> > > > -	set_window_buffer (mini_window, empty_minibuf, 0, 0);
> > > > -    }

> > > Does this mean the minibuffers on other frames will now not be emptied?

> > Yes, indeed.  If minibuffer-follows-selected-frame, there'll only be a
> > single mini-window, which we're about to write into, so there's no point
> > emptying out a null set of other windows.

> That's the intention, perhaps, but are we really 110% sure this will
> happen?  And where's the alternative code which will make sure the
> other minibuffers are cleared in this case?

Maybe something like edebug invoked from a recursive edit when there's a
minibuffer live.  That could be problematic, perhaps.

How about emptying mini-windows which don't have live minibuffers on
them?  This could be tested by Fminibufferp (b, Qt).  In practice, when
minibuffer-follows-selected-frame this would empty all mini-windows but
the current one, and when !m-f-s-f it would leave intact the mini-windows
we want to be left intact.

To be honest, I think I've been seeing stale messages hanging around in
echo areas, and this emptying might clear them out.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 19:44:19 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I can't remember very clearly, but I think I made this change early on in
> the project because the Fthrow (Qexit, str); left some mini-windows in a
> messy state; or something like that.  That doesn't happen any more.
> 
> So, maybe I should just remove this hunk from the proposed patch.  It
> doesn't seem that important any more.

Fine with me.

> How about emptying mini-windows which don't have live minibuffers on
> them?  This could be tested by Fminibufferp (b, Qt).  In practice, when
> minibuffer-follows-selected-frame this would empty all mini-windows but
> the current one, and when !m-f-s-f it would leave intact the mini-windows
> we want to be left intact.

let me turn the table and ask why this hunk is needed?  What doesn't
work right if this code is left in place?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 31, 2020 at 22:00:09 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 19:44:19 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I can't remember very clearly, but I think I made this change early on in
> > the project because the Fthrow (Qexit, str); left some mini-windows in a
> > messy state; or something like that.  That doesn't happen any more.

> > So, maybe I should just remove this hunk from the proposed patch.  It
> > doesn't seem that important any more.

> Fine with me.

OK, that's done.

> > How about emptying mini-windows which don't have live minibuffers on
> > them?  This could be tested by Fminibufferp (b, Qt).  In practice, when
> > minibuffer-follows-selected-frame this would empty all mini-windows but
> > the current one, and when !m-f-s-f it would leave intact the mini-windows
> > we want to be left intact.

> let me turn the table and ask why this hunk is needed?  What doesn't
> work right if this code is left in place?

Without that hunk (i.e. with the emptying-out code):
(i) emacs -Q
(ii) M-: (setq minibuffer-follows-selected-frame nil)
(iii) C-x 5 2 ; giving two frames.
(iv) C-x b ; leaving a minibuffer open.
(v) C-x 5 o ; move to other frame.

(vi) C-r in ; start an isearch.
(vii) C-x 8 RET ; intending on inserting a non-keyboard character.

At this point, the mini-window in Frame 1 is emptied.  This is bad.
There appears to be no way to get its minibuffer back again.

By contrast, the same sequence of operations without (ii) (with an extra
step:

(v).5 C-x o ; move to the ordinary window.

), the first minibuffer is "protected" on Frame 2 underneath the C-x 8
RET minibuffer.  So, when the isearch is finished, the "Switch to
buffer" minibuffer appears again, and is active.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 20:39:14 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > How about emptying mini-windows which don't have live minibuffers on
> > > them?  This could be tested by Fminibufferp (b, Qt).  In practice, when
> > > minibuffer-follows-selected-frame this would empty all mini-windows but
> > > the current one, and when !m-f-s-f it would leave intact the mini-windows
> > > we want to be left intact.
> 
> > let me turn the table and ask why this hunk is needed?  What doesn't
> > work right if this code is left in place?
> 
> Without that hunk (i.e. with the emptying-out code):
> (i) emacs -Q
> (ii) M-: (setq minibuffer-follows-selected-frame nil)
> (iii) C-x 5 2 ; giving two frames.
> (iv) C-x b ; leaving a minibuffer open.
> (v) C-x 5 o ; move to other frame.
> 
> (vi) C-r in ; start an isearch.
> (vii) C-x 8 RET ; intending on inserting a non-keyboard character.
> 
> At this point, the mini-window in Frame 1 is emptied.  This is bad.

But the same happens with the current master.  So this is no worse
than what we have today.

> By contrast, the same sequence of operations without (ii) (with an extra
> step:
> 
> (v).5 C-x o ; move to the ordinary window.
> 
> ), the first minibuffer is "protected" on Frame 2 underneath the C-x 8
> RET minibuffer.  So, when the isearch is finished, the "Switch to
> buffer" minibuffer appears again, and is active.

Is this with or without removing the code which empties all the other
minibuffers?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sun, Nov 01, 2020 at 20:35:54 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 20:39:14 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > How about emptying mini-windows which don't have live minibuffers
> > > > on them?  This could be tested by Fminibufferp (b, Qt).  In
> > > > practice, when minibuffer-follows-selected-frame this would empty
> > > > all mini-windows but the current one, and when !m-f-s-f it would
> > > > leave intact the mini-windows we want to be left intact.

> > > let me turn the table and ask why this hunk is needed?  What
> > > doesn't work right if this code is left in place?

> > Without that hunk (i.e. with the emptying-out code):
> > (i) emacs -Q
> > (ii) M-: (setq minibuffer-follows-selected-frame nil)
> > (iii) C-x 5 2 ; giving two frames.
> > (iv) C-x b ; leaving a minibuffer open.
> > (v) C-x 5 o ; move to other frame.

> > (vi) C-r in ; start an isearch.
> > (vii) C-x 8 RET ; intending on inserting a non-keyboard character.

> > At this point, the mini-window in Frame 1 is emptied.  This is bad.

> But the same happens with the current master.  So this is no worse than
> what we have today.

It might be no worse (the situations aren't exactly parallel), but I
think the !minibuffer_f_s_frame case should be no worse than the m_f_s_f
case.  We should be aiming to improve things.  The mental model for
!m_f_s_f is that a minibuffer is attached to a frame.  So actions in a
different frame shouldn't affect it.

> > By contrast, the same sequence of operations without (ii) (with an extra
> > step:

> > (v).5 C-x o ; move to the ordinary window.

> > ), the first minibuffer is "protected" on Frame 2 underneath the C-x 8
> > RET minibuffer.  So, when the isearch is finished, the "Switch to
> > buffer" minibuffer appears again, and is active.

> Is this with or without removing the code which empties all the other
> minibuffers?

This is with the emptying code present, exactly as in the previous case.


I propose amending the emptying out code to look like this:

  /* Empty out the minibuffers of all frames, except those frames
     where there is an active minibuffer.
     Set them to point to ` *Minibuf-0*', which is always empty.  */
  empty_minibuf = get_minibuffer (0);

  FOR_EACH_FRAME (dummy, frame)
    {
      Lisp_Object root_window = Fframe_root_window (frame);
      Lisp_Object mini_window = XWINDOW (root_window)->next;
      Lisp_Object buffer;

      if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
          && !NILP (Fwindow_minibuffer_p (mini_window)))
        {
          buffer = XWINDOW (mini_window)->contents;
          if (NILP (Fminibufferp (buffer, Qt)))       <========================
            /* Use set_window_buffer instead of Fset_window_buffer (see
               discussion of bug#11984, bug#12025, bug#12026).  */
            set_window_buffer (mini_window, empty_minibuf, 0, 0);
        }
    }

Here Fminibufferp (with the new argument Qt) tests for an active
minibuffer.  This code appears to work well.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 19:53:13 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
>   /* Empty out the minibuffers of all frames, except those frames
>      where there is an active minibuffer.
>      Set them to point to ` *Minibuf-0*', which is always empty.  */
>   empty_minibuf = get_minibuffer (0);
> 
>   FOR_EACH_FRAME (dummy, frame)
>     {
>       Lisp_Object root_window = Fframe_root_window (frame);
>       Lisp_Object mini_window = XWINDOW (root_window)->next;
>       Lisp_Object buffer;
> 
>       if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
>           && !NILP (Fwindow_minibuffer_p (mini_window)))
>         {
>           buffer = XWINDOW (mini_window)->contents;
>           if (NILP (Fminibufferp (buffer, Qt)))       <========================
>             /* Use set_window_buffer instead of Fset_window_buffer (see
>                discussion of bug#11984, bug#12025, bug#12026).  */
>             set_window_buffer (mini_window, empty_minibuf, 0, 0);
>         }
>     }
> 
> Here Fminibufferp (with the new argument Qt) tests for an active
> minibuffer.  This code appears to work well.

Please just use the guts of Fminibufferp; the tests it does on its
argument are not needed here.  Also, won't this condition catch
*Minibuf-0* as well?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Mon, Nov 02, 2020 at 19:19:18 +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Nov 2020 19:53:13 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> >   /* Empty out the minibuffers of all frames, except those frames
> >      where there is an active minibuffer.
> >      Set them to point to ` *Minibuf-0*', which is always empty.  */
> >   empty_minibuf = get_minibuffer (0);
> > 
> >   FOR_EACH_FRAME (dummy, frame)
> >     {
> >       Lisp_Object root_window = Fframe_root_window (frame);
> >       Lisp_Object mini_window = XWINDOW (root_window)->next;
> >       Lisp_Object buffer;
> > 
> >       if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
> >           && !NILP (Fwindow_minibuffer_p (mini_window)))
> >         {
> >           buffer = XWINDOW (mini_window)->contents;
> >           if (NILP (Fminibufferp (buffer, Qt)))       <========================
> >             /* Use set_window_buffer instead of Fset_window_buffer (see
> >                discussion of bug#11984, bug#12025, bug#12026).  */
> >             set_window_buffer (mini_window, empty_minibuf, 0, 0);
> >         }
> >     }

> > Here Fminibufferp (with the new argument Qt) tests for an active
> > minibuffer.  This code appears to work well.

> Please just use the guts of Fminibufferp; the tests it does on its
> argument are not needed here.

Sorry, I can't follow you, here.  What do you mean by "the guts" of
Fminibufferp?  What things do you mean that the word "just" should
exclude?

> Also, won't this condition catch  *Minibuf-0* as well?

The Qt argument will cause Fminibufferp to return Qnil for all buffers
except  *Minibuf-1*,  *Minibuf-2*,  ...,  *Minibuf-n*, where n is
minibuf-level.  In particular, Qnil is returned for  *Minibuf-0*, so any
mini-window showing  *Minibuf-0* would get emptied.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Mon, 2 Nov 2020 18:51:47 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Please just use the guts of Fminibufferp; the tests it does on its
> > argument are not needed here.
> 
> Sorry, I can't follow you, here.  What do you mean by "the guts" of
> Fminibufferp?  What things do you mean that the word "just" should
> exclude?

I meant to exclude these tests that Fminibufferp does:

  if (NILP (buffer))
    buffer = Fcurrent_buffer ();
  else if (STRINGP (buffer))
    buffer = Fget_buffer (buffer);
  else
    CHECK_BUFFER (buffer);

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Mon, Nov 02, 2020 at 21:19:40 +0200, Eli Zaretskii wrote:
> > Date: Mon, 2 Nov 2020 18:51:47 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de

> > > Please just use the guts of Fminibufferp; the tests it does on its
> > > argument are not needed here.

> > Sorry, I can't follow you, here.  What do you mean by "the guts" of
> > Fminibufferp?  What things do you mean that the word "just" should
> > exclude?

> I meant to exclude these tests that Fminibufferp does:

>   if (NILP (buffer))
>     buffer = Fcurrent_buffer ();
>   else if (STRINGP (buffer))
>     buffer = Fget_buffer (buffer);
>   else
>     CHECK_BUFFER (buffer);

OK, I've extracted a new function `live_minibuffer_p'  from Fminibufferp,
and call that directly from the mini-window emptying code.  (The new
second parameter in Fminibufferp is still needed, since it is used in
minibuffer.el.)

Here's a patch of the subset of changes to minibuf.c which are relevant
to our discussions of the last two or three days.  Perhaps we are close
to the stage when this could be committed to master.



diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..ebc00ae4e4 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -261,15 +302,31 @@ read_minibuf_noninteractive (Lisp_Object prompt, bool expflag,
   return val;
 }
 \f
+/* Return true when BUFFER is an active minibuffer.  */
+static bool
+live_minibuffer_p (Lisp_Object buffer)
+{
+  Lisp_Object tem;
+  EMACS_INT i;
+
+  if (EQ (buffer, Fcar (Vminibuffer_list)))
+    /*  *Minibuf-0* is never active.  */
+    return false;
+  tem = Fcdr (Vminibuffer_list);
+  for (i = 1; i <= minibuf_level; i++, tem = Fcdr (tem))
+    if (EQ (Fcar (tem), buffer))
+      return true;
+  return false;
+}
+
 DEFUN ("minibufferp", Fminibufferp,
-       Sminibufferp, 0, 1, 0,
+       Sminibufferp, 0, 2, 0,
        doc: /* Return t if BUFFER is a minibuffer.
 No argument or nil as argument means use current buffer as BUFFER.
-BUFFER can be a buffer or a buffer name.  */)
-  (Lisp_Object buffer)
+BUFFER can be a buffer or a buffer name.  If LIVE is non-nil, then
+return t only if BUFFER is an active minibuffer.  */)
+  (Lisp_Object buffer, Lisp_Object live)
 {
-  Lisp_Object tem;
-
   if (NILP (buffer))
     buffer = Fcurrent_buffer ();
   else if (STRINGP (buffer))
@@ -277,8 +334,10 @@ BUFFER can be a buffer or a buffer name.  */)
   else
     CHECK_BUFFER (buffer);
 
-  tem = Fmemq (buffer, Vminibuffer_list);
-  return ! NILP (tem) ? Qt : Qnil;
+  return (NILP (live)
+          ? !NILP (Fmemq (buffer, Vminibuffer_list))
+          : live_minibuffer_p (buffer))
+    ? Qt : Qnil;
 }
 
 DEFUN ("minibuffer-prompt-end", Fminibuffer_prompt_end,
@@ -566,8 +626,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   if (minibuf_level == 1 || !EQ (minibuf_window, selected_window))
     minibuf_selected_window = selected_window;
 
-  /* Empty out the minibuffers of all frames other than the one
-     where we are going to display one now.
+  /* Empty out the minibuffers of all frames, except those frames
+     where there is an active minibuffer.
      Set them to point to ` *Minibuf-0*', which is always empty.  */
   empty_minibuf = get_minibuffer (0);
 
@@ -575,12 +635,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
     {
       Lisp_Object root_window = Fframe_root_window (frame);
       Lisp_Object mini_window = XWINDOW (root_window)->next;
+      Lisp_Object buffer;
 
-      if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window)
-	  && !NILP (Fwindow_minibuffer_p (mini_window)))
-	/* Use set_window_buffer instead of Fset_window_buffer (see
-	   discussion of bug#11984, bug#12025, bug#12026).  */
-	set_window_buffer (mini_window, empty_minibuf, 0, 0);
+      if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
+          && !NILP (Fwindow_minibuffer_p (mini_window)))
+        {
+          buffer = XWINDOW (mini_window)->contents;
+          if (!live_minibuffer_p (buffer))
+            /* Use set_window_buffer instead of Fset_window_buffer (see
+               discussion of bug#11984, bug#12025, bug#12026).  */
+            set_window_buffer (mini_window, empty_minibuf, 0, 0);
+        }
     }
 
   /* Display this minibuffer in the proper window.  */


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Tue, 3 Nov 2020 21:08:53 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> OK, I've extracted a new function `live_minibuffer_p'  from Fminibufferp,
> and call that directly from the mini-window emptying code.  (The new
> second parameter in Fminibufferp is still needed, since it is used in
> minibuffer.el.)
> 
> Here's a patch of the subset of changes to minibuf.c which are relevant
> to our discussions of the last two or three days.  Perhaps we are close
> to the stage when this could be committed to master.

Yes, I think so.

> +  if (EQ (buffer, Fcar (Vminibuffer_list)))
> +    /*  *Minibuf-0* is never active.  */
> +    return false;
> +  tem = Fcdr (Vminibuffer_list);
> +  for (i = 1; i <= minibuf_level; i++, tem = Fcdr (tem))
> +    if (EQ (Fcar (tem), buffer))
> +      return true;
> +  return false;

I'm curious: why a loop instead of a call to Fmemq?

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 04, 2020 at 18:47:10 +0200, Eli Zaretskii wrote:
> > Date: Tue, 3 Nov 2020 21:08:53 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > OK, I've extracted a new function `live_minibuffer_p'  from
> > Fminibufferp, and call that directly from the mini-window emptying
> > code.  (The new second parameter in Fminibufferp is still needed,
> > since it is used in minibuffer.el.)

> > Here's a patch of the subset of changes to minibuf.c which are
> > relevant to our discussions of the last two or three days.  Perhaps
> > we are close to the stage when this could be committed to master.

> Yes, I think so.

Maybe I should do that this evening.  WDYT?

> > +  if (EQ (buffer, Fcar (Vminibuffer_list)))
> > +    /*  *Minibuf-0* is never active.  */
> > +    return false;
> > +  tem = Fcdr (Vminibuffer_list);
> > +  for (i = 1; i <= minibuf_level; i++, tem = Fcdr (tem))
> > +    if (EQ (Fcar (tem), buffer))
> > +      return true;
> > +  return false;

> I'm curious: why a loop instead of a call to Fmemq?

Because Vminibuffer_list is a list of all minibuffers which have ever
been active.  When the use of a MB is terminated, the MB stays on the
list (for reuse), and minibuf_level is decremented.

So an Fmemq would need somehow to ignore the end of the Vminibuffer_list.
Just doing a loop in C seems simpler.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Madhu]

* Alan Mackenzie <20201104173954.GA14535@ACM> :
Wrote on Wed, 4 Nov 2020 17:39:54 +0000:
> On Wed, Nov 04, 2020 at 18:47:10 +0200, Eli Zaretskii wrote:
>> > Date: Tue, 3 Nov 2020 21:08:53 +0000
>> > From: Alan Mackenzie <acm@muc.de>
>
>> > OK, I've extracted a new function `live_minibuffer_p'  from
>> > Fminibufferp, and call that directly from the mini-window emptying
>> > code.  (The new second parameter in Fminibufferp is still needed,
>> > since it is used in minibuffer.el.)
[snip]

These patches introduce a regression on "graphical" emacs -

1. emacs -Q

2. M-: (setq pop-up-frames 'graphic-only)

3. M-! g <TAB>

This should pop up a *Completions* buffer in a new frame.

On choosing the completion (via a button1 or by navigating to the
desired point and typing RET) - the frame should be automatically
hidden[1]

This doesn't happen anymore and the completion buffer and frame remain
there taking up focus.


[1] default value for frame-auto-hide-function is #'iconify-frame, but
if your window manager cannot iconify it, set
(setq frame-auto-hide-function #'delete-frame)

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Madhu <enometh@meer.net> writes:

> * Alan Mackenzie <20201104173954.GA14535@ACM> :
> Wrote on Wed, 4 Nov 2020 17:39:54 +0000:
>> On Wed, Nov 04, 2020 at 18:47:10 +0200, Eli Zaretskii wrote:
>>> > Date: Tue, 3 Nov 2020 21:08:53 +0000
>>> > From: Alan Mackenzie <acm@muc.de>
>>
>>> > OK, I've extracted a new function `live_minibuffer_p'  from
>>> > Fminibufferp, and call that directly from the mini-window emptying
>>> > code.  (The new second parameter in Fminibufferp is still needed,
>>> > since it is used in minibuffer.el.)
> [snip]
>
> On choosing the completion (via a button1 or by navigating to the
> desired point and typing RET) - the frame should be automatically
> hidden[1]
>
> This doesn't happen anymore and the completion buffer and frame remain
> there taking up focus.

Take a look at the 'minibuffer-follows-selected-frame' variable.
Setting it to 'nil' will solve your issue.

Alan, is it possible to make 'minibuffer-follows-selected-frame' nil by
default?

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Date: Mon, 09 Nov 2020 22:34:31 +0200
> Cc: emacs-devel@gnu.org
> 
> Alan, is it possible to make 'minibuffer-follows-selected-frame' nil by
> default?

If this is because the other value produces bugs, IMO we should fix
those bugs rather than make them less frequent (and thus harder to
detect) by flipping the default value.

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
>> Date: Mon, 09 Nov 2020 22:34:31 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Alan, is it possible to make 'minibuffer-follows-selected-frame' nil by
>> default?
>
> If this is because the other value produces bugs, IMO we should fix
> those bugs rather than make them less frequent (and thus harder to
> detect) by flipping the default value.

It is not producing bugs for me, but changes behavior.

E.g. in emacs -Q:

1. Evaluate
  (select-frame-set-input-focus
   (make-frame '((minibuffer . only)
                 (left . 1.0))))
2. M-x
3. C-x 5 o

Before minibuffer-follows-selected-frame, the prompt stays in the
minibuffer-only frame.
On recent master, the prompt is moved to other frame leaving
minibuffer-only frame empty.  I can't report this as a bug.  Just
wondering why minibuffer-follows-selected-frame is set to t by default,
potentially changing someone's expected behavior.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

On November 10, 2020 10:08:46 AM GMT+02:00, Andrii Kolomoiets <andreyk.mad@gmail.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> >> Date: Mon, 09 Nov 2020 22:34:31 +0200
> >> Cc: emacs-devel@gnu.org
> >> 
> >> Alan, is it possible to make 'minibuffer-follows-selected-frame'
> nil by
> >> default?
> >
> > If this is because the other value produces bugs, IMO we should fix
> > those bugs rather than make them less frequent (and thus harder to
> > detect) by flipping the default value.
> 
> It is not producing bugs for me, but changes behavior.
> 
> E.g. in emacs -Q:
> 
> 1. Evaluate
>   (select-frame-set-input-focus
>    (make-frame '((minibuffer . only)
>                  (left . 1.0))))
> 2. M-x
> 3. C-x 5 o
> 
> Before minibuffer-follows-selected-frame, the prompt stays in the
> minibuffer-only frame.
> On recent master, the prompt is moved to other frame leaving
> minibuffer-only frame empty.  I can't report this as a bug.  Just
> wondering why minibuffer-follows-selected-frame is set to t by
> default,
> potentially changing someone's expected behavior.

The defaults are selected for the common usage patterns.  It is not clear to me that the test case you presented is common.  But if it is, perhaps we do need to consider changing the default.

Does anyone else think this is common usage, to have a minibuffer-only frame while other frames also have minibuffers?

Alternatively, perhaps minibuffers activated in minibuffer-only frames should behave specially in this regard?

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> Does anyone else think this is common usage, to have a minibuffer-only frame
> while other frames also have minibuffers?

FWIW, I've never seen it in the wild (I've seen mixes of frames with
and without minibuffers, but when there is a minibuffer-only frame
never seen it accompanied with other frames-with-minibuffer, except for
frames on other terminals).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Does anyone else think this is common usage, to have a minibuffer-only frame
>> while other frames also have minibuffers?
>
> FWIW, I've never seen it in the wild (I've seen mixes of frames with
> and without minibuffers, but when there is a minibuffer-only frame
> never seen it accompanied with other frames-with-minibuffer, except for
> frames on other terminals).

I don't sure what the "in the wild" means, but I know at least two
packages that shows minibuffer-only child frame on reading user input:

https://raw.githubusercontent.com/honmaple/emacs-maple-minibuffer/master/maple-minibuffer.el

https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Date: Tue, 10 Nov 2020 19:27:45 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, enometh@meer.net, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> Does anyone else think this is common usage, to have a minibuffer-only frame
> >> while other frames also have minibuffers?
> >
> > FWIW, I've never seen it in the wild (I've seen mixes of frames with
> > and without minibuffers, but when there is a minibuffer-only frame
> > never seen it accompanied with other frames-with-minibuffer, except for
> > frames on other terminals).
> 
> I don't sure what the "in the wild" means, but I know at least two
> packages that shows minibuffer-only child frame on reading user input:

I didn't ask if this was possible, or used, I asked if such usage is
common.  It is clear that we cannot find a default that will fit all
the uses, but we should have the default that works well in common use
cases.

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Eli Zaretskii <eliz@gnu.org> writes:

>>>> Does anyone else think this is common usage, to have a minibuffer-only frame
>>>> while other frames also have minibuffers?
>>>
>>> FWIW, I've never seen it in the wild (I've seen mixes of frames with
>>> and without minibuffers, but when there is a minibuffer-only frame
>>> never seen it accompanied with other frames-with-minibuffer, except for
>>> frames on other terminals).
>> 
>> I don't sure what the "in the wild" means, but I know at least two
>> packages that shows minibuffer-only child frame on reading user input:
>
> I didn't ask if this was possible, or used, I asked if such usage is
> common.

I don't think such usage is common nowadays.  Maybe someday it would
sound like "minibuffer-only frame while other frames have echo areas"
and then it would be more commonly used IMO.

> It is clear that we cannot find a default that will fit all
> the uses, but we should have the default that works well in common use
> cases.

Totally agree.  Just thought that the existing behavior is common
enough.

Don't you the think new behavior may be confusing?  The old behavior was
like "Oh, I left the minibuffer in that frame; OK, I need to switch to
that frame and complete the task".  And the new one is like "Oh, the
minibuffer is on active frame, cool! But wait, where is the results of
my eval?" because in 'emacs -Q':

C-x 5 b foo RET bar M-: (buffer-string) C-x 5 o C-x o RET

Seems like the 'buffer-string' is evaluated in the *scratch* buffer, but
it is not.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Cc: monnier@iro.umontreal.ca,  enometh@meer.net,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2020 00:43:13 +0200
> 
> Don't you the think new behavior may be confusing?  The old behavior was
> like "Oh, I left the minibuffer in that frame; OK, I need to switch to
> that frame and complete the task".

Actually, the old behavior was more like "Oh, I left the minibuffer in
that frame, but sometimes -- whoops! -- it jumps to the new frame, and
sometimes it doesn't."

> And the new one is like "Oh, the minibuffer is on active frame,
> cool! But wait, where is the results of my eval?" because in 'emacs
> -Q':
> 
> C-x 5 b foo RET bar M-: (buffer-string) C-x 5 o C-x o RET
> 
> Seems like the 'buffer-string' is evaluated in the *scratch* buffer, but
> it is not.

Exactly as documented, btw.  But if we think this is a bug, we should
fix it regardless of the default value of the new option.  Once again,
let's distinguish between what we think are bugs and what we think is
valid behavior that someone might not like as the default.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> I don't sure what the "in the wild" means, but I know at least two
> packages that shows minibuffer-only child frame on reading user input:
>
> https://raw.githubusercontent.com/honmaple/emacs-maple-minibuffer/master/maple-minibuffer.el
>
> https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el

Indeed, great examples, thanks.

> I can't report this as a bug.  Just wondering why
> minibuffer-follows-selected-frame is set to t by default, potentially
> changing someone's expected behavior.

I think the reason is that it more closely mimics what happens with the
echo area and it arguably (philosophically) better matches the default
setting of `enable-recursive-minibuffers`.

But if it results in regressions with packages to maple-minibuffer or
mini-frame, we should of course try and address that (either by refining
the behavior or by changing the default).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I don't sure what the "in the wild" means, but I know at least two
>> packages that shows minibuffer-only child frame on reading user input:
>>
>> https://raw.githubusercontent.com/honmaple/emacs-maple-minibuffer/master/maple-minibuffer.el
>>
>> https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el
>
> Indeed, great examples, thanks.
>
>> I can't report this as a bug.  Just wondering why
>> minibuffer-follows-selected-frame is set to t by default, potentially
>> changing someone's expected behavior.
>
> I think the reason is that it more closely mimics what happens with the
> echo area and it arguably (philosophically) better matches the default
> setting of `enable-recursive-minibuffers`.

Maybe I'm missing something, but the message "Command attempted to use
minibuffer while in minibuffer" is displayed in other frame, just like
in Emacs 27.

> But if it results in regressions with packages to maple-minibuffer or
> mini-frame, we should of course try and address that (either by refining
> the behavior or by changing the default).

Well, mini-frame-mode already has a (not so pretty) workaround for the
new behavior: set the global option on mode activation.

Probably the better solution will be to not take the minibuffer away
from minibuffer-only frames.  After all, it's all they got :)

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> I think the reason is that it more closely mimics what happens with the
>> echo area and it arguably (philosophically) better matches the default
>> setting of `enable-recursive-minibuffers`.
> Maybe I'm missing something, but the message "Command attempted to use
> minibuffer while in minibuffer" is displayed in other frame, just like
> in Emacs 27.

I'm not sure which scenario you're referring to.  What I was referring
to is the fact that if you do `M-: (message "hello") RET`, the "hello"
message subsequently follows the selected frame (until it gets replaced
by another message or erased by command that doesn't emit any message).

> Probably the better solution will be to not take the minibuffer away
> from minibuffer-only frames.  After all, it's all they got :)

Personally I philosophically like the (non-default) nil setting for the
new variable, so that minibuffers stick to the frame where they
presumably operate.

But since my Emacs only has a single mini window anyway, I'm never
affected by this setting at all, so I don't have any real experience
either way.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> it arguably (philosophically) better matches the default setting of
>>> `enable-recursive-minibuffers`.
>> Maybe I'm missing something, but the message "Command attempted to use
>> minibuffer while in minibuffer" is displayed in other frame, just like
>> in Emacs 27.
>
> I'm not sure which scenario you're referring to.  What I was referring
> to is the fact that if you do `M-: (message "hello") RET`, the "hello"
> message subsequently follows the selected frame (until it gets replaced
> by another message or erased by command that doesn't emit any message).

Sorry for not quoting the part of the message I was talking about.  I'm
referring to this scenario:

C-x 5 2
M-x
C-x 5 o
M-x

With the default setting of `enable-recursive-minibuffers`, the
minibuffer is moved to active frame, but the error message is displayed
in the other frame.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Date: Wed, 11 Nov 2020 09:47:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, enometh@meer.net, emacs-devel@gnu.org
> 
> C-x 5 2
> M-x
> C-x 5 o
> M-x
> 
> With the default setting of `enable-recursive-minibuffers`, the
> minibuffer is moved to active frame, but the error message is displayed
> in the other frame.

Arguably a bug.  Alan, could you please look into this?

Thanks.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 11, 2020 at 18:07:49 +0200, Eli Zaretskii wrote:
> > From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> > Date: Wed, 11 Nov 2020 09:47:39 +0200
> > Cc: Eli Zaretskii <eliz@gnu.org>, enometh@meer.net, emacs-devel@gnu.org

> > C-x 5 2
> > M-x
> > C-x 5 o
> > M-x

> > With the default setting of `enable-recursive-minibuffers`, the
> > minibuffer is moved to active frame, but the error message is displayed
> > in the other frame.

> Arguably a bug.  Alan, could you please look into this?

I think this is a bug, too.

I've been looking at the C sources for some while but haven't found
anything useful.  I've tried setting echo_area_window during the frame
change, but this doesn't have any visible effect.

I'll carry on with the diagnosis.  Any quick tips would be welcome.

Thanks!

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 11 Nov 2020 20:37:16 +0000
> Cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, monnier@iro.umontreal.ca,
>   enometh@meer.net, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > C-x 5 2
> > > M-x
> > > C-x 5 o
> > > M-x
> 
> > > With the default setting of `enable-recursive-minibuffers`, the
> > > minibuffer is moved to active frame, but the error message is displayed
> > > in the other frame.
> 
> > Arguably a bug.  Alan, could you please look into this?
> 
> I think this is a bug, too.
> 
> I've been looking at the C sources for some while but haven't found
> anything useful.  I've tried setting echo_area_window during the frame
> change, but this doesn't have any visible effect.
> 
> I'll carry on with the diagnosis.  Any quick tips would be welcome.

My guess is that this is somehow related to the fact that error
messages are displayed as part of handling an error signal, which
causes a throw to top level.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 14 Nov 2020 15:36:43 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: enometh@meer.net, monnier@iro.umontreal.ca, andreyk.mad@gmail.com,
>  emacs-devel@gnu.org
> 
> > Date: Wed, 11 Nov 2020 20:37:16 +0000
> > Cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, monnier@iro.umontreal.ca,
> >   enometh@meer.net, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > > > C-x 5 2
> > > > M-x
> > > > C-x 5 o
> > > > M-x
> > 
> > > > With the default setting of `enable-recursive-minibuffers`, the
> > > > minibuffer is moved to active frame, but the error message is displayed
> > > > in the other frame.
> > 
> > > Arguably a bug.  Alan, could you please look into this?
> > 
> > I think this is a bug, too.
> > 
> > I've been looking at the C sources for some while but haven't found
> > anything useful.  I've tried setting echo_area_window during the frame
> > change, but this doesn't have any visible effect.
> > 
> > I'll carry on with the diagnosis.  Any quick tips would be welcome.
> 
> My guess is that this is somehow related to the fact that error
> messages are displayed as part of handling an error signal, which
> causes a throw to top level.

Specifically, read-from-minibuffer (called when we type the first M-x)
binds some variables, then enters recursive-edit.  When the error
unwinds the stack, it restores the original window configuration,
which includes the frame which was selected back then.  And that
undoes the effect of "C-x 5 o", so the error message is displayed on
the original frame.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 14, 2020 at 19:12:24 +0200, Eli Zaretskii wrote:
> > Date: Sat, 14 Nov 2020 15:36:43 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: enometh@meer.net, monnier@iro.umontreal.ca, andreyk.mad@gmail.com,
> >  emacs-devel@gnu.org

> > > Date: Wed, 11 Nov 2020 20:37:16 +0000
> > > Cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, monnier@iro.umontreal.ca,
> > >   enometh@meer.net, emacs-devel@gnu.org
> > > From: Alan Mackenzie <acm@muc.de>

> > > > > C-x 5 2
> > > > > M-x
> > > > > C-x 5 o
> > > > > M-x

> > > > > With the default setting of `enable-recursive-minibuffers`, the
> > > > > minibuffer is moved to active frame, but the error message is displayed
> > > > > in the other frame.

> > > > Arguably a bug.  Alan, could you please look into this?

> > > I think this is a bug, too.

> > > I've been looking at the C sources for some while but haven't found
> > > anything useful.  I've tried setting echo_area_window during the frame
> > > change, but this doesn't have any visible effect.

> > > I'll carry on with the diagnosis.  Any quick tips would be welcome.

> > My guess is that this is somehow related to the fact that error
> > messages are displayed as part of handling an error signal, which
> > causes a throw to top level.

> Specifically, read-from-minibuffer (called when we type the first M-x)
> binds some variables, then enters recursive-edit.  When the error
> unwinds the stack, it restores the original window configuration,
> which includes the frame which was selected back then.  And that
> undoes the effect of "C-x 5 o", so the error message is displayed on
> the original frame.

Thanks!  I was approaching the same conclusion myself, but much more
slowly than you.  ;-)

Arguably, Fset_window_configuration selecting the pertinent frame is a
bug in the specification of that function - one should be able to restore
a frame's configuration without selecting the frame as well.  However,
backwards compatibility, and all that....

I propose fixing the bug at the place where read_minibuf saves the frame
configuration.  As well as saving that frame configuration, it should
additionally save another Lisp_Object for which nil means "restore the
selected frame", non-nil means "don't restore it".
Fset_window_configuration would acquire an extra &optional parameter with
the same meaning.

The function restore_window_configuration, frustratingly, is used in only
one place apart from read_minibuf, and that is in an obsolete byte code
in bytecode.c.

What do you think?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 14 Nov 2020 18:48:58 +0000
> Cc: enometh@meer.net, monnier@iro.umontreal.ca, andreyk.mad@gmail.com,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I propose fixing the bug at the place where read_minibuf saves the frame
> configuration.  As well as saving that frame configuration, it should
> additionally save another Lisp_Object for which nil means "restore the
> selected frame", non-nil means "don't restore it".
> Fset_window_configuration would acquire an extra &optional parameter with
> the same meaning.

Sounds fine, but I'd like to hear Martin's comments on this idea.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Arguably, Fset_window_configuration selecting the pertinent frame is a
 > bug in the specification of that function - one should be able to restore
 > a frame's configuration without selecting the frame as well.  However,
 > backwards compatibility, and all that....

You'd first have to get rid of the two select_window calls which select
the frame whose configuration gets restored.  Fset_window_configuration
is a PITA.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin and Eli.

On Sat, Nov 14, 2020 at 20:24:32 +0100, martin rudalics wrote:
>  > Arguably, Fset_window_configuration selecting the pertinent frame is a
>  > bug in the specification of that function - one should be able to restore
>  > a frame's configuration without selecting the frame as well.  However,
>  > backwards compatibility, and all that....

> You'd first have to get rid of the two select_window calls which select
> the frame whose configuration gets restored.  Fset_window_configuration
> is a PITA.

Actually, I just put in a do_switch_frame back to the frame which was
the selected one at the beginning of the function.

But I agree with you about Fset_window_configuration.

Anyway, here's a provisional patch.  I realise that my amendment to the
doc string of Fset_window_configuration is poor, but it's too late to
fix it tonight.  ;-(  I also realise I'll need to amend the Elisp manual
and NEWS, but also not tonight.

The patch seems to fix the bug (the one about a "recursive" C-x b
displaying its error message in the wrong frame).

Comments are welcome.



diff --git a/src/keyboard.c b/src/keyboard.c
index 49a0a8bd23..1579c007ec 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2122,7 +2122,7 @@ read_char_help_form_unwind (void)
   Lisp_Object window_config = XCAR (help_form_saved_window_configs);
   help_form_saved_window_configs = XCDR (help_form_saved_window_configs);
   if (!NILP (window_config))
-    Fset_window_configuration (window_config);
+    Fset_window_configuration (window_config, Qnil);
 }
 
 #define STOP_POLLING					\
diff --git a/src/minibuf.c b/src/minibuf.c
index 8c19559b08..acb633c583 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -501,14 +501,15 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   record_unwind_protect_void (choose_minibuf_frame);
 
   record_unwind_protect (restore_window_configuration,
-			 Fcurrent_window_configuration (Qnil));
+                         Fcons (Qt, Fcurrent_window_configuration (Qnil)));
 
   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
-			   Fcurrent_window_configuration (mini_frame));
+			   Fcons (Qt,
+                                  Fcurrent_window_configuration (mini_frame)));
 
   /* If the minibuffer is on an iconified or invisible frame,
      make it visible now.  */
diff --git a/src/window.c b/src/window.c
index a6de34f3db..3187720f89 100644
--- a/src/window.c
+++ b/src/window.c
@@ -6824,19 +6826,24 @@ DEFUN ("window-configuration-frame", Fwindow_configuration_frame, Swindow_config
 }
 
 DEFUN ("set-window-configuration", Fset_window_configuration,
-       Sset_window_configuration, 1, 1, 0,
+       Sset_window_configuration, 1, 2, 0,
        doc: /* Set the configuration of windows and buffers as specified by CONFIGURATION.
 CONFIGURATION must be a value previously returned
 by `current-window-configuration' (which see).
+
+Normally, the original frame of CONFIGURATION gets selected, but if DONT-SET-FRAME is
+non-nil, the frame selected at the beginning of this function remains selected.
+
 If CONFIGURATION was made from a frame that is now deleted,
 only frame-independent values can be restored.  In this case,
 the return value is nil.  Otherwise the value is t.  */)
-  (Lisp_Object configuration)
+  (Lisp_Object configuration, Lisp_Object dont_set_frame)
 {
   register struct save_window_data *data;
   struct Lisp_Vector *saved_windows;
   Lisp_Object new_current_buffer;
   Lisp_Object frame;
+  Lisp_Object old_frame = selected_frame;
   struct frame *f;
   ptrdiff_t old_point = -1;
   USE_SAFE_ALLOCA;
@@ -7153,7 +7160,10 @@ the return value is nil.  Otherwise the value is t.  */)
 	 select_window above totally superfluous; it still sets f's
 	 selected window.  */
       if (FRAME_LIVE_P (XFRAME (data->selected_frame)))
-	do_switch_frame (data->selected_frame, 0, 0, Qnil);
+	do_switch_frame (NILP (dont_set_frame)
+                         ? data->selected_frame
+                         : old_frame
+                         , 0, 0, Qnil);
     }
 
   FRAME_WINDOW_CHANGE (f) = true;
@@ -7191,7 +7201,10 @@ the return value is nil.  Otherwise the value is t.  */)
 void
 restore_window_configuration (Lisp_Object configuration)
 {
-  Fset_window_configuration (configuration);
+  if (CONSP (configuration))
+    Fset_window_configuration (XCDR (configuration), XCAR (configuration));
+  else
+    Fset_window_configuration (configuration, Qnil);
 }
 
 


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > The patch seems to fix the bug (the one about a "recursive" C-x b
 > displaying its error message in the wrong frame).
 >
 > Comments are welcome.

IIRC restoring the window configuration here is a bad idea because any
change of the window configuration you do in a nested invocation is
immediately undone when the outer invocation gets in control again.  So
'read_minibuf' is just as poor as 'set-window-configuration' and you
can't harm either of them much by doing such changes.  Both should be
rewritten from scratch with a clear concept of what they are supposed to
accomplish in mind.

And obviously all those select_window/Fselect_window calls outside the
scope of 'select-window' proper must get removed.  We hardly can get
them right within window.c itself so what do we expect from the others?

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Andrii.

On Wed, Nov 11, 2020 at 09:47:39 +0200, Andrii Kolomoiets wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >>> it arguably (philosophically) better matches the default setting of
> >>> `enable-recursive-minibuffers`.
> >> Maybe I'm missing something, but the message "Command attempted to use
> >> minibuffer while in minibuffer" is displayed in other frame, just like
> >> in Emacs 27.

> > I'm not sure which scenario you're referring to.  What I was referring
> > to is the fact that if you do `M-: (message "hello") RET`, the "hello"
> > message subsequently follows the selected frame (until it gets replaced
> > by another message or erased by command that doesn't emit any message).

> Sorry for not quoting the part of the message I was talking about.  I'm
> referring to this scenario:

> C-x 5 2
> M-x
> C-x 5 o
> M-x

> With the default setting of `enable-recursive-minibuffers`, the
> minibuffer is moved to active frame, but the error message is displayed
> in the other frame.

I've just committed a fix to the Emacs master branch.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Alan Mackenzie <acm@muc.de> writes:

>> With the default setting of `enable-recursive-minibuffers`, the
>> minibuffer is moved to active frame, but the error message is displayed
>> in the other frame.
>
> I've just committed a fix to the Emacs master branch.

Some NEWS entries are deleted with your commit.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Andrii.

On Thu, Nov 19, 2020 at 13:40:19 +0200, Andrii Kolomoiets wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> With the default setting of `enable-recursive-minibuffers`, the
> >> minibuffer is moved to active frame, but the error message is displayed
> >> in the other frame.

> > I've just committed a fix to the Emacs master branch.

> Some NEWS entries are deleted with your commit.

Sorry about that, and thanks for noticing.  That problem should now be
fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > I've just committed a fix to the Emacs master branch.

Sorry, but this cannot be possibly right.  With emacs -Q load a file
with

(setq default-frame-alist '((minibuffer . nil)))

(defun foo ()
   (interactive)
   (read-from-minibuffer "...?")
   (insert (format "%s" (selected-frame))))

insert (foo) into *scratch* and type C-x C-e.  After answering the
prompt this gets me #<frame *Minibuf-1* 0x36132d8>.  Do the same with
Emacs 27 and it will get you the *scratch* frame.

As soon as 'read-from-minibuffer' has finished its job, it is as if it
never happened and the old configuration must have been restored.  We
might be able to stay on old_frame when minibuf_level > 0 but in the
scenario above the frame that was selected when 'read-from-minibuffer'
was called must be re-selected.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Fri, Nov 20, 2020 at 19:47:28 +0100, martin rudalics wrote:
>  > I've just committed a fix to the Emacs master branch.

> Sorry, but this cannot be possibly right.  With emacs -Q load a file
> with

> (setq default-frame-alist '((minibuffer . nil)))

> (defun foo ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert (format "%s" (selected-frame))))

> insert (foo) into *scratch* and type C-x C-e.  After answering the
> prompt this gets me #<frame *Minibuf-1* 0x36132d8>.  Do the same with
> Emacs 27 and it will get you the *scratch* frame.

Yes, I see this (except for the Emacs 27 bit which I haven't tried,
yet).

However, if I type (frame-list) into *scratch* and do C-x C-e I get only
one frame in the list, and it has the same address in the #<frame ...>
output as the " *Minibuf-1* 0xxxx" output.

In other words, I think your (insert (format "%s" (selected-frame))) is
getting the correct frame, but the current buffer within it is still the
minibuffer.

Might you possibly have simplified the recipe so much that the problem
is no longer shown by the recipe?  Removing the setting of
default-frame-alist from the file doesn't seem to make any difference.

> As soon as 'read-from-minibuffer' has finished its job, it is as if it
> never happened and the old configuration must have been restored.  We
> might be able to stay on old_frame when minibuf_level > 0 but in the
> scenario above the frame that was selected when 'read-from-minibuffer'
> was called must be re-selected.

Why were we selecting a frame as an "incidental" side effect of restoring
a window configuration?  Surely the frame to be selected should be
selected deliberately and explicitly.

I'm thinking that what needs restoring is the frame's current buffer, and
I'm wondering why that wasn't done by the (set-window-configuration foo
t) which happened near the end of read_minibuf.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> (setq default-frame-alist '((minibuffer . nil)))
>>
>> (defun foo ()
>>    (interactive)
>>    (read-from-minibuffer "...?")
>>    (insert (format "%s" (selected-frame))))
[...]
> However, if I type (frame-list) into *scratch* and do C-x C-e I get only
> one frame in the list, and it has the same address in the #<frame ...>
> output as the " *Minibuf-1* 0xxxx" output.

Hmm... any chance you've missed the

    (setq default-frame-alist '((minibuffer . nil)))

or you executed it too late?
There *should* be 2 frames in the above recipe, one being
a minibuffer-only frame.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> (setq default-frame-alist '((minibuffer . nil)))
 >
 >> (defun foo ()
 >>     (interactive)
 >>     (read-from-minibuffer "...?")
 >>     (insert (format "%s" (selected-frame))))
 >
 >> insert (foo) into *scratch* and type C-x C-e.  After answering the
 >> prompt this gets me #<frame *Minibuf-1* 0x36132d8>.  Do the same with
 >> Emacs 27 and it will get you the *scratch* frame.
 >
 > Yes, I see this (except for the Emacs 27 bit which I haven't tried,
 > yet).
 >
 > However, if I type (frame-list) into *scratch* and do C-x C-e I get only
 > one frame in the list, and it has the same address in the #<frame ...>
 > output as the " *Minibuf-1* 0xxxx" output.

You have to _load_ the

(setq default-frame-alist '((minibuffer . nil)))

part, it won't work after your default initial frame has been already
set up.  Run Emacs via something like

emacs -Q --load ~/foo.el

to see the effect (and please try to get used to test any changes in
this area with such a setup as well).

But indeed, with Emacs -Q executing 'foo' defined as

(defun foo ()
   (interactive)
   (read-from-minibuffer "...?")
   (insert (format "window: %s .. frame: %s" (selected-window) (selected-frame))))

reveals another aspect broken by your change.  The values reported by
'selected-window' and 'select-frame' do not match up any more (unless
our masochistic way or printing frame names hides an important detail).

 > In other words, I think your (insert (format "%s" (selected-frame))) is
 > getting the correct frame, but the current buffer within it is still the
 > minibuffer.

The frame is _not_ correct - try with a separate minibuffer frame.

 > Might you possibly have simplified the recipe so much that the problem
 > is no longer shown by the recipe?  Removing the setting of
 > default-frame-alist from the file doesn't seem to make any difference.

See above.

 > Why were we selecting a frame as an "incidental" side effect of restoring
 > a window configuration?  Surely the frame to be selected should be
 > selected deliberately and explicitly.

Agreed.  But I suppose the current behavior was chosen precisely to
support the use case we're discussing here: With a separate minibuffer
frame it has to restore the frame that was selected before the
minibuffer interaction started.  All the remaining stuff done by
restore_window_configuration is rubbish IMHO.  Basically, minibuffer
only frames could work seamlessly were it not for the complications that
people added over the years:

'restore_window_configuration': Anything the minibuffer dialogue changes
in the window configuration of a normal frame (like popping up
completions) should be undone immediately by the associated code.  Any
changes to the configuration done explicitly by the user in between
(like, for example, splitting a window to run some other application in
it) should not be undone.

'redirect-frame-focus': There's should be no need for that - when the
minibuffer becomes active, raise its frame to send keystrokes to it.
With the above minibuffer nil setting here I get a minibuffer frame that
is hidden by the non-minibuffer frame when it shows the prompt - no
wonder that people immediately refrain from using such a set up.  The
prompt must be initially visible - always and everywhere.  Emacs should
be no hide-and-seek game.

'frame-auto-hide-function': No need for that either.  When a minibuffer
frame becomes active, it should become visible and be displayed on top
of the frame from where the dialogue originated.  When the dialogue
terminates, the minibuffer frame should return to its prior state.

Obviously, people might dislike a minibuffer-only frame getting focus
every time something is displayed in the echo area.  But that's just a
consequence of Emacs habit to conflate minibuffer and echo area in one
and the same part of a user's display.

 > I'm thinking that what needs restoring is the frame's current buffer, and
 > I'm wondering why that wasn't done by the (set-window-configuration foo
 > t) which happened near the end of read_minibuf.

A frame does not have a current buffer.  The "current buffer" is a
completely different concept.  The only real connection is that in
keyboard.c the

       set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents));

resets the current buffer to that of the selected window which also
should be the selected frame's selected window.  But your change
apparently broke that.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 21, 2020 at 10:02:15 +0100, martin rudalics wrote:
>  >> (setq default-frame-alist '((minibuffer . nil)))

>  >> (defun foo ()
>  >>     (interactive)
>  >>     (read-from-minibuffer "...?")
>  >>     (insert (format "%s" (selected-frame))))

>  >> insert (foo) into *scratch* and type C-x C-e.  After answering the
>  >> prompt this gets me #<frame *Minibuf-1* 0x36132d8>.  Do the same with
>  >> Emacs 27 and it will get you the *scratch* frame.

>  > Yes, I see this (except for the Emacs 27 bit which I haven't tried,
>  > yet).

>  > However, if I type (frame-list) into *scratch* and do C-x C-e I get only
>  > one frame in the list, and it has the same address in the #<frame ...>
>  > output as the " *Minibuf-1* 0xxxx" output.

> You have to _load_ the

> (setq default-frame-alist '((minibuffer . nil)))

> part, it won't work after your default initial frame has been already
> set up.  Run Emacs via something like

> emacs -Q --load ~/foo.el

> to see the effect ....

OK, I've got it now.

[ .... ]

> But indeed, with Emacs -Q executing 'foo' defined as

> (defun foo ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert (format "window: %s .. frame: %s" (selected-window) (selected-frame))))

> reveals another aspect broken by your change.  The values reported by
> 'selected-window' and 'select-frame' do not match up any more (unless
> our masochistic way of printing frame names hides an important detail).

I'll look at that later.  I'll look at the other things below [snipped]
later, too.  I'm a bit short of time today.

[ .... ]

Here's a quick and dirty patch to minibuf.c which appears to fix the bug,
but I haven't given it much testing yet:



diff --git a/src/minibuf.c b/src/minibuf.c
index 464e3018f7..5312dc9805 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -508,7 +508,14 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
-			   Fcons (Qt,
+			   Fcons (
+                                  /* If we're at top minibuffer level in a
+                                     minibuffer-only frame, arrange for the
+                                     frame later to be switched back.  */
+                                  (FRAME_MINIBUF_ONLY_P (XFRAME (mini_frame))
+                                   && minibuf_level <= 1)
+                                  ? Qnil
+                                  : Qt,
                                   Fcurrent_window_configuration (mini_frame)));
 
   /* If the minibuffer is on an iconified or invisible frame,


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Here's a quick and dirty patch to minibuf.c which appears to fix the bug,
 > but I haven't given it much testing yet:

This will still fail when read_minibuf, triggered from any frame but the
minibuffer frame, exits with minibuf_level > 0.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 21, 2020 at 12:55:41 +0100, martin rudalics wrote:
>  > Here's a quick and dirty patch to minibuf.c which appears to fix the bug,
>  > but I haven't given it much testing yet:

> This will still fail when read_minibuf, triggered from any frame but the
> minibuffer frame, exits with minibuf_level > 0.

(i) I start emacs -Q --load=foo.el
(ii) C-x 5 2  ; this leaves three frames, one being the minibuffer
  frame.
(iii) C-x b   ; leaves point in the minibuffer.
(iv) C-x 5 o  ; moves to the other normal frame.
(v) C-r  C-x 8 RET SPACE RET ; invokes a recursive minibuffer

At this stage, point is in the minibuffer, exactly as after (iii).  I
don't see this as a failure.

Where do you see the failure happening with that quick and dirty patch?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Where do you see the failure happening with that quick and dirty patch?

Load (via --load) a file with the following contents:


(setq default-frame-alist '((minibuffer . nil)))

(setq enable-recursive-minibuffers t)

(defun foo ()
   (interactive)
   (read-from-minibuffer "...?")
   (insert (format "%s" (selected-frame))))

(global-set-key [(control meta +)] 'foo)


Now type C-x 5 2 followed by C-M-+ in one of the normal frames.  Then
type C-M-+ in the other normal frame and type RET in the minibuffer
frame.  Here I get in *scratch*

#<frame *Minibuf-2* 0x313ab10>

and only answering the second prompt gets me a normal frame inserted.

Emacs 27 after any of these prompts inserts the frame selected at the
time I typed C-M-+ which is TRT.

As I mentioned earlier in this thread, such tribulations are the price
we have to pay for providing non-modal dialogues.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 21, 2020 at 16:53:11 +0100, martin rudalics wrote:
>  > Where do you see the failure happening with that quick and dirty patch?

> Load (via --load) a file with the following contents:


> (setq default-frame-alist '((minibuffer . nil)))

> (setq enable-recursive-minibuffers t)

> (defun foo ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert (format "%s" (selected-frame))))

> (global-set-key [(control meta +)] 'foo)


> Now type C-x 5 2 followed by C-M-+ in one of the normal frames.  Then
> type C-M-+ in the other normal frame and type RET in the minibuffer
> frame.  Here I get in *scratch*

> #<frame *Minibuf-2* 0x313ab10>

> and only answering the second prompt gets me a normal frame inserted.

Yes.  It seems my patch from yesterday was too complicated.  At the
record_unwind_protect for the window configuration of the calling frame
(when that is different from the minibuffer frame) in read_minibuf, we
can set it up later to select that calling frame unconditionally.
Basically, if the MB is on a different frame, we want to return to the
calling frame always.

So, instead of yesterday's patch, I think this patch works:



diff --git a/src/minibuf.c b/src/minibuf.c
index 464e3018f7..fc3fd92a88 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
-			   Fcons (Qt,
+			   Fcons (/* Arrange for the frame later to be
+                                     switched back to the calling
+                                     frame. */
+                                  Qnil,
                                   Fcurrent_window_configuration (mini_frame)));
 
   /* If the minibuffer is on an iconified or invisible frame,



> Emacs 27 after any of these prompts inserts the frame selected at the
> time I typed C-M-+ which is TRT.

There seem to be quite a few things wrong, even on Emacs 27.  On
starting it with loading your initialisation file from the command line,
the initial selected frame is the minibuffer frame, which is surely
suboptimal.  On M-: followed by C-x 5 o (moving to the normal frame),
the unfinished command in the minibuffer frame cannot now be cancelled,
and C-x 5 o doesn't move back into the minibuffer.

I'm coming round to your way of thinking, that this whole area is a
mess, and needs redesigning.

> As I mentioned earlier in this thread, such tribulations are the price
> we have to pay for providing non-modal dialogues.

Yes, maybe, but modal dialogues are a right pain for the user, as can be
seen by using virtually any commericial software on non-free systems.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> Yes.  It seems my patch from yesterday was too complicated.  At the

Agreed.  I think we should more narrowly taylor-make it for the problem
at hand: i.e. when signaling an error, remember the selected-frame
somewhere before doing the longjmp, and then when emitting the error
message make use of that remembered selected-frame to choose which
miniwindow to use for the message.

Basically, the problem at hand is that we want to emit the error message
"as if" we did it before the longjmp, but for technical reasons we need
to do it after the longjmp.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

On Sun, Nov 22, 2020 at 10:13:35 -0500, Stefan Monnier wrote:
> > Yes.  It seems my patch from yesterday was too complicated.  At the

> Agreed.  I think we should more narrowly taylor-make it for the problem
> at hand: i.e. when signaling an error, remember the selected-frame
> somewhere before doing the longjmp, and then when emitting the error
> message make use of that remembered selected-frame to choose which
> miniwindow to use for the message.

Er, I think you're talking about the patch I committed on Thursday, not
the proposed one I sent to Martin.

> Basically, the problem at hand is that we want to emit the error message
> "as if" we did it before the longjmp, but for technical reasons we need
> to do it after the longjmp.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> Agreed.  I think we should more narrowly taylor-make it for the problem
>> at hand: i.e. when signaling an error, remember the selected-frame
>> somewhere before doing the longjmp, and then when emitting the error
>> message make use of that remembered selected-frame to choose which
>> miniwindow to use for the message.
>
> Er, I think you're talking about the patch I committed on Thursday, not
> the proposed one I sent to Martin.

Hmm... like King Crimson said: confusion will be my epitaph,


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > diff --git a/src/minibuf.c b/src/minibuf.c
 > index 464e3018f7..fc3fd92a88 100644
 > --- a/src/minibuf.c
 > +++ b/src/minibuf.c
 > @@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 >     mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
 >     if (!EQ (mini_frame, selected_frame))
 >       record_unwind_protect (restore_window_configuration,
 > -			   Fcons (Qt,
 > +			   Fcons (/* Arrange for the frame later to be
 > +                                     switched back to the calling
 > +                                     frame. */
 > +                                  Qnil,
 >                                     Fcurrent_window_configuration (mini_frame)));
 >
 >     /* If the minibuffer is on an iconified or invisible frame,

This one immediately chokes when I run

emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

and type C-x 5 2.  Here the cursor disappears entirely although when I
do some typing now the text shows up in the minibuffer window.  TRT as
with Emacs 27 is to select and focus the new frame.

 > There seem to be quite a few things wrong, even on Emacs 27.  On
 > starting it with loading your initialisation file from the command line,
 > the initial selected frame is the minibuffer frame, which is surely
 > suboptimal.

Here the minibuffer-only frame is selected but partially hidden by the
normal frame so that I don't see no cursor initially.  I don't know why
people like it that way.  A minibuffer child frame is explicitly not
selected.

Note that the way Emacs creates the two frames layout is atrocious - we
first make a normal frame to do our usual initialization stuff and then
we create the minibuffer-only and the minibuffer-less frames and delete
the initial one (compare 'frame-notice-user-settings').  It's for years
that I want to rewrite that ...

 > On M-: followed by C-x 5 o (moving to the normal frame),
 > the unfinished command in the minibuffer frame cannot now be cancelled,
 > and C-x 5 o doesn't move back into the minibuffer.

'other-frame' never selects a minibuffer-only frame.  It probably should.

And the behavior of C-g in a separate minibuffer frame IME usually
varies with the time of the day.

 > Yes, maybe, but modal dialogues are a right pain for the user, as can be
 > seen by using virtually any commericial software on non-free systems.

Modal dialogues are supported by the windowing subsystem, regardless of
whether it's free or not.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sun, Nov 22, 2020 at 18:57:30 +0100, martin rudalics wrote:
>  > diff --git a/src/minibuf.c b/src/minibuf.c
>  > index 464e3018f7..fc3fd92a88 100644
>  > --- a/src/minibuf.c
>  > +++ b/src/minibuf.c
>  > @@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>  >     mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
>  >     if (!EQ (mini_frame, selected_frame))
>  >       record_unwind_protect (restore_window_configuration,
>  > -			   Fcons (Qt,
>  > +			   Fcons (/* Arrange for the frame later to be
>  > +                                     switched back to the calling
>  > +                                     frame. */
>  > +                                  Qnil,
>  >                                     Fcurrent_window_configuration (mini_frame)));
>  >
>  >     /* If the minibuffer is on an iconified or invisible frame,

> This one immediately chokes when I run

> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

> and type C-x 5 2.  Here the cursor disappears entirely although when I
> do some typing now the text shows up in the minibuffer window.  TRT as
> with Emacs 27 is to select and focus the new frame.

On my machine (XFCE on X-Windows on GNU) I see TRT when I do this.  Could
it be something to do with your window manager?

>  > There seem to be quite a few things wrong, even on Emacs 27.  On
>  > starting it with loading your initialisation file from the command
>  > line, the initial selected frame is the minibuffer frame, which is
>  > surely suboptimal.

> Here the minibuffer-only frame is selected but partially hidden by the
> normal frame so that I don't see no cursor initially.  I don't know why
> people like it that way.  A minibuffer child frame is explicitly not
> selected.

Do people like it, or is it just not a big enough annoyance for anybody
to complain?  If I were a minibuffer-only frame user, I suspect it would
drive me up the wall.

> Note that the way Emacs creates the two frames layout is atrocious - we
> first make a normal frame to do our usual initialization stuff and then
> we create the minibuffer-only and the minibuffer-less frames and delete
> the initial one (compare 'frame-notice-user-settings').  It's for years
> that I want to rewrite that ...

Yes, I can understand that.  But you will be aware of all the nasty
little things which will leap out in front of you and force you to solve
along the way.

>  > On M-: followed by C-x 5 o (moving to the normal frame),
>  > the unfinished command in the minibuffer frame cannot now be cancelled,
>  > and C-x 5 o doesn't move back into the minibuffer.

> 'other-frame' never selects a minibuffer-only frame.  It probably should.

I'm more of the view that a minibuffer-only frame should never be
selected other than by activating a minibuffer.

> And the behavior of C-g in a separate minibuffer frame IME usually
> varies with the time of the day.

>  > Yes, maybe, but modal dialogues are a right pain for the user, as can be
>  > seen by using virtually any commericial software on non-free systems.

> Modal dialogues are supported by the windowing subsystem, regardless of
> whether it's free or not.

Yes.  I hate these dialogues, which force you to cancel them and start
again, should you need some information from another part of the program
to be able to fill them in.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > On my machine (XFCE on X-Windows on GNU) I see TRT when I do this.  Could
 > it be something to do with your window manager?

Here it's xfce 4.12 with xfwm4 so probably something very similar to
yours.  But since the behavior does not depend on your patches as I just
verified, something else must be causing it.

 >> Here the minibuffer-only frame is selected but partially hidden by the
 >> normal frame so that I don't see no cursor initially.  I don't know why
 >> people like it that way.  A minibuffer child frame is explicitly not
 >> selected.
 >
 > Do people like it, or is it just not a big enough annoyance for anybody
 > to complain?  If I were a minibuffer-only frame user, I suspect it would
 > drive me up the wall.

I suppose we only have two such users - Stefan and Drew - and they seem
to like it (or work around it).

 >> 'other-frame' never selects a minibuffer-only frame.  It probably should.
 >
 > I'm more of the view that a minibuffer-only frame should never be
 > selected other than by activating a minibuffer.

Then what did you mean with the last line of

 >> On M-: followed by C-x 5 o (moving to the normal frame),
 >> the unfinished command in the minibuffer frame cannot now be cancelled,
 >> and C-x 5 o doesn't move back into the minibuffer.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Mon, Nov 23, 2020 at 10:10:36 +0100, martin rudalics wrote:
>  > On my machine (XFCE on X-Windows on GNU) I see TRT when I do this.  Could
>  > it be something to do with your window manager?

> Here it's xfce 4.12 with xfwm4 so probably something very similar to
> yours.  But since the behavior does not depend on your patches as I just
> verified, something else must be causing it.

OK.

>  >> Here the minibuffer-only frame is selected but partially hidden by the
>  >> normal frame so that I don't see no cursor initially.  I don't know why
>  >> people like it that way.  A minibuffer child frame is explicitly not
>  >> selected.
  
>  > Do people like it, or is it just not a big enough annoyance for anybody
>  > to complain?  If I were a minibuffer-only frame user, I suspect it would
>  > drive me up the wall.

> I suppose we only have two such users - Stefan and Drew - and they seem
> to like it (or work around it).

Maybe one or other of them might answer this point.

>  >> 'other-frame' never selects a minibuffer-only frame.  It probably should.

>  > I'm more of the view that a minibuffer-only frame should never be
>  > selected other than by activating a minibuffer.

> Then what did you mean with the last line of

>  >> On M-: followed by C-x 5 o (moving to the normal frame),
>  >> the unfinished command in the minibuffer frame cannot now be cancelled,
>  >> and C-x 5 o doesn't move back into the minibuffer.

It was a complaint about not being able to cancel the unfinished command
in the minibuffer.  One should be able to cancel such a command.
Eventually it occurred to me that I could click on the minibuffer frame
with the mouse, which I did, and then C-g worked.

If you have nothing against it, I'll commit the fix from yesterday (the
one supplying a Qnil to the future set-window-configuration) to master.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> Then what did you mean with the last line of
 >
 >>   >> On M-: followed by C-x 5 o (moving to the normal frame),
 >>   >> the unfinished command in the minibuffer frame cannot now be cancelled,
 >>   >> and C-x 5 o doesn't move back into the minibuffer.
 >
 > It was a complaint about not being able to cancel the unfinished command
 > in the minibuffer.  One should be able to cancel such a command.
 > Eventually it occurred to me that I could click on the minibuffer frame
 > with the mouse,

C-x o should have worked too.

 > which I did, and then C-g worked.
 >
 > If you have nothing against it, I'll commit the fix from yesterday (the
 > one supplying a Qnil to the future set-window-configuration) to master.

Commit it.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Mon, Nov 23, 2020 at 15:22:08 +0100, martin rudalics wrote:
>  >> Then what did you mean with the last line of

>  >>   >> On M-: followed by C-x 5 o (moving to the normal frame),
>  >>   >> the unfinished command in the minibuffer frame cannot now be cancelled,
>  >>   >> and C-x 5 o doesn't move back into the minibuffer.

>  > It was a complaint about not being able to cancel the unfinished command
>  > in the minibuffer.  One should be able to cancel such a command.
>  > Eventually it occurred to me that I could click on the minibuffer frame
>  > with the mouse,

> C-x o should have worked too.

>  > which I did, and then C-g worked.

>  > If you have nothing against it, I'll commit the fix from yesterday (the
>  > one supplying a Qnil to the future set-window-configuration) to master.

> Commit it.

DONE.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > DONE.

Thanks.  To elaborate on an earlier problem I mentioned which, as I
found out, happens already with Emacs 27 at the least.  I'd be just
interested if you can reproduce it on your system.  Start with

emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

Now in the minibuffer window type C-h f and at the prompt type setq RET.
This pops up a help window on the normal frame explaining 'setq' and
'Type "q" in help window to delete it.' appears in the minibuffer
window.  Here, sometimes the normal frame is selected, sometimes the
minibuffer frame remains selected.  It might be a timing issue since
sometimes I see the cursor flicker at the end of the 'Type "q" ...'
text before it moves to the normal frame, provided it moves there.

The strange thing that happens is when I now type "q" in the help
window.  Here the minibuffer window gets selected and ready to receive
input but no cursor is shown in it.  Do you see that?  Anyone else?

Thanks, martin

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]


In GNU Emacs 28.0.50 (build 24, x86_64-apple-darwin19.6.0, NS
appkit-2022.10 Version 11.0.1 (Build 20B29))
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.0.1

> Thanks.  To elaborate on an earlier problem I mentioned which, as I
> found out, happens already with Emacs 27 at the least.  I'd be just
> interested if you can reproduce it on your system.  Start with
>
> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

To make both frames visible I use the following command:

emacs -Q --eval "(setq initial-frame-alist '((minibuffer) (top . 86)))"

> Now in the minibuffer window type C-h f and at the prompt type setq RET.
> This pops up a help window on the normal frame explaining 'setq' and
> 'Type "q" in help window to delete it.' appears in the minibuffer
> window.  Here, sometimes the normal frame is selected, sometimes the
> minibuffer frame remains selected.  It might be a timing issue since
> sometimes I see the cursor flicker at the end of the 'Type "q" ...'
> text before it moves to the normal frame, provided it moves there.

Here the normal frame is visually selected, but the minibuffer frame is
ready to receive input.  See attached screenshot.

> The strange thing that happens is when I now type "q" in the help
> window.  Here the minibuffer window gets selected and ready to receive
> input but no cursor is shown in it.  Do you see that?  Anyone else?

Can confirm.


[-- Attachment #2: chf.png --]
[-- Type: image/png, Size: 114767 bytes --]

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > To make both frames visible I use the following command:
 >
 > emacs -Q --eval "(setq initial-frame-alist '((minibuffer) (top . 86)))"

Yes.  I'm using (top . -1).

 > Here the normal frame is visually selected, but the minibuffer frame is
 > ready to receive input.  See attached screenshot.

That should be focus redirection at work.  'Type "q" in help window to
delete it.' is a hint that the normal frame is not selected internally
so C-x 1 would not work.  I see no logical flaws till here.

 >> The strange thing that happens is when I now type "q" in the help
 >> window.  Here the minibuffer window gets selected and ready to receive
 >> input but no cursor is shown in it.  Do you see that?  Anyone else?
 >
 > Can confirm.

Thanks.  I have no idea why this happens - window point and start are
both at 1 and the buffer is empty.  Either redisplay gets confused or
this is by design ...

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> Thanks.  To elaborate on an earlier problem I mentioned which, as I 
> found out, happens already with Emacs 27 at the least.  I'd be just 
> interested if you can reproduce it on your system.  Start with
>
> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
>
> Now in the minibuffer window type C-h f and at the prompt type setq RET. 
> This pops up a help window on the normal frame explaining 'setq' and 
> 'Type "q" in help window to delete it.' appears in the minibuffer 
> window.  Here, sometimes the normal frame is selected, sometimes the 
> minibuffer frame remains selected.  It might be a timing issue since 
> sometimes I see the cursor flicker at the end of the 'Type "q" ...' text 
> before it moves to the normal frame, provided it moves there.
>
> The strange thing that happens is when I now type "q" in the help 
> window.  Here the minibuffer window gets selected and ready to receive 
> input but no cursor is shown in it.  Do you see that?  Anyone else?
>

I can confirm this behavior.  It does not happen with Emacs 23 to 25, and 
happens with Emacs 26 to 28.  Except that:

"Now in the minibuffer window type C-h f and..." is (in my case at least) 
"Select the miniwindow frame, type C-h f, and..."

I did not see the "sometimes the normal frame is selected, sometimes the 
minibuffer frame remains selected", in my case at least the miniwindow 
frame remains selected in all cases.  Which means that I need to click in 
the *Help* buffer before typing "q".

"Here the minibuffer window gets selected and ready to receive input but 
no cursor is shown in it." is (in my case at least) "The minibuffer gets 
selected and ready to receive input but no cursor is shown in it AND the 
miniwindow frame is not raised (put above the main frame by the window 
manager)".

Another strange thing is that at that point a number of keys are bound to 
something, as if something like "C-x 5" was always pressed:

"b" says "Switch to buffer in other frame"
"f" says "Find file in other frame:"
"m" opens "mail"
"i" opens "info"
"n" creates a new frame

But it is not the "C-x 5" keymap, because "d" or "r" for example are not 
bound, and "n" is not bound in "C-x 5".

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

Gregory Heytings <ghe@sdf.org> writes:

> Another strange thing is that at that point a number of keys are bound
> to something, as if something like "C-x 5" was always pressed:
>
> "b" says "Switch to buffer in other frame"
> "f" says "Find file in other frame:"
> "m" opens "mail"
> "i" opens "info"
> "n" creates a new frame
>
> But it is not the "C-x 5" keymap, because "d" or "r" for example are
> not bound, and "n" is not bound in "C-x 5".

Those keys are from the 'minibuffer-inactive-mode-map' variable:

Keymap for use in the minibuffer when it is not active.
The non-mouse bindings in this keymap can only be used in minibuffer-only
frames, since the minibuffer can normally not be selected when it is
not active.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> Another strange thing is that at that point a number of keys are bound
 >> to something, as if something like "C-x 5" was always pressed:
 >>
 >> "b" says "Switch to buffer in other frame"
 >> "f" says "Find file in other frame:"
 >> "m" opens "mail"
 >> "i" opens "info"
 >> "n" creates a new frame
 >>
 >> But it is not the "C-x 5" keymap, because "d" or "r" for example are
 >> not bound, and "n" is not bound in "C-x 5".
 >
 > Those keys are from the 'minibuffer-inactive-mode-map' variable:
 >
 > Keymap for use in the minibuffer when it is not active.
 > The non-mouse bindings in this keymap can only be used in minibuffer-only
 > frames, since the minibuffer can normally not be selected when it is
 > not active.

Thanks for the explanation.  Maybe this is supposed to handle the limbo
state where the WM focuses the minibuffer-onlly frame but Emacs doesn't
want or need that.  It might explain then that the minibuffer-only frame
gets focus initially.  The rationale behind this is nowhere described.

martin

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > I can confirm this behavior.

Which OS?

 > It does not happen with Emacs 23 to 25, and happens with Emacs 26 to 28.

That's interesting.  I'll have to take a look.

 > Except that:
 >
 > "Now in the minibuffer window type C-h f and..." is (in my case at least) "Select the miniwindow frame, type C-h f, and..."
 >
 > I did not see the "sometimes the normal frame is selected, sometimes
 > the minibuffer frame remains selected", in my case at least the
 > miniwindow frame remains selected in all cases.  Which means that I
 > need to click in the *Help* buffer before typing "q".

Same here, usually.  But I managed a few times to have the normal frame
selected.  In that case, as I mentioned, I quickly saw the cursor
flicker in the minibuffer window before it showed up on the normal
frame.  Also, instead of using the mouse, C-x 5 o followed by C-x o
works too, but C-x o used directly in the minibuffer window does not
work.

 > "Here the minibuffer window gets selected and ready to receive input
 > but no cursor is shown in it." is (in my case at least) "The
 > minibuffer gets selected and ready to receive input but no cursor is
 > shown in it AND the miniwindow frame is not raised (put above the main
 > frame by the window manager)".

One can use

(setq minibuffer-auto-raise t)

If I do that, then typing something into the minibuffer window in the
state where no cursor is seen, automatically switches to the normal
frame.

martin

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

 >  > It does not happen with Emacs 23 to 25, and happens with Emacs 26 to 28.
 >
 > That's interesting.  I'll have to take a look.

OK.  It was me who introduced that bug in Emacs 26.  Many thanks for
spotting it.

Can both of you confirm that reverting that change fixes the behavior?
Patch attached.

Thanks, martin

[-- Attachment #2: frame-redirect.diff --]
[-- Type: text/x-patch, Size: 686 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 512aaf5f45..f56176910e 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1426,11 +1426,7 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
       if (FRAMEP (gfocus))
 	{
 	  focus = FRAME_FOCUS_FRAME (XFRAME (gfocus));
-	  if ((FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
-	      /* Redirect frame focus also when FRAME has its minibuffer
-		 window on the selected frame (see Bug#24500).  */
-	      || (NILP (focus)
-		  && EQ (FRAME_MINIBUF_WINDOW (f), sf->selected_window)))
+	  if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
 	    Fredirect_frame_focus (gfocus, frame);
 	}
     }

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>>> It does not happen with Emacs 23 to 25, and happens with Emacs 26 to 
>>> 28.
>>
>> That's interesting.  I'll have to take a look.
>
> OK.  It was me who introduced that bug in Emacs 26.  Many thanks for 
> spotting it.
>
> Can both of you confirm that reverting that change fixes the behavior? 
> Patch attached.
>

Yes, it does.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> Can both of you confirm that reverting that change fixes the behavior? Patch attached.
 >>
 >
 > Yes, it does.

Fine.  I will push this to Emacs 27.2.

Thanks, martin

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Fine.  I will push this to Emacs 27.2.

Done.  Alan, the following two concerns are still awaiting a fix:


Madhu's:

These patches introduce a regression on "graphical" emacs -

1. emacs -Q

2. M-: (setq pop-up-frames 'graphic-only)

3. M-! g <TAB>

This should pop up a *Completions* buffer in a new frame.

On choosing the completion (via a button1 or by navigating to the
desired point and typing RET) - the frame should be automatically
hidden[1]

This doesn't happen anymore and the completion buffer and frame remain
there taking up focus.


[1] default value for frame-auto-hide-function is #'iconify-frame, but
if your window manager cannot iconify it, set
(setq frame-auto-hide-function #'delete-frame)


Andrii's:

It is not producing bugs for me, but changes behavior.

E.g. in emacs -Q:

1. Evaluate
   (select-frame-set-input-focus
    (make-frame '((minibuffer . only)
                  (left . 1.0))))
2. M-x
3. C-x 5 o

Before minibuffer-follows-selected-frame, the prompt stays in the
minibuffer-only frame.
On recent master, the prompt is moved to other frame leaving
minibuffer-only frame empty.  I can't report this as a bug.  Just
wondering why minibuffer-follows-selected-frame is set to t by default,
potentially changing someone's expected behavior.


martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Wed, Nov 25, 2020 at 10:25:46 +0100, martin rudalics wrote:
>  > Fine.  I will push this to Emacs 27.2.

> Done.  Alan, the following two concerns are still awaiting a fix:

OK.

> Madhu's:

> These patches introduce a regression on "graphical" emacs -

> 1. emacs -Q

> 2. M-: (setq pop-up-frames 'graphic-only)

> 3. M-! g <TAB>

> This should pop up a *Completions* buffer in a new frame.

> On choosing the completion (via a button1 or by navigating to the
> desired point and typing RET) - the frame should be automatically
> hidden[1]

> This doesn't happen anymore and the completion buffer and frame remain
> there taking up focus.

I've started looking at this.  It could take some time to resolve.

> [1] default value for frame-auto-hide-function is #'iconify-frame, but
> if your window manager cannot iconify it, set
> (setq frame-auto-hide-function #'delete-frame)


> Andrii's:

> It is not producing bugs for me, but changes behavior.

This is inevitable, even if regrettable.

> E.g. in emacs -Q:

> 1. Evaluate
>    (select-frame-set-input-focus
>     (make-frame '((minibuffer . only)
>                   (left . 1.0))))
> 2. M-x
> 3. C-x 5 o

> Before minibuffer-follows-selected-frame, the prompt stays in the
> minibuffer-only frame.
> On recent master, the prompt is moved to other frame leaving
> minibuffer-only frame empty.  I can't report this as a bug.  Just
> wondering why minibuffer-follows-selected-frame is set to t by default,
> potentially changing someone's expected behavior.

The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves with
a frame switch, sometimes it doesn't.  The change in master is intended
to make the behaviour logical and systematic.

As to why minibuffer-follows-selected-frame is t by default, there is no
particular reason.  It transpired that Eli and I had different mental
models of the connection between minibuffers and frames.  The setting t
represents Eli's model rather than mine (?ours).  Setting it to nil by
default would also cause annoyance, in different ways.

Also, how often do people actually select minibuffer-only frames?
Unless I'm missing something, it seems a rather strange thing to want to
do.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves with 
> a frame switch, sometimes it doesn't.
>

I wouldn't write it is "chaotic".  The behavior you consider "chaotic" is 
well-defined, and has been there since Emacs 21 at least: the minibuffer 
moves from frame F1 to frame F2 if and only if the minibuffer is active on 
frame F1 and a recursive minibuffer is entered on frame F2.  There are 
other possible behaviors of course, but IMO the current one is a 
reasonable one.

>
> Also, how often do people actually select minibuffer-only frames? Unless 
> I'm missing something, it seems a rather strange thing to want to do.
>

There are at least two Emacs users on this list who use minibuffer-only 
frames: Stefan and Drew.  I'm also curious why they do this, and would be 
interested if they could explain what the benefit of doing this is.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Wed, Nov 25, 2020 at 21:31:13 +0000, Gregory Heytings wrote:


> > The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves with 
> > a frame switch, sometimes it doesn't.

> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" is 
> well-defined, and has been there since Emacs 21 at least: the minibuffer 
> moves from frame F1 to frame F2 if and only if the minibuffer is active on 
> frame F1 and a recursive minibuffer is entered on frame F2.

I'm not sure what you mean by "is" in that sentence.

> There are other possible behaviors of course, but IMO the current one
> is a reasonable one.

If a recursive minibuffer operation has been carried out, then the
minibuffer moves, if it hasn't it doesn't.  That means Emacs has some
invisible internal state, something which doesn't seem desirable.

> > Also, how often do people actually select minibuffer-only frames? Unless 
> > I'm missing something, it seems a rather strange thing to want to do.

> There are at least two Emacs users on this list who use minibuffer-only 
> frames: Stefan and Drew.

Sorry, I don't think I was clear.  By "select .... frames" I meant the
operation of making the minibuffer frame the current frame, not the
chosing of an Emacs setup which includes minibuffer-only frames.  Such a
minibuffer-only frame comes into operation whenever a minibuffer action
is invoked in another frame, but actually selecting it independently of
such a minibuffer action?

> I'm also curious why they do this, and would be interested if they
> could explain what the benefit of doing this is.

It's also not a setup I would want to use.  By preference, I use the
Linux tty and only ever have one frame on the screen at a time.  But I
can imagine people wanting their interactive minibuffer always to be in
the same place on a GUI screen.  Or something like that.  Maybe Stefan or
Drew will answer this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>>> The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves 
>>> with a frame switch, sometimes it doesn't.
>>
>> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" 
>> is well-defined, and has been there since Emacs 21 at least: the 
>> minibuffer moves from frame F1 to frame F2 if and only if the 
>> minibuffer is active on frame F1 and a recursive minibuffer is entered 
>> on frame F2.
>
> I'm not sure what you mean by "is" in that sentence.
>

I've reread what I wrote five times, and I don't understand the question 
;-)

>> There are other possible behaviors of course, but IMO the current one 
>> is a reasonable one.
>
> If a recursive minibuffer operation has been carried out, then the 
> minibuffer moves, if it hasn't it doesn't. That means Emacs has some 
> invisible internal state, something which doesn't seem desirable.
>

What do you mean?  By definition a recursive minibuffer is entered when a 
minibuffer has been entered and not yet left, that is, when the operation 
has not yet been completed.  After typing C-x C-f in frame F1 and M-: in 
frame F2, the two minibuffers have been moved to frame F2.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Wed, Nov 25, 2020 at 22:23:17 +0000, Gregory Heytings wrote:

> >>> The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves 
> >>> with a frame switch, sometimes it doesn't.

> >> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" 
> >> is well-defined, and has been there since Emacs 21 at least: the 
> >> minibuffer moves from frame F1 to frame F2 if and only if the 
> >> minibuffer is active on frame F1 and a recursive minibuffer is entered 
> >> on frame F2.

> > I'm not sure what you mean by "is" in that sentence.


> I've reread what I wrote five times, and I don't understand the question 
> ;-)

It seems somewhat indefinite _when_ the recursive minibuffer "is"
entered on frame F2, relative to the other operations.

> >> There are other possible behaviors of course, but IMO the current one 
> >> is a reasonable one.

> > If a recursive minibuffer operation has been carried out, then the 
> > minibuffer moves, if it hasn't it doesn't. That means Emacs has some 
> > invisible internal state, something which doesn't seem desirable.


> What do you mean?

In Emacs 27, emacs -Q, C-x 5 2, giving a two-frame setup.  In F1, C-x b.
C-x 5 o, moving to F2.  C-r SPACE.  Note that the open minibuffer
remains on F1.

Now type C-x 8 RET SPACE RET.  This sucks the open minibuffer over to
F2, despite the C-r operation having nothing to do with the suspended
operation in the minibuffer.  This is not good and has been/is in the
process of being fixed for Emacs 28.

> By definition a recursive minibuffer is entered when a minibuffer has
> been entered and not yet left, that is, when the operation has not yet
> been completed.  After typing C-x C-f in frame F1 and M-: in frame F2,
> the two minibuffers have been moved to frame F2.

More precisely, if we're talking about Emacs 28 with
minibuffer-follows-selected-frame at its default of t, the C-x C-f
minibuffer moves to F2 when F2 gets selected.  The M-: then gives an
error message in F2, or (when enable-recursive-minibuffers is t) opens a
recursive minibuffer in F2.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

Hi Alan,

>>>>> The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves 
>>>>> with a frame switch, sometimes it doesn't.
>>>>
>>>> I wouldn't write it is "chaotic".  The behavior you consider 
>>>> "chaotic" is well-defined, and has been there since Emacs 21 at 
>>>> least: the minibuffer moves from frame F1 to frame F2 if and only if 
>>>> the minibuffer is active on frame F1 and a recursive minibuffer is 
>>>> entered on frame F2.
>>>
>>> I'm not sure what you mean by "is" in that sentence.
>>
>> I've reread what I wrote five times, and I don't understand the 
>> question ;-)
>
> It seems somewhat indefinite _when_ the recursive minibuffer "is" 
> entered on frame F2, relative to the other operations.
>

No it is not.  Another, perhaps more precise definition would be: in Emacs 
21 to 27, when minibuffers MB1 to MBn are active on a frame F1, and an 
operation which activates the minibuffer is used on a frame F2, the 
minibuffers MB1 to MBn are moved to frame F2, and the minibuffer MBn+1 is 
created.

>>>> There are other possible behaviors of course, but IMO the current one 
>>>> is a reasonable one.
>>>
>>> If a recursive minibuffer operation has been carried out, then the 
>>> minibuffer moves, if it hasn't it doesn't. That means Emacs has some 
>>> invisible internal state, something which doesn't seem desirable.
>>
>> What do you mean?
>
> In Emacs 27, emacs -Q, C-x 5 2, giving a two-frame setup.  In F1, C-x b. 
> C-x 5 o, moving to F2.  C-r SPACE.  Note that the open minibuffer 
> remains on F1.
>

Yes, this is normal, C-r does not use the minibuffer, but the echo area 
(you can see this because the cursor does not move leave the buffer in 
which you are).  The minibuffers and echo area are both displayed in the 
miniwindow, but they are different.

>
> Now type C-x 8 RET SPACE RET.  This sucks the open minibuffer over to 
> F2, despite the C-r operation having nothing to do with the suspended 
> operation in the minibuffer.
>

This is normal again, C-x 8 RET starts an operation which uses the 
minibuffer, and the cursor leaves the buffer in which you are and moves to 
the miniwindow.  As explained above, when an operation which activates a 
minibuffer is used on a frame while other minibuffers are active on 
another frame, they are moved to that frame.  I honestly can't see what's 
wrong with this.

IMO the only other reasonable behavior is to make sure that _all_ 
minibuffers are moved from frame F1 to frame F2 whenever one switches from 
a frame F1 to a frame F2.  This is not feasible with Emacs 21-27, and 
still not feasible with Emacs 28.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> Now type C-x 8 RET SPACE RET.  This sucks the open minibuffer over to 
>> F2, despite the C-r operation having nothing to do with the suspended 
>> operation in the minibuffer.
>
> This is normal again, C-x 8 RET starts an operation which uses the 
> minibuffer, and the cursor leaves the buffer in which you are and moves 
> to the miniwindow.  As explained above, when an operation which 
> activates a minibuffer is used on a frame while other minibuffers are 
> active on another frame, they are moved to that frame.  I honestly can't 
> see what's wrong with this.
>
> IMO the only other reasonable behavior is to make sure that _all_ 
> minibuffers are moved from frame F1 to frame F2 whenever one switches 
> from a frame F1 to a frame F2.  This is not feasible with Emacs 21-27, 
> and still not feasible with Emacs 28.
>

I wrote too fast here: this is feasible with Emacs 28 (by setting 
minibuffer-follows-selected-frame to t, which is its default value), but 
there is no way to get the previous behavior of Emacs 21-27.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Fri, Nov 27, 2020 at 10:47:49 +0000, Gregory Heytings wrote:

[ .... ]

> > IMO the only other reasonable behavior is to make sure that _all_
> > minibuffers are moved from frame F1 to frame F2 whenever one switches
> > from a frame F1 to a frame F2.  This is not feasible with Emacs
> > 21-27, and still not feasible with Emacs 28.

> I wrote too fast here: this is feasible with Emacs 28 (by setting 
> minibuffer-follows-selected-frame to t, which is its default value), but 
> there is no way to get the previous behavior of Emacs 21-27.

The behaviour in Emacs 21-27 was unsatisfactory.  Eli and I agreed this
earlier on in this thread, and explicitly agreed the new behaviour would
be different.

That earlier behaviour was agreed to be chaotic, and would be very
difficult to restore without breaking the recent changes in this area.

What, in particular, do you miss from the old behaviour?  If it's something
specific, maybe it would be possible to add it in, somehow.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

Hi Alan,

>
> The behaviour in Emacs 21-27 was unsatisfactory.  Eli and I agreed this 
> earlier on in this thread, and explicitly agreed the new behaviour would 
> be different.
>
> That earlier behaviour was agreed to be chaotic, and would be very 
> difficult to restore without breaking the recent changes in this area.
>
> What, in particular, do you miss from the old behaviour?  If it's 
> something specific, maybe it would be possible to add it in, somehow.
>

Simply: the old behavior.

I agree that a new option "minibuffer-follows-selected-frame" would be 
welcome, and I also agree that it can be set to t by default in Emacs 28, 
but setting it to nil should restore the behavior of Emacs 21-27.

Changing the longstanding behavior of something as central to Emacs as the 
minibuffer just because two people agree that it is "chaotic", while many 
have been using it for decades without complaining, and without giving 
those who for one reason or another like/rely on the old behavior a way to 
restore the old behavior, is just wrong IMO.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Fri, Nov 27, 2020 at 10:36:35 +0000, Gregory Heytings wrote:

> Hi Alan,

> >>>>> The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves 
> >>>>> with a frame switch, sometimes it doesn't.

[ .... ]

> >>> If a recursive minibuffer operation has been carried out, then the 
> >>> minibuffer moves, if it hasn't it doesn't. That means Emacs has some 
> >>> invisible internal state, something which doesn't seem desirable.

> >> What do you mean?

> > In Emacs 27, emacs -Q, C-x 5 2, giving a two-frame setup.  In F1, C-x b. 
> > C-x 5 o, moving to F2.  C-r SPACE.  Note that the open minibuffer 
> > remains on F1.


> Yes, this is normal, C-r does not use the minibuffer, but the echo area 
> (you can see this because the cursor does not move leave the buffer in 
> which you are).  The minibuffers and echo area are both displayed in the 
> miniwindow, but they are different.


> > Now type C-x 8 RET SPACE RET.  This sucks the open minibuffer over to 
> > F2, despite the C-r operation having nothing to do with the suspended 
> > operation in the minibuffer.


> This is normal again, C-x 8 RET starts an operation which uses the 
> minibuffer, and the cursor leaves the buffer in which you are and moves to 
> the miniwindow.  As explained above, when an operation which activates a 
> minibuffer is used on a frame while other minibuffers are active on 
> another frame, they are moved to that frame.  I honestly can't see what's 
> wrong with this.

I can see a lot wrong with it, from a UI point of view.  Whether the MB
gets moved depends on _how_ a user enters characters into C-r.  This is
bad.  The MB should either move when you type C-r or it shouldn't.  Emacs
28 fixes this.

Also we shouldn't force users to have to understand the difference
between the echo area and the minibuffer.  Some of them will understand,
many will not.  That most of isearch uses the echo area, but some of it
uses the minibuffer, is an arcane implementation issue which users
shouldn't have to worry about.  We should leave them in peace.

> IMO the only other reasonable behavior is to make sure that _all_ 
> minibuffers are moved from frame F1 to frame F2 whenever one switches from 
> a frame F1 to a frame F2.  This is not feasible with Emacs 21-27, and 
> still not feasible with Emacs 28.

As you note in your next post, it is feasible with Emacs 28, or at least
will be when the bugs are fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

Hi Alan,

>> This is normal again, C-x 8 RET starts an operation which uses the 
>> minibuffer, and the cursor leaves the buffer in which you are and moves 
>> to the miniwindow.  As explained above, when an operation which 
>> activates a minibuffer is used on a frame while other minibuffers are 
>> active on another frame, they are moved to that frame.  I honestly 
>> can't see what's wrong with this.
>
> I can see a lot wrong with it, from a UI point of view.  Whether the MB 
> gets moved depends on _how_ a user enters characters into C-r.  This is 
> bad.  The MB should either move when you type C-r or it shouldn't.
>

I disagree with that explanation.  You do not "enter characters into C-r". 
When you type characters after typing C-r, they are displayed in the echo 
area, but that doesn't mean you enter them there: the cursor does not move 
there.  When you type C-x 8 RET, the cursor moves into the miniwindow, and 
at that point you type characters in a minibuffer.

>
> Emacs 28 fixes this.
>

At the cost of breaking a longstanding behavior...

>
> Also we shouldn't force users to have to understand the difference 
> between the echo area and the minibuffer.  Some of them will understand, 
> many will not.
>

That's a basic thing to learn when you use Emacs.  And it's easy to 
understand: the echo area is for "status messages" with which you do not 
interact (and this is visible because the point does not leave the buffer 
in which you are), minibuffers are for "commands" with which you interact 
(and this is visible because the point moves from the buffer in which you 
are to the miniwindow).

>
> That most of isearch uses the echo area, but some of it uses the 
> minibuffer, is an arcane implementation issue which users shouldn't have 
> to worry about.  We should leave them in peace.
>

I doubt a user who does not understand the difference between the echo 
area and the minibuffer would use C-x 8 RET during an isearch.  And even 
then, with the above explanation that difference is easy to understand.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > That's a basic thing to learn when you use Emacs.  And it's easy to
 > understand: the echo area is for "status messages" with which you do
 > not interact (and this is visible because the point does not leave the
 > buffer in which you are), minibuffers are for "commands" with which
 > you interact (and this is visible because the point moves from the
 > buffer in which you are to the miniwindow).

It's not so easy.  With Emacs 26, 'y-or-n-p' still used the echo area
for answering questions.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> That's a basic thing to learn when you use Emacs.  And it's easy to 
>> understand: the echo area is for "status messages" with which you do 
>> not interact (and this is visible because the point does not leave the 
>> buffer in which you are), minibuffers are for "commands" with which you 
>> interact (and this is visible because the point moves from the buffer 
>> in which you are to the miniwindow).
>
> It's not so easy.  With Emacs 26, 'y-or-n-p' still used the echo area 
> for answering questions.
>

Okay, there are (or rather, IIUC, there were) exceptions to that general 
rule ;-)  But I think you meant Emacs 25 and earlier, with my Emacs 26 
y-or-n-p does use the minibuffer.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > But I think you meant Emacs 25 and earlier, with my Emacs 26 y-or-n-p
 > does use the minibuffer.

This time I did read the NEWS entry.  For Emacs 27.1 it says

*** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> But I think you meant Emacs 25 and earlier, with my Emacs 26 y-or-n-p 
>> does use the minibuffer.
>
> This time I did read the NEWS entry.  For Emacs 27.1 it says
>
> *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.
>

Never trust the documentation ;-)

(progn (setq frame-title-format "%b") (y-or-n-p "*Minibuf-1*?"))

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Never trust the documentation ;-)
 >
 > (progn (setq frame-title-format "%b") (y-or-n-p "*Minibuf-1*?"))

Never trust 'frame-title-format' ;-)

(progn
   (display-buffer (get-buffer-create " *Echo Area 1*"))
   (y-or-n-p "......"))

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> Never trust the documentation ;-)
>>
>> (progn (setq frame-title-format "%b") (y-or-n-p "*Minibuf-1*?"))
>
> Never trust 'frame-title-format' ;-)
>
> (progn
>  (display-buffer (get-buffer-create " *Echo Area 1*"))
>  (y-or-n-p "......"))
>

Whoops, indeed, you are correct.  I accidentally changed a link on my 
computer a few days ago, and what I thought was Emacs 26 was in fact Emacs 
27.  Sorry for the noise!

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 27 Nov 2020 17:43:14 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, emacs-devel@gnu.org,
>         enometh@meer.net, Stefan Monnier <monnier@iro.umontreal.ca>,
>         Alan Mackenzie <acm@muc.de>, Eli Zaretskii <eliz@gnu.org>
> 
> > This time I did read the NEWS entry.  For Emacs 27.1 it says
> >
> > *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.
> >
> 
> Never trust the documentation ;-)
> 
> (progn (setq frame-title-format "%b") (y-or-n-p "*Minibuf-1*?"))

This tells me Emacs 26 didn't use the minibuffer.

How did you evaluate this?  You should do it with "C-x C-e", not with
"M-:".

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > I wouldn't write it is "chaotic".  The behavior you consider "chaotic"
 > is well-defined, and has been there since Emacs 21 at least: the
 > minibuffer moves from frame F1 to frame F2 if and only if the
 > minibuffer is active on frame F1 and a recursive minibuffer is entered
 > on frame F2.  There are other possible behaviors of course, but IMO
 > the current one is a reasonable one.

The basic behavioral change I see is with 'enable-recursive-minibuffers'
non-nil and two frames: When I type C-h f setq in the first frame and
C-h f cons in the second frame, hit RET, reselect the minibuffer window
and hit RET again, with Emacs 27 a help window pops up in the first
frame while Emacs 28 reuses the help window of the second frame.  In
both cases the second RET goes to the second frame and both behaviors
seem reasonable to me.

If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,
the behavior does not entirely match that of Emacs 27 because the second
RET must be typed in the first frame.  So if some application relies on
the exact replication of the behavior of Emacs 27, we have a regression.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" 
>> is well-defined, and has been there since Emacs 21 at least: the 
>> minibuffer moves from frame F1 to frame F2 if and only if the 
>> minibuffer is active on frame F1 and a recursive minibuffer is entered 
>> on frame F2.  There are other possible behaviors of course, but IMO the 
>> current one is a reasonable one.
>
> The basic behavioral change I see is with 'enable-recursive-minibuffers' 
> non-nil and two frames: When I type C-h f setq in the first frame and 
> C-h f cons in the second frame, hit RET, reselect the minibuffer window 
> and hit RET again, with Emacs 27 a help window pops up in the first 
> frame while Emacs 28 reuses the help window of the second frame.  In 
> both cases the second RET goes to the second frame and both behaviors 
> seem reasonable to me.
>
> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil, 
> the behavior does not entirely match that of Emacs 27 because the second 
> RET must be typed in the first frame.  So if some application relies on 
> the exact replication of the behavior of Emacs 27, we have a regression.
>

Note that this patch and discussion started with the following observation 
(on Oct 13):

> (i) Have two frames open displaying buffers.
> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
> (iii) Move to F2.
> (iv) Do C-x 8 RET <enter some character>.
> F1's minibuffer is now on F2.  This is bad.

It is indeed not possible to replicate the behavior of Emacs 27 and 
earlier.  What we have is, for example:

   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
A | MB1 on F1   | MB1 on F2                      | MB1 on F1
B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]

A: type C-x C-f on frame F1, switch to frame F2
B: type C-x C-f on frame F1, switch to frame F2, type M-:

[1] There is also a severe regression in this case.  Type C-x C-f on frame 
F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
miniwindow on frame F1; switch to frame F1.

Experiment 1: Type the name of a file and RET.  You'll get the error 
message "End of file during parsing", and MB2 on frame F2 will be left. 
MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
you do.

Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
will stay in MB1 on frame F1.  However you cannot use it anymore, the 
keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
1, you cannot leave it.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

[Apparently this email I sent a few hours ago did not reach the mailing 
list.  I apologize if you receive it twice.]

>> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" 
>> is well-defined, and has been there since Emacs 21 at least: the 
>> minibuffer moves from frame F1 to frame F2 if and only if the 
>> minibuffer is active on frame F1 and a recursive minibuffer is entered 
>> on frame F2.  There are other possible behaviors of course, but IMO the 
>> current one is a reasonable one.
>
> The basic behavioral change I see is with 'enable-recursive-minibuffers' 
> non-nil and two frames: When I type C-h f setq in the first frame and 
> C-h f cons in the second frame, hit RET, reselect the minibuffer window 
> and hit RET again, with Emacs 27 a help window pops up in the first 
> frame while Emacs 28 reuses the help window of the second frame.  In 
> both cases the second RET goes to the second frame and both behaviors 
> seem reasonable to me.
>
> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil, 
> the behavior does not entirely match that of Emacs 27 because the second 
> RET must be typed in the first frame.  So if some application relies on 
> the exact replication of the behavior of Emacs 27, we have a regression.
>

Note that this patch and discussion started with the following observation 
(on Oct 13):

> (i) Have two frames open displaying buffers.
> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
> (iii) Move to F2.
> (iv) Do C-x 8 RET <enter some character>.
> F1's minibuffer is now on F2.  This is bad.

It is indeed not possible to replicate the behavior of Emacs 27 and 
earlier.  What we have is, for example:

   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
A | MB1 on F1   | MB1 on F2                      | MB1 on F1
B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]

A: type C-x C-f on frame F1, switch to frame F2
B: type C-x C-f on frame F1, switch to frame F2, type M-:

[1] There is also a severe regression in this case.  Type C-x C-f on frame 
F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
miniwindow on frame F1; switch to frame F1.

Experiment 1: Type the name of a file and RET.  You'll get the error 
message "End of file during parsing", and MB2 on frame F2 will be left. 
MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
you do.

Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
will stay in MB1 on frame F1.  However you cannot use it anymore, the 
keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
1, you cannot leave it.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Note that this patch and discussion started with the following observation (on Oct 13):
 >
 >> (i) Have two frames open displaying buffers.
 >> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
 >> (iii) Move to F2.
 >> (iv) Do C-x 8 RET <enter some character>.
 >> F1's minibuffer is now on F2.  This is bad.

But I see the same with Emacs 27.  After moving to F2, the minibuffer of
F1 appears there.  It's just that when I now confirm the prompt to switch
to *Messages*, that buffer appears in F2 with Emacs 28 whereas with
Emacs 27 it appeared in F1 (with 'minibuffer-follows-selected-frame' at
its default t).

 > It is indeed not possible to replicate the behavior of Emacs 27 and earlier.  What we have is, for example:
 >
 >   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
 > A | MB1 on F1   | MB1 on F2                      | MB1 on F1
 > B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]
 >
 > A: type C-x C-f on frame F1, switch to frame F2
 > B: type C-x C-f on frame F1, switch to frame F2, type M-:

Right.  Needs 'enable-recursive-minibuffers' non-nil to replicate.

 > [1] There is also a severe regression in this case.  Type C-x C-f on
 > frame F1, switch to frame F2, type M-:.  "Find file" is still visible
 > in the miniwindow on frame F1; switch to frame F1.
 >
 > Experiment 1: Type the name of a file and RET.  You'll get the error
 > message "End of file during parsing", and MB2 on frame F2 will be
 > left. MB1 is now unuseable, and impossible to leave, it will stay on
 > F1 whatever you do.

'keyboard-escape-quit' gets me out.  While this should be the last
resort only, it happened to me occasionally before Alan's changes.
Yet, your scenario must be fixed.

 > Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file"
 > will stay in MB1 on frame F1.  However you cannot use it anymore, the
 > keymap of MB1 is now minibuffer-inactive-mode-map.  And like in
 > experiment 1, you cannot leave it.

Bad indeed.  Must be fixed too.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> Note that this patch and discussion started with the following 
>> observation (on Oct 13):
>>
>>> (i) Have two frames open displaying buffers.
>>> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
>>> (iii) Move to F2.
>>> (iv) Do C-x 8 RET <enter some character>.
>>> F1's minibuffer is now on F2.  This is bad.
>
> But I see the same with Emacs 27.  After moving to F2, the minibuffer of 
> F1 appears there.
>

Are you sure?  You see the minibuffer moving from frame F1 to frame F2, 
without doing anything?  With Emacs 27?  I have Emacs 27.1, and do not see 
this, neither with graphical nor with terminal Emacs.

>> It is indeed not possible to replicate the behavior of Emacs 27 and
>> earlier.  What we have is, for example:
>>
>>   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
>> A | MB1 on F1   | MB1 on F2                      | MB1 on F1
>> B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]
>>
>> A: type C-x C-f on frame F1, switch to frame F2
>> B: type C-x C-f on frame F1, switch to frame F2, type M-:
>
> Right.  Needs 'enable-recursive-minibuffers' non-nil to replicate.
>

Or using a command which temporarily sets enable-recursive-minibuffers, 
like C-x 8 RET or C-h f or C-h w or...  But without 
enable-recursive-minibuffers this patch and discussion would not take 
place, you simply get a "Command attempted to use minibuffer while in 
minibuffer".  In any case, it is not possible to replicate the behavior of 
Emacs 21-27, which is IMO not a good thing, especially for something as 
central to Emacs as the minibuffer.

>> [1] There is also a severe regression in this case.  Type C-x C-f on 
>> frame F1, switch to frame F2, type M-:.  "Find file" is still visible 
>> in the miniwindow on frame F1; switch to frame F1.
>>
>> Experiment 1: Type the name of a file and RET.  You'll get the error 
>> message "End of file during parsing", and MB2 on frame F2 will be left. 
>> MB1 is now unuseable, and impossible to leave, it will stay on F1 
>> whatever you do.
>
> 'keyboard-escape-quit' gets me out.  While this should be the last 
> resort only, it happened to me occasionally before Alan's changes. Yet, 
> your scenario must be fixed.
>

Indeed, 'abort-recursive-edit' also works.  But as you write these 
commands should be used in last resort, especially as they are not known 
to newcomers.

>> Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
>> will stay in MB1 on frame F1.  However you cannot use it anymore, the 
>> keymap of MB1 is now minibuffer-inactive-mode-map.  And like in 
>> experiment 1, you cannot leave it.
>
> Bad indeed.  Must be fixed too.
>

IMO "fixing" in this case should be going back to the earlier state (the 
Emacs 21-27 behavior), and first trying to _precisely_ define the desired 
new behavior.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >>>> (i) Have two frames open displaying buffers.
 >>>> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
 >>>> (iii) Move to F2.
 >>>> (iv) Do C-x 8 RET <enter some character>.
 >>>> F1's minibuffer is now on F2.  This is bad.
 >>
 >> But I see the same with Emacs 27.  After moving to F2, the minibuffer of F1 appears there.
 >>
 >
 > Are you sure?  You see the minibuffer moving from frame F1 to frame
 > F2, without doing anything?  With Emacs 27?  I have Emacs 27.1, and do
 > not see this, neither with graphical nor with terminal Emacs.

Why "moving"?  The active minibuffer is already on F2 because after
(iii) I am on F2 and answered the C-x 8 prompt there.  With Emacs 27
built two days ago.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>>>>> (i) Have two frames open displaying buffers.
>>>>> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
>>>>> (iii) Move to F2.
>>>>> (iv) Do C-x 8 RET <enter some character>.
>>>>> F1's minibuffer is now on F2.  This is bad.
>>>
>>> But I see the same with Emacs 27.  After moving to F2, the minibuffer 
>>> of F1 appears there.
>>
>> Are you sure?  You see the minibuffer moving from frame F1 to frame F2, 
>> without doing anything?  With Emacs 27?  I have Emacs 27.1, and do not 
>> see this, neither with graphical nor with terminal Emacs.
>
> Why "moving"?  The active minibuffer is already on F2 because after 
> (iii) I am on F2 and answered the C-x 8 prompt there.  With Emacs 27 
> built two days ago.
>

Yes, and this is precisely the "bad" behavior Alan would like to fix.

With Emacs 28 (-Q), the active minibuffer is moved from frame F1 to frame 
F2 at step (iii), _before_ you answer the C-x 8 RET. That is, the active 
minibuffer is moved from frame F1 to frame F2 whenever you switch from 
frame F1 to frame F2.

With Emacs 21-27, this happens only at step (iv), _after_ you hit C-x 8 
RET.  That is, the active minibuffer is moved from frame F1 to frame F2 
only when you activate a new minibuffer on frame F2.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > With Emacs 28 (-Q), the active minibuffer is moved from frame F1 to
 > frame F2 at step (iii), _before_ you answer the C-x 8 RET. That is,
 > the active minibuffer is moved from frame F1 to frame F2 whenever you
 > switch from frame F1 to frame F2.
 >
 > With Emacs 21-27, this happens only at step (iv), _after_ you hit C-x
 > 8 RET.  That is, the active minibuffer is moved from frame F1 to frame
 > F2 only when you activate a new minibuffer on frame F2.

I understand you now.  With Emacs 27 the minibuffer window moves lazily
- that is, only when it's needed on some other frame - with Emacs 28 it
moves eagerly.  That doesn't look like a change for the better.  Alan,
couldn't we try to do that by giving 'minibuffer-follows-selected-frame'
a third value like 'on-demand and move only when the user really wants
to interact with the minibuffer on another frame?

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> With Emacs 28 (-Q), the active minibuffer is moved from frame F1 to 
>> frame F2 at step (iii), _before_ you answer the C-x 8 RET. That is, the 
>> active minibuffer is moved from frame F1 to frame F2 whenever you 
>> switch from frame F1 to frame F2.
>>
>> With Emacs 21-27, this happens only at step (iv), _after_ you hit C-x 8 
>> RET.  That is, the active minibuffer is moved from frame F1 to frame F2 
>> only when you activate a new minibuffer on frame F2.
>
> I understand you now.  With Emacs 27 the minibuffer window moves lazily 
> - that is, only when it's needed on some other frame - with Emacs 28 it 
> moves eagerly.  That doesn't look like a change for the better.  Alan, 
> couldn't we try to do that by giving 'minibuffer-follows-selected-frame' 
> a third value like 'on-demand and move only when the user really wants 
> to interact with the minibuffer on another frame?
>

Yes, AFAIU doing this would amount to make it possible to restore the 
Emacs 21-27 behavior, which would be a good thing.

BTW, this (to have three possible behaviors) is what I suggested as early 
as Oct 14.  This suggestion was totally ignored:

1. the Emacs 21-27 behavior, with which all recursive minibuffers are 
moved from one frame to another when one or more minibuffers are active in 
one frame, and a new recursive activation happens in another frame: that's 
what we lost

2. move all recursive minibuffers from one frame to the other when 
switching to another frame: that's what we now have with 
minibuffer-follows-selected-frame set to t, except that it doesn't work as 
it should (the result of the commands do not take place in the frame in 
which they were initiated)

3. tie each one of the recursive minibuffers to the frame in which it was 
activated: that's what we now have with minibuffer-follows-selected-frame 
set to nil, except that it doesn't work as it should (interacting with the 
minibuffers that are not the most recently entered one break things badly)

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.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > 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.

- 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.

But I think the main task for the moment is to fix the
'minibuffer-follows-selected-frame' nil behavior.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> 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.)

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> - 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.)

With 'minibuffer-follows-selected-frame' non-nil, the remainder of
'switch-to-buffer' simply runs on the frame where the prompt is answered
which is not necessarily the frame where C-x b was issued initially.

 > My feeling is also that "minibuffer-follows-selected-frame" is not a
 > good generic name for all these behaviors.

We have worse ones.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>>> - 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.)
>
> With 'minibuffer-follows-selected-frame' non-nil, the remainder of 
> 'switch-to-buffer' simply runs on the frame where the prompt is answered 
> which is not necessarily the frame where C-x b was issued initially.
>

Yes, and this is not what it is supposed to do.  The NEWS item says "the 
effect of what you type in the minibuffer happens in the frame where the 
minibuffer was first activated, even if it moved to another frame."

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory and Martin.

On Fri, Nov 27, 2020 at 07:33:04 +0000, Gregory Heytings wrote:

[ .... ]

>   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
> A | MB1 on F1   | MB1 on F2                      | MB1 on F1
> B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]

> A: type C-x C-f on frame F1, switch to frame F2
> B: type C-x C-f on frame F1, switch to frame F2, type M-:

> [1] There is also a severe regression in this case.  Type C-x C-f on frame 
> F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
> miniwindow on frame F1; switch to frame F1.

> Experiment 1: Type the name of a file and RET.  You'll get the error 
> message "End of file during parsing", and MB2 on frame F2 will be left. 
> MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
> you do.

> Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
> will stay in MB1 on frame F1.  However you cannot use it anymore, the 
> keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
> 1, you cannot leave it.

The abstract cause of this situation would appear to be using F1's
minibuffer while a more deeply nested minibuffer is still active.  It is
a violation of the "recursive" nature of these buffers.

I think a solution would be to put F1's minibuffer into
minibuffer-inactive-mode until the recursive MB in F2 has terminated.

What do you think of this?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

> Hello, Gregory and Martin.

On Sat, Nov 28, 2020 at 10:45:34 +0000, Alan Mackenzie wrote:

> On Fri, Nov 27, 2020 at 07:33:04 +0000, Gregory Heytings wrote:

> [ .... ]

> >   | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil)
> > A | MB1 on F1   | MB1 on F2                      | MB1 on F1
> > B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]

> > A: type C-x C-f on frame F1, switch to frame F2
> > B: type C-x C-f on frame F1, switch to frame F2, type M-:

> > [1] There is also a severe regression in this case.  Type C-x C-f on frame 
> > F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
> > miniwindow on frame F1; switch to frame F1.

> > Experiment 1: Type the name of a file and RET.  You'll get the error 
> > message "End of file during parsing", and MB2 on frame F2 will be left. 
> > MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
> > you do.

> > Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
> > will stay in MB1 on frame F1.  However you cannot use it anymore, the 
> > keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
> > 1, you cannot leave it.

> The abstract cause of this situation would appear to be using F1's
> minibuffer while a more deeply nested minibuffer is still active.  It is
> a violation of the "recursive" nature of these buffers.

> I think a solution would be to put F1's minibuffer into
> minibuffer-inactive-mode until the recursive MB in F2 has terminated.

> What do you think of this?

Here's a trial implementation, which doesn't quite put F1's MB into
minibuffer-inactive-mode, but sets its local keymap to the mode's
keymap.



diff --git a/src/minibuf.c b/src/minibuf.c
index fc3fd92a88..58e72bc4a4 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,6 +63,8 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
 static bool
 minibuf_follows_frame (void)
@@ -90,7 +92,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && !minibuf_follows_frame ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -411,6 +413,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +535,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -727,8 +732,26 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map;
+      if ((inactive_map =
+           find_symbol_value (intern ("minibuffer-inactive-mode-map")))
+          != Qunbound)
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the frame
+     back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    do_switch_frame (calling_frame, 1, 0, Qnil);
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -790,6 +813,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +883,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +920,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +935,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0



-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> A: type C-x C-f on frame F1, switch to frame F2
>> B: type C-x C-f on frame F1, switch to frame F2, type M-:
>
>> [1] There is also a severe regression in this case.  Type C-x C-f on frame 
>> F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
>> miniwindow on frame F1; switch to frame F1.
>
>> Experiment 1: Type the name of a file and RET.  You'll get the error 
>> message "End of file during parsing", and MB2 on frame F2 will be left. 
>> MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
>> you do.
>
>> Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
>> will stay in MB1 on frame F1.  However you cannot use it anymore, the 
>> keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
>> 1, you cannot leave it.
>
> The abstract cause of this situation would appear to be using F1's
> minibuffer while a more deeply nested minibuffer is still active.

More specifically, it's the act of leaving MB1 when there's a deeper MB2
active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or
`abort-recursive-edit`) doesn't actually pay attention to which
minibuffer is currently being used: while it's run from MB1 it actually
exits MB2.  I'm not completely sure why we end up with a broken state,
but I guess it's because some of the code that "deactivates" the
minibuffer upon exit in run in the minibuffer that the users thought they
were about to exit rather than in the one that is actually exited.

I expect that this is the core origin of the problem.

One way to address it might be to make every minibuffer use a different exit
tag (instead of the constant `exit` symbol), so that the `throw` will
not be caught by some unrelated `catch`.  Additionally, we may want to
tweak `exit-minibuffer` and `abort-recursive-edit` so that the user is
warned/prompted before "silently" canceling that other (deeper) minibuffer.

[ Another way to attack the problem would be to arrange it so that every
  minibuffer runs in its own thread, so you can exit one without
  affecting the other.  I think it might be an interesting direction,
  but it's probably not trivial.  In any case, cmpletely out of scope
  of the present problem.  ]


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> More specifically, it's the act of leaving MB1 when there's a deeper MB2 
> active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or 
> `abort-recursive-edit`) doesn't actually pay attention to which 
> minibuffer is currently being used: while it's run from MB1 it actually 
> exits MB2.  I'm not completely sure why we end up with a broken state, 
> but I guess it's because some of the code that "deactivates" the 
> minibuffer upon exit in run in the minibuffer that the users thought 
> they were about to exit rather than in the one that is actually exited.
>

Isn't the main reason for this that it has never been possible to interact 
with a MBn when a MBm, with m > n, was active?  IOW, that exit-minibuffer 
was so far only meant to be used for the most recent minibuffer?

BTW, I played a bit with this, and it seems that recursive minibuffers on 
more than two frames do not work correctly, since Emacs 21 at least. 
Here is a recipe you can try with Emacs 21-28:

emacs -Q
M-: (setq enable-recursive-minibuffers t) RET
C-x C-f ; create MB1 on frame F1
C-x 5 2
C-x C-f ; move MB1 to frame F2 and create MB2
C-x 5 2
C-x C-f .emacs RET ; create MB3 on frame F3, open file in frame F3
C-x o .emacs RET ; activate MB2 on frame F3, open file in frame F2

At that point MB2 is moved to frame F2, and is now unuseable (in 
minibuffer-inactive-mode).  You can either abort-recursive-edit (which 
works), or exit-recursive-edit (which, strangely, opens Dired on frame 
F1).

You can add more frames to the recipe, only the two last ones will work as 
expected.

What should have happened is that, at the end of the recipe, MB2 should 
have been exited and MB1 should be activated on frame F3, so that C-x o 
.emacs RET would open the file in frame F1.

>
> One way to address it might be to make every minibuffer use a different 
> exit tag (instead of the constant `exit` symbol), so that the `throw` 
> will not be caught by some unrelated `catch`.  Additionally, we may want 
> to tweak `exit-minibuffer` and `abort-recursive-edit` so that the user 
> is warned/prompted before "silently" canceling that other (deeper) 
> minibuffer.
>

Is such an added complexity really worth the price?

IMO the old behavior (with the bug above fixed) and a new behavior 
"minibuffer-follows-selected-frame" which would give a similar experience 
to that of using a minibuffer-only window, should be enough.  What is the 
added value of tying minibuffers to the frames in which they were created, 
compared to the price of implementing that feature?

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> More specifically, it's the act of leaving MB1 when there's a deeper MB2
>> active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or
>> `abort-recursive-edit`) doesn't actually pay attention to which minibuffer
>> is currently being used: while it's run from MB1 it actually exits MB2.
>> I'm not completely sure why we end up with a broken state, but I guess
>> it's because some of the code that "deactivates" the minibuffer upon exit
>> in run in the minibuffer that the users thought they were about to exit
>> rather than in the one that is actually exited.
> Isn't the main reason for this that it has never been possible to interact
> with a MBn when a MBm, with m > n, was active?

Well, it's at best an indirect cause of the bug, but yes, it's the
reason why this bug wasn't visible until now.

>> One way to address it might be to make every minibuffer use a different
>> exit tag (instead of the constant `exit` symbol), so that the `throw` will
>> not be caught by some unrelated `catch`.  Additionally, we may want to
>> tweak `exit-minibuffer` and `abort-recursive-edit` so that the user is
>> warned/prompted before "silently" canceling that other
>> (deeper) minibuffer.
> Is such an added complexity really worth the price?

I don't see much complexity here.  The main issue is not complexity but
the fact that it's a change, so there can be backward compatibility
issues (most likely the catcher will have catch both the old `exit` tag
as well as the new tag, in case some old code throws the `exit` tag
rather than going through `exit-minibuffer`).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> Isn't the main reason for this that it has never been possible to 
>> interact with a MBn when a MBm, with m > n, was active?
>
> Well, it's at best an indirect cause of the bug, but yes, it's the 
> reason why this bug wasn't visible until now.
>

Put another way, is it not problematic to interact with and/or terminate a 
recursive edit while one or more higher level recursive edits are 
underway?

Do you think the recipe with more than two frames I just sent demonstrates 
a bug?

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>>> Isn't the main reason for this that it has never been possible to
>>> interact with a MBn when a MBm, with m > n, was active?
>> Well, it's at best an indirect cause of the bug, but yes, it's the reason
>> why this bug wasn't visible until now.
> Put another way, is it not problematic to interact with and/or terminate
> a recursive edit while one or more higher level recursive edits
> are underway?

I think "interact with" should be OK (I can see situations where you'd
use two minibuffers, where you copy text from one to the other), but
since the invocations have to obey the nesting, exiting from the
non-deepest minibuffer is indeed a problem.

We could start by signaling an error when trying to exit the
non-deepest minibuffer?

> Do you think the recipe with more than two frames I just sent
> demonstrates a bug?

If you're referring to the recipe to which I responded, then yes.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]


>>>> Isn't the main reason for this that it has never been possible to 
>>>> interact with a MBn when a MBm, with m > n, was active?
>>>
>>> Well, it's at best an indirect cause of the bug, but yes, it's the 
>>> reason why this bug wasn't visible until now.
>>
>> Put another way, is it not problematic to interact with and/or 
>> terminate a recursive edit while one or more higher level recursive 
>> edits are underway?
>
> I think "interact with" should be OK (I can see situations where you'd 
> use two minibuffers, where you copy text from one to the other), but 
> since the invocations have to obey the nesting, exiting from the 
> non-deepest minibuffer is indeed a problem.
>

Okay, so I wasn't completely wrong when I said that tying minibuffers to 
the frames in which they are created is complex ;-)

If it becomes possible to interact with lower level minibuffers, typing 
".emacs RET" in a lower level minibuffer that was previously created with 
"C-x C-f" would open the file.  What would happen with the minibuffer at 
that point?  What should happen if it is entered again for example with 
C-x o?  Will it become a Schrödinger minibuffer that is neither alive nor 
dead?

>> Do you think the recipe with more than two frames I just sent 
>> demonstrates a bug?
>
> If you're referring to the recipe to which I responded, then yes.
>

I'm not sure what you mean by "the recipe to which I responded".  I meant 
the recipe I sent about an hour ago.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan, Gregory, and Martin.

On Sat, Nov 28, 2020 at 12:02:34 -0500, Stefan Monnier wrote:
> >> A: type C-x C-f on frame F1, switch to frame F2
> >> B: type C-x C-f on frame F1, switch to frame F2, type M-:

> >> [1] There is also a severe regression in this case.  Type C-x C-f on frame 
> >> F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
> >> miniwindow on frame F1; switch to frame F1.

> >> Experiment 1: Type the name of a file and RET.  You'll get the error 
> >> message "End of file during parsing", and MB2 on frame F2 will be left. 
> >> MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
> >> you do.

> >> Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
> >> will stay in MB1 on frame F1.  However you cannot use it anymore, the 
> >> keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
> >> 1, you cannot leave it.

> > The abstract cause of this situation would appear to be using F1's
> > minibuffer while a more deeply nested minibuffer is still active.

> More specifically, it's the act of leaving MB1 when there's a deeper MB2
> active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or
> `abort-recursive-edit`) doesn't actually pay attention to which
> minibuffer is currently being used: while it's run from MB1 it actually
> exits MB2.  I'm not completely sure why we end up with a broken state,
> but I guess it's because some of the code that "deactivates" the
> minibuffer upon exit in run in the minibuffer that the users thought they
> were about to exit rather than in the one that is actually exited.

> I expect that this is the core origin of the problem.

> One way to address it might be to make every minibuffer use a different exit
> tag (instead of the constant `exit` symbol), so that the `throw` will
> not be caught by some unrelated `catch`.  Additionally, we may want to
> tweak `exit-minibuffer` and `abort-recursive-edit` so that the user is
> warned/prompted before "silently" canceling that other (deeper) minibuffer.

> [ Another way to attack the problem would be to arrange it so that every
>   minibuffer runs in its own thread, so you can exit one without
>   affecting the other.  I think it might be an interesting direction,
>   but it's probably not trivial.  In any case, cmpletely out of scope
>   of the present problem.  ]

I haven't paid too much attention to the above.  But I do have a patch
which addresses the problem by removing the minibuffer key map from
outer level minibuffers, and giving them minibuffer-inactive-mode-map
instead.

Gregory, the patch is intended to restore at least part of the former
behaviour.  Set minibuffer-follows-selected-frame to a non-nil, not-t
value (such as 'hybrid), and minibuffers will move onto a selected frame
when the user invokes a minibuffer on that frame.  I think that's what
you wanted.

The patch might also fix your (Gregory's) problem with three frames and
three minibuffers.  I'm not sure.

Also, the patch is incomplete - the customsation entry in cus-start.el
needs amending, as do the Emacs manual and (probably) the NEWS entry.

Any testing you could do would be most appreciated.  Thanks!



diff --git a/src/minibuf.c b/src/minibuf.c
index fc3fd92a88..9db95c8381 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,38 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ())
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
     {
       Lisp_Object tail, frame;
+      Lisp_Object buffer = nth_minibuffer (minibuf_level - 1);
+      struct frame *sf = XFRAME (selected_frame);
 
       FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
+        if (!EQ (frame, selected_frame)
+            && minibuf_level > 1)
+        {
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame)))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+          if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents,
+                  buffer))
+            {
+              set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+              set_window_buffer (XFRAME (frame)->minibuffer_window,
+                                 get_minibuffer (0), 0, 0);
+            }
+        }
     }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -411,6 +444,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +566,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -727,8 +763,33 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map;
+      if ((inactive_map =
+           find_symbol_value (intern ("minibuffer-inactive-mode-map")))
+          != Qunbound)
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     frame back to the calling frame.  Also switch the current window
+     away from the expired minibuffer window.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    {
+      Fset_frame_selected_window (selected_frame,
+                                  Fprevious_window (minibuf_window,
+                                                    Qnil, Qnil),
+                                  Qnil);
+      do_switch_frame (calling_frame, 1, 0, Qnil);
+    }
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -790,6 +851,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +921,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +958,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +973,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
@@ -2035,13 +2111,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minniffer.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,



>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Thu, Nov 26, 2020 at 16:44:11 +0100, martin rudalics wrote:
>  > I wouldn't write it is "chaotic".  The behavior you consider "chaotic"
>  > is well-defined, and has been there since Emacs 21 at least: the
>  > minibuffer moves from frame F1 to frame F2 if and only if the
>  > minibuffer is active on frame F1 and a recursive minibuffer is entered
>  > on frame F2.  There are other possible behaviors of course, but IMO
>  > the current one is a reasonable one.

> The basic behavioral change I see is with
> 'enable-recursive-minibuffers' non-nil and two frames: When I type C-h
> f setq in the first frame and C-h f cons in the second frame, hit RET,
> reselect the minibuffer window and hit RET again, with Emacs 27 a help
> window pops up in the first frame while Emacs 28 reuses the help window
> of the second frame.  In both cases the second RET goes to the second
> frame and both behaviors seem reasonable to me.

> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,

Do you mean "to nil", here?  That variable is non-nil by default.

> the behavior does not entirely match that of Emacs 27 because the second
> RET must be typed in the first frame.  So if some application relies on
> the exact replication of the behavior of Emacs 27, we have a regression.

Well the new behaviour is explicitly not wholly compatible with the old.
I'm not sure that counts as a regression.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,
 >
 > Do you mean "to nil", here?  That variable is non-nil by default.

Right.  I meant "to nil" here.

 >> the behavior does not entirely match that of Emacs 27 because the second
 >> RET must be typed in the first frame.  So if some application relies on
 >> the exact replication of the behavior of Emacs 27, we have a regression.
 >
 > Well the new behaviour is explicitly not wholly compatible with the old.
 > I'm not sure that counts as a regression.

Having a customizable variable like 'minibuffer-follows-selected-frame'
whose purpose is to get back the old behavior, should also provide that
old behavior as faithfully as possible IMHO.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Fri, Nov 27, 2020 at 11:36:47 +0100, martin rudalics wrote:
>  >> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,

>  > Do you mean "to nil", here?  That variable is non-nil by default.

> Right.  I meant "to nil" here.

>  >> the behavior does not entirely match that of Emacs 27 because the second
>  >> RET must be typed in the first frame.  So if some application relies on
>  >> the exact replication of the behavior of Emacs 27, we have a regression.

>  > Well the new behaviour is explicitly not wholly compatible with the old.
>  > I'm not sure that counts as a regression.

> Having a customizable variable like 'minibuffer-follows-selected-frame'
> whose purpose is to get back the old behavior, should also provide that
> old behavior as faithfully as possible IMHO.

That is not the purpose of the variable.  The purpose is to be able to
chose between mental models of a minibuffer in a frame.  Eli's mental
model is that the MB represents the action which should be performed
next.  Mine is that a MB is part of the frame it is opened in.  So Eli
gets to leave m-f-s-f at t, I get to set it to nil.

The old behaviour was chaotic and unsystematic, and Eli and I agreed
this earlier on in the thread.  The recent changes were an attempt to
bring the behaviour back, at least partially, to something systematic.
The new variable m-f-s-f should enable a user to set the behaviour she
wants.  Maybe there's something missing (aside from bugs which still
need fixing).

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Cc: Gregory Heytings <ghe@sdf.org>, Andrii Kolomoiets
>  <andreyk.mad@gmail.com>, emacs-devel@gnu.org, enometh@meer.net,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 27 Nov 2020 11:36:47 +0100
> 
> Having a customizable variable like 'minibuffer-follows-selected-frame'
> whose purpose is to get back the old behavior, should also provide that
> old behavior as faithfully as possible IMHO.

The NEWS entry clearly says that the old behavior is no longer
available, so getting back the old behavior is not the purpose of that
variable.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> Having a customizable variable like 'minibuffer-follows-selected-frame' 
>> whose purpose is to get back the old behavior, should also provide that 
>> old behavior as faithfully as possible IMHO.
>
> The NEWS entry clearly says that the old behavior is no longer 
> available, so getting back the old behavior is not the purpose of that 
> variable.
>

I hope that does not mean "end of discussion".

I sent two recipes to Martin a few hours ago, which demonstrate that the 
behavior with that variable set to nil is broken.  Again it is surprising 
that such a radical change was accepted without testing these cases, which 
are obvious cases to test.

The NEWS entry says "Nevertheless, the effect of what you type in the 
minibuffer happens in the frame where the minibuffer was first activated, 
even if it moved to another frame."  This is not correct.  Three recipes:

emacs -Q
C-x 5 2
C-x C-f
C-x 5 o
C-x o
.emacs RET

The file is opened in the frame in which you are, not in the frame in 
which C-x C-f was entered.

Another recipe:

emacs -Q
C-x 5 2
C-h f setq
C-x 5 o
C-x o
RET

The *Help* buffer is displayed in the frame in which you are, not in the 
frame in which C-h f setq was entered.

Yet another recipe, similar to the one with which this discussion started:

emacs -Q
C-x 5 2
C-x b
C-x 5 o
C-x o
RET

The buffer is displayed in the frame in which you are, not in the frame in 
which C-x b was entered.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> emacs -Q
> C-x 5 2
> C-x C-f
> C-x 5 o
> C-x o
> .emacs RET
>
> The file is opened in the frame in which you are, not in the frame in which
> C-x C-f was entered.

Looks like a bug, indeed.  I recommend filing at via `M-x
report-emacs-bug` so it's not forgotten.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 27 Nov 2020 13:43:27 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: martin rudalics <rudalics@gmx.at>, andreyk.mad@gmail.com,
>         emacs-devel@gnu.org, enometh@meer.net, monnier@iro.umontreal.ca,
>         acm@muc.de
> 
> >> Having a customizable variable like 'minibuffer-follows-selected-frame' 
> >> whose purpose is to get back the old behavior, should also provide that 
> >> old behavior as faithfully as possible IMHO.
> >
> > The NEWS entry clearly says that the old behavior is no longer 
> > available, so getting back the old behavior is not the purpose of that 
> > variable.
> 
> I hope that does not mean "end of discussion".

No, it's just to point out that Martin was expecting from that
variable something it didn't intend to provide.

> it is surprising that such a radical change was accepted without
> testing these cases, which are obvious cases to test.

The master branch _is_ for testing things.  If a change has adverse
effects, those adverse effects should be fixed.  If it turns out there
are too many adverse effects that cannot be reasonably fixed, the
change will be reverted.

> The NEWS entry says "Nevertheless, the effect of what you type in the 
> minibuffer happens in the frame where the minibuffer was first activated, 
> even if it moved to another frame."  This is not correct.  Three recipes:

Please report bugs about these recipes, they need to be investigated,
and either they or the documentation needs to be fixed.

TIA

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Fri, Nov 27, 2020 at 13:43:27 +0000, Gregory Heytings wrote:

> >> Having a customizable variable like 'minibuffer-follows-selected-frame' 
> >> whose purpose is to get back the old behavior, should also provide that 
> >> old behavior as faithfully as possible IMHO.

> > The NEWS entry clearly says that the old behavior is no longer 
> > available, so getting back the old behavior is not the purpose of that 
> > variable.

> I hope that does not mean "end of discussion".

> I sent two recipes to Martin a few hours ago, which demonstrate that the 
> behavior with that variable set to nil is broken.  Again it is surprising 
> that such a radical change was accepted without testing these cases, which 
> are obvious cases to test.

> The NEWS entry says "Nevertheless, the effect of what you type in the 
> minibuffer happens in the frame where the minibuffer was first activated, 
> even if it moved to another frame."  This is not correct.  Three recipes:

> emacs -Q
> C-x 5 2
> C-x C-f
> C-x 5 o
> C-x o
> .emacs RET

> The file is opened in the frame in which you are, not in the frame in 
> which C-x C-f was entered.

> Another recipe:

> emacs -Q
> C-x 5 2
> C-h f setq
> C-x 5 o
> C-x o
> RET

> The *Help* buffer is displayed in the frame in which you are, not in the 
> frame in which C-h f setq was entered.

> Yet another recipe, similar to the one with which this discussion started:

> emacs -Q
> C-x 5 2
> C-x b
> C-x 5 o
> C-x o
> RET

> The buffer is displayed in the frame in which you are, not in the frame in 
> which C-x b was entered.

Thanks for drawing this to our attention.  This bug slipped in unnoticed
in my commit 6e469709c550ba18d9d5a34f6bb89908472f0eb2 from Thu Nov 19
10:31:50 2020 +0000, "In attempted recursive minibuffer use, display
error message in correct frame".

You are right, more systematic testing would have caught this bug before
it got committed.  I urge you to try out the following fix, and let us
all know whether you find further problems with it.  Thanks!



diff --git a/src/minibuf.c b/src/minibuf.c
index fc3fd92a88..7009579763 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -411,6 +411,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -729,6 +730,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 
   recursive_edit_1 ();
 
+  if (!EQ (selected_frame, calling_frame))
+    do_switch_frame (calling_frame, 1, 0, Qnil);
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> Having a customizable variable like 'minibuffer-follows-selected-frame'
 >> whose purpose is to get back the old behavior, should also provide that
 >> old behavior as faithfully as possible IMHO.
 >
 > The NEWS entry clearly says that the old behavior is no longer
 > available, so getting back the old behavior is not the purpose of that
 > variable.

Thanks for the clarification.  I clearly didn't bother to read the NEWS
entry.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin, Andrii, Gregory, and everybody else.

I have been working on this topic over the last few days, and think the
time is almost ripe for another commit to master.  In particular,
several bugs have been fixed.

I would be grateful to anybody who tests out the patch below.  Otherwise
I think the patch is pretty much ready for committing.

On Fri, Nov 27, 2020 at 11:36:47 +0100, martin rudalics wrote:
>  >> If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,
>  >
>  > Do you mean "to nil", here?  That variable is non-nil by default.

> Right.  I meant "to nil" here.

>  >> the behavior does not entirely match that of Emacs 27 because the second
>  >> RET must be typed in the first frame.  So if some application relies on
>  >> the exact replication of the behavior of Emacs 27, we have a regression.
>  >
>  > Well the new behaviour is explicitly not wholly compatible with the old.
>  > I'm not sure that counts as a regression.

> Having a customizable variable like 'minibuffer-follows-selected-frame'
> whose purpose is to get back the old behavior, should also provide that
> old behavior as faithfully as possible IMHO.

Due to protests, minibuffer-follows-selected-frame can now also take a
non-nil, non-t value which provides an approximation of the old
behaviour.

The bugs which have been fixed are these:


1/- "Madhu's bug".  Set pop-up-frames to 'graphic-only, do M-!, type
g TAB, which opens *Completions* in a new frame.  Select something.  The
*Completions* frame should be deleted, but isn't.

This was a problem in window-deleteable-p (window.el), where if an
active minibuffer is in a frame, that frame is regarded as not to be
deleted.  The new minibuffer mechanisms move minibuffers to the new
frame on a frame change, so this obviously(?) clashed.  I have amended
window-deleteable-p to take account of
minibuffer-follows-selected-frame and the new mechanisms.


2/- From Martin: Start emacs -Q -l foo.el, where foo.el is:

(setq default-frame-alist '((minibuffer . nil)))

(defun foo ()
  (interactive)
  (read-from-minibuffer "...?")
  (insert (format "%s" (selected-frame))))

(global-set-key [(control meta +)] 'foo)

(setq enable-recursive-minibuffers t)

Do C-M-+, type something into the minibuffer, and either selected-frame
announced *Minibuffer-1*, or there was an error about "Window not being
in Frame".  Both of these problems are now fixed.


3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers
to t.   Do C-x C-f  C-x 5 o twice, then C-x C-f a third time.  It was
possible to enter filenames for and visit files for the innermost two
minibuffers, but not the outermost one.  This has (I believe) been
fixed.


4/- With minibuffer-follows-selected-frame nil, and
enable-recursive-minibuffers t, there were problems caused by editing
outer level minibuffers whilst an inner level buffer was still active.
I've tried to fix this by giving outer level MBs the keymap
minibuffer-inactive-mode-map temporariliy whilst a recursive MB is
active.


One bug which I haven't fixed, and doesn't appear to be to do with these
changes, is:


5/- emacs -Q, enter the following into *Scratch*:

(defun bar ()
  (interactive)
  (read-from-minibuffer "...?")
  (insert "window: %s ... frame: %s"
          (selected-window) (selected-frame)))

, evaluate it, then evaluate (bar).  The window announced under "window:"
is *Scratch*, that under "frame:" is *Minibuf-1*.  It seems they should
match.

I think the problem is that frame->name doesn't get appear to get set on
a set-frame-selected-window call.  I think the command loop sets
frame->name, and the recursive command loop in read_minibuf sets it to
*Minibuf-1*, and nothing else changes it until the next iteration of the
main command loop.

Also, this bug was in the version of master just before I made my first
commit in this area.


OK, that's enough talking.  Here's the current version of the patch,
which might well be ready to commit.  As already said, I'd be grateful
for anybody who tests it.  Thanks!



diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index c7c8fb30ac..f81e64bdf9 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -76,9 +76,13 @@ Basic Minibuffer
 the user option @code{minibuffer-follows-selected-frame} to
 @code{nil}, then the minibuffer stays in the frame where you opened
 it, and you must switch back to that frame in order to complete (or
-abort) the current command.  Note that the effect of the command, when
-you finally finish using the minibuffer, always takes place in the
-frame where you first opened it.
+abort) the current command.  If you set that option to a value which
+is neither @code{nil} nor @code{t}, the minibuffer moves frame only
+after a recursive minibuffer has been opened in the current command
+(@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
+(approximately) the behavior prior to Emacs 28.1.  Note that the
+effect of the command, when you finally finish using the minibuffer,
+always takes place in the frame where you first opened it.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/etc/NEWS b/etc/NEWS
index b294ff1d23..bd707cb047 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -102,12 +102,13 @@ effect should be negligible in the vast majority of cases anyway.
 By default, when you switch to another frame, an active minibuffer now
 moves to the newly selected frame.  Nevertheless, the effect of what
 you type in the minibuffer happens in the frame where the minibuffer
-was first activated, even if it moved to another frame.  An
-alternative behavior is available by customizing
-'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
-stays in the frame where you first opened it, and you must switch back
-to this frame to continue or abort its command.  The old, somewhat
-unsystematic behavior, which mixed these two is no longer available.
+was first activated.  An alternative behavior is available by
+customizing 'minibuffer-follows-selected-frame' to nil.  Here, the
+minibuffer stays in the frame where you first opened it, and you must
+switch back to this frame to continue or abort its command.  The old
+behavior, which mixed these two, can be approximated by customizing
+'minibuffer-follows-selected-frame' to a value which is neither nil
+nor t.
 
 +++
 ** New system for displaying documentation for groups of functions.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 85dd14f628..0293d34d1c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,7 +394,11 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
-             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
+	     (minibuffer-follows-selected-frame
+              minibuffer (choice (const :tag "Always" t)
+                                 (const :tag "When used" hybrid)
+                                 (const :tag "Never" nil))
+              "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/window.el b/lisp/window.el
index cd13e6603a..4b7d2c4677 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4116,7 +4116,10 @@ window-deletable-p
 				     frame))
 			(throw 'other t))))
 		  (let ((minibuf (active-minibuffer-window)))
-		    (and minibuf (eq frame (window-frame minibuf)))))
+		    (and minibuf (eq frame (window-frame minibuf))
+                         (not (eq (default-toplevel-value
+                                    minibuffer-follows-selected-frame)
+                                  t)))))
 	'frame))
      ((window-minibuffer-p window)
       ;; If WINDOW is the minibuffer window of a non-minibuffer-only
diff --git a/src/minibuf.c b/src/minibuf.c
index 8b23569019..be4ce9d321 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,37 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ())
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
-    {
-      Lisp_Object tail, frame;
-
-      FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
-    }
+  {
+    Lisp_Object tail, frame;
+    struct frame *sf = XFRAME (selected_frame);
+    struct frame *of;
+
+    FOR_EACH_FRAME (tail, frame)
+      if (!EQ (frame, selected_frame)
+          && minibuf_level > 1)
+        {
+          of = XFRAME (frame);
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+
+          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
+                   nth_minibuffer (0)))
+            set_window_buffer (of->minibuffer_window,
+                               nth_minibuffer (0), 0, 0);
+        }
+  }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -411,6 +443,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +565,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -648,6 +683,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
         }
     }
 
+  if (minibuf_moves_frame_when_opened ())
+  {
+    EMACS_INT i;
+
+    /* Stack up all the (recursively) open minibuffers on the selected
+       mini_window.  */
+    for (i = 1; i < minibuf_level; i++)
+      set_window_buffer (XFRAME (mini_frame)->minibuffer_window,
+                         nth_minibuffer (i), 0, 0);
+  }
+
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -727,8 +773,39 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map;
+      if ((inactive_map =
+           find_symbol_value (intern ("minibuffer-inactive-mode-map")))
+          != Qunbound)
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     current window away from the expired minibuffer window.  */
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    while (!EQ (prev, minibuf_window)
+	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
+      prev = Fprevious_window (prev, Qnil, Qnil);
+    if (!EQ (prev, minibuf_window))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+
+  /* Switch the frame back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    do_switch_frame (calling_frame, 1, 0, Qnil);
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -790,6 +867,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +937,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +974,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +989,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
@@ -2035,13 +2127,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minniffer there.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,



> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Here's the current version of the patch,
 > which might well be ready to commit.  As already said, I'd be grateful
 > for anybody who tests it.  Thanks!

Please send it as attachment, here the linefeeds got lost and it doesn't
apply.

Thanks, martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

Hello, Martin.

On Sun, Jan 03, 2021 at 19:24:03 +0100, martin rudalics wrote:
>  > Here's the current version of the patch,
>  > which might well be ready to commit.  As already said, I'd be grateful
>  > for anybody who tests it.  Thanks!

> Please send it as attachment, here the linefeeds got lost and it doesn't
> apply.

OK, here it is!

> Thanks, martin

-- 
Alan Mackenzie (Nuremberg, Germany).


[-- Attachment #2: diff.2021-01-03.diff --]
[-- Type: text/plain, Size: 12872 bytes --]

diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index c7c8fb30ac..f81e64bdf9 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -76,9 +76,13 @@ Basic Minibuffer
 the user option @code{minibuffer-follows-selected-frame} to
 @code{nil}, then the minibuffer stays in the frame where you opened
 it, and you must switch back to that frame in order to complete (or
-abort) the current command.  Note that the effect of the command, when
-you finally finish using the minibuffer, always takes place in the
-frame where you first opened it.
+abort) the current command.  If you set that option to a value which
+is neither @code{nil} nor @code{t}, the minibuffer moves frame only
+after a recursive minibuffer has been opened in the current command
+(@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
+(approximately) the behavior prior to Emacs 28.1.  Note that the
+effect of the command, when you finally finish using the minibuffer,
+always takes place in the frame where you first opened it.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/etc/NEWS b/etc/NEWS
index b294ff1d23..bd707cb047 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -102,12 +102,13 @@ effect should be negligible in the vast majority of cases anyway.
 By default, when you switch to another frame, an active minibuffer now
 moves to the newly selected frame.  Nevertheless, the effect of what
 you type in the minibuffer happens in the frame where the minibuffer
-was first activated, even if it moved to another frame.  An
-alternative behavior is available by customizing
-'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
-stays in the frame where you first opened it, and you must switch back
-to this frame to continue or abort its command.  The old, somewhat
-unsystematic behavior, which mixed these two is no longer available.
+was first activated.  An alternative behavior is available by
+customizing 'minibuffer-follows-selected-frame' to nil.  Here, the
+minibuffer stays in the frame where you first opened it, and you must
+switch back to this frame to continue or abort its command.  The old
+behavior, which mixed these two, can be approximated by customizing
+'minibuffer-follows-selected-frame' to a value which is neither nil
+nor t.
 
 +++
 ** New system for displaying documentation for groups of functions.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 85dd14f628..0293d34d1c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,7 +394,11 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
-             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
+	     (minibuffer-follows-selected-frame
+              minibuffer (choice (const :tag "Always" t)
+                                 (const :tag "When used" hybrid)
+                                 (const :tag "Never" nil))
+              "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/window.el b/lisp/window.el
index cd13e6603a..4b7d2c4677 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4116,7 +4116,10 @@ window-deletable-p
 				     frame))
 			(throw 'other t))))
 		  (let ((minibuf (active-minibuffer-window)))
-		    (and minibuf (eq frame (window-frame minibuf)))))
+		    (and minibuf (eq frame (window-frame minibuf))
+                         (not (eq (default-toplevel-value
+                                    minibuffer-follows-selected-frame)
+                                  t)))))
 	'frame))
      ((window-minibuffer-p window)
       ;; If WINDOW is the minibuffer window of a non-minibuffer-only
diff --git a/src/minibuf.c b/src/minibuf.c
index 8b23569019..be4ce9d321 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,37 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ())
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
-    {
-      Lisp_Object tail, frame;
-
-      FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
-    }
+  {
+    Lisp_Object tail, frame;
+    struct frame *sf = XFRAME (selected_frame);
+    struct frame *of;
+
+    FOR_EACH_FRAME (tail, frame)
+      if (!EQ (frame, selected_frame)
+          && minibuf_level > 1)
+        {
+          of = XFRAME (frame);
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+
+          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
+                   nth_minibuffer (0)))
+            set_window_buffer (of->minibuffer_window,
+                               nth_minibuffer (0), 0, 0);
+        }
+  }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -411,6 +443,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +565,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -648,6 +683,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
         }
     }
 
+  if (minibuf_moves_frame_when_opened ())
+  {
+    EMACS_INT i;
+
+    /* Stack up all the (recursively) open minibuffers on the selected
+       mini_window.  */
+    for (i = 1; i < minibuf_level; i++)
+      set_window_buffer (XFRAME (mini_frame)->minibuffer_window,
+                         nth_minibuffer (i), 0, 0);
+  }
+
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -727,8 +773,39 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map;
+      if ((inactive_map =
+           find_symbol_value (intern ("minibuffer-inactive-mode-map")))
+          != Qunbound)
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     current window away from the expired minibuffer window.  */
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    while (!EQ (prev, minibuf_window)
+	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
+      prev = Fprevious_window (prev, Qnil, Qnil);
+    if (!EQ (prev, minibuf_window))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+
+  /* Switch the frame back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    do_switch_frame (calling_frame, 1, 0, Qnil);
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -790,6 +867,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +937,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +974,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +989,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
@@ -2035,13 +2127,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minniffer there.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > OK, here it is!

Thanks.  It fails to build here as:


CC       cmds.o
../../src/minibuf.c: In function ‘choose_minibuf_frame’:
../../src/minibuf.c:136:19: warning: unused variable ‘sf’ [-Wunused-variable]
      struct frame *sf = XFRAME (selected_frame);
                    ^~
../../src/minibuf.c: In function ‘read_minibuf’:
../../src/minibuf.c:784:11: error: invalid operands to binary != (have ‘Lisp_Object’ {aka ‘struct Lisp_Object’} and ‘Lisp_Object’ {aka ‘struct Lisp_Object’})
        if ((inactive_map =
            ~~~~~~~~~~~~~~~
             find_symbol_value (intern ("minibuffer-inactive-mode-map")))
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            != Qunbound)
            ^~
   CC       casetab.o
make[1]: *** [Makefile:405: minibuf.o] Fehler 1
make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[1]: Verzeichnis „/home/martin/emacs-git/trunk/obj-gtk/src“ wird verlassen
make: *** [Makefile:424: src] Fehler 2


You have to use !EQ when testing Lisp Objects for inequality.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

Hello, Martin.

On Sun, Jan 03, 2021 at 21:08:21 +0100, martin rudalics wrote:
>  > OK, here it is!

> Thanks.  It fails to build here as:


> CC       cmds.o
> ../../src/minibuf.c: In function ‘choose_minibuf_frame’:
> ../../src/minibuf.c:136:19: warning: unused variable ‘sf’ [-Wunused-variable]
>       struct frame *sf = XFRAME (selected_frame);
>                     ^~
> ../../src/minibuf.c: In function ‘read_minibuf’:
> ../../src/minibuf.c:784:11: error: invalid operands to binary != (have ‘Lisp_Object’ {aka ‘struct Lisp_Object’} and ‘Lisp_Object’ {aka ‘struct Lisp_Object’})
>         if ((inactive_map =
>             ~~~~~~~~~~~~~~~
>              find_symbol_value (intern ("minibuffer-inactive-mode-map")))
>              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>             != Qunbound)
>             ^~
>    CC       casetab.o
> make[1]: *** [Makefile:405: minibuf.o] Fehler 1
> make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet....
> make[1]: Verzeichnis „/home/martin/emacs-git/trunk/obj-gtk/src“ wird verlassen
> make: *** [Makefile:424: src] Fehler 2

Thanks!  My compiler (GCC 9.3.0) didn't even raise a warning for that.
I've corrected it, and also got rid of the unused variable.

> You have to use !EQ when testing Lisp Objects for inequality.

Yes, indeed.

The corrected patch is attached.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).


[-- Attachment #2: diff.20210103b.diff --]
[-- Type: text/plain, Size: 12820 bytes --]

diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index c7c8fb30ac..f81e64bdf9 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -76,9 +76,13 @@ Basic Minibuffer
 the user option @code{minibuffer-follows-selected-frame} to
 @code{nil}, then the minibuffer stays in the frame where you opened
 it, and you must switch back to that frame in order to complete (or
-abort) the current command.  Note that the effect of the command, when
-you finally finish using the minibuffer, always takes place in the
-frame where you first opened it.
+abort) the current command.  If you set that option to a value which
+is neither @code{nil} nor @code{t}, the minibuffer moves frame only
+after a recursive minibuffer has been opened in the current command
+(@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
+(approximately) the behavior prior to Emacs 28.1.  Note that the
+effect of the command, when you finally finish using the minibuffer,
+always takes place in the frame where you first opened it.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/etc/NEWS b/etc/NEWS
index b294ff1d23..bd707cb047 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -102,12 +102,13 @@ effect should be negligible in the vast majority of cases anyway.
 By default, when you switch to another frame, an active minibuffer now
 moves to the newly selected frame.  Nevertheless, the effect of what
 you type in the minibuffer happens in the frame where the minibuffer
-was first activated, even if it moved to another frame.  An
-alternative behavior is available by customizing
-'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
-stays in the frame where you first opened it, and you must switch back
-to this frame to continue or abort its command.  The old, somewhat
-unsystematic behavior, which mixed these two is no longer available.
+was first activated.  An alternative behavior is available by
+customizing 'minibuffer-follows-selected-frame' to nil.  Here, the
+minibuffer stays in the frame where you first opened it, and you must
+switch back to this frame to continue or abort its command.  The old
+behavior, which mixed these two, can be approximated by customizing
+'minibuffer-follows-selected-frame' to a value which is neither nil
+nor t.
 
 +++
 ** New system for displaying documentation for groups of functions.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 85dd14f628..0293d34d1c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,7 +394,11 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
-             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
+	     (minibuffer-follows-selected-frame
+              minibuffer (choice (const :tag "Always" t)
+                                 (const :tag "When used" hybrid)
+                                 (const :tag "Never" nil))
+              "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/window.el b/lisp/window.el
index cd13e6603a..4b7d2c4677 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4116,7 +4116,10 @@ window-deletable-p
 				     frame))
 			(throw 'other t))))
 		  (let ((minibuf (active-minibuffer-window)))
-		    (and minibuf (eq frame (window-frame minibuf)))))
+		    (and minibuf (eq frame (window-frame minibuf))
+                         (not (eq (default-toplevel-value
+                                    minibuffer-follows-selected-frame)
+                                  t)))))
 	'frame))
      ((window-minibuffer-p window)
       ;; If WINDOW is the minibuffer window of a non-minibuffer-only
diff --git a/src/minibuf.c b/src/minibuf.c
index 8b23569019..55445f103d 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,36 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ())
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
-    {
-      Lisp_Object tail, frame;
-
-      FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
-    }
+  {
+    Lisp_Object tail, frame;
+    struct frame *of;
+
+    FOR_EACH_FRAME (tail, frame)
+      if (!EQ (frame, selected_frame)
+          && minibuf_level > 1)
+        {
+          of = XFRAME (frame);
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+
+          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
+                   nth_minibuffer (0)))
+            set_window_buffer (of->minibuffer_window,
+                               nth_minibuffer (0), 0, 0);
+        }
+  }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -411,6 +442,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +564,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -648,6 +682,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
         }
     }
 
+  if (minibuf_moves_frame_when_opened ())
+  {
+    EMACS_INT i;
+
+    /* Stack up all the (recursively) open minibuffers on the selected
+       mini_window.  */
+    for (i = 1; i < minibuf_level; i++)
+      set_window_buffer (XFRAME (mini_frame)->minibuffer_window,
+                         nth_minibuffer (i), 0, 0);
+  }
+
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -727,8 +772,39 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map;
+      if (!EQ (inactive_map =
+	       find_symbol_value (intern ("minibuffer-inactive-mode-map")),
+	       Qunbound))
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     current window away from the expired minibuffer window.  */
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    while (!EQ (prev, minibuf_window)
+	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
+      prev = Fprevious_window (prev, Qnil, Qnil);
+    if (!EQ (prev, minibuf_window))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+
+  /* Switch the frame back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    do_switch_frame (calling_frame, 1, 0, Qnil);
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -790,6 +866,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +936,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +973,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +988,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
@@ -2035,13 +2126,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minniffer there.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

It builds now so let's get back to your initial request.

 > 1/- "Madhu's bug".  Set pop-up-frames to 'graphic-only, do M-!, type
 > g TAB, which opens *Completions* in a new frame.  Select something.  The
 > *Completions* frame should be deleted, but isn't.
 >
 > This was a problem in window-deleteable-p (window.el), where if an
 > active minibuffer is in a frame, that frame is regarded as not to be
 > deleted.  The new minibuffer mechanisms move minibuffers to the new
 > frame on a frame change, so this obviously(?) clashed.  I have amended
 > window-deleteable-p to take account of
 > minibuffer-follows-selected-frame and the new mechanisms.

I leave this to Madhu.  Here the minibuffer frame is not deleted but
gets iconified which is probably due to the default of
'auto-hide-function', something I'm not going to dispute here.

 > 2/- From Martin: Start emacs -Q -l foo.el, where foo.el is:
 >
 > (setq default-frame-alist '((minibuffer . nil)))
 >
 > (defun foo ()
 >    (interactive)
 >    (read-from-minibuffer "...?")
 >    (insert (format "%s" (selected-frame))))
 >
 > (global-set-key [(control meta +)] 'foo)
 >
 > (setq enable-recursive-minibuffers t)
 >
 > Do C-M-+, type something into the minibuffer, and either selected-frame
 > announced *Minibuffer-1*, or there was an error about "Window not being
 > in Frame".  Both of these problems are now fixed.

Confirmed.  At least I can't reproduce them any more.

 >
 > 3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers
 > to t.   Do C-x C-f  C-x 5 o twice, then C-x C-f a third time.  It was
 > possible to enter filenames for and visit files for the innermost two
 > minibuffers, but not the outermost one.  This has (I believe) been
 > fixed.

I'm not sure what's missing here, probably a C-x 5 2 to get the frame
C-x 5 o can act upon.  So I let Gregory tell whether this has been
fixed.  What I see is that with 'enable-recursive-minibuffers' t C-x 5 2
followed by two C-x C-f C-x 5 o

- doesn't get me _always_ into the minibuffer window of the frame
   switched too (I'm not sure whether it should and under which
   circumstances - this should be clarified), and

- typing C-g to quit an inner invocation of C-x C-f sometimes gets me a
   catatonic minibuffer window where either nothing is displayed or just
   a simple "Quit" appears - I have to get out of it via C-x o.

 > 4/- With minibuffer-follows-selected-frame nil, and
 > enable-recursive-minibuffers t, there were problems caused by editing
 > outer level minibuffers whilst an inner level buffer was still active.
 > I've tried to fix this by giving outer level MBs the keymap
 > minibuffer-inactive-mode-map temporariliy whilst a recursive MB is
 > active.

How do I edit an outer level minibuffer whilst an inner level buffer is
active?

 > One bug which I haven't fixed, and doesn't appear to be to do with these
 > changes, is:
 >
 >
 > 5/- emacs -Q, enter the following into *Scratch*:
 >
 > (defun bar ()
 >    (interactive)
 >    (read-from-minibuffer "...?")
 >    (insert "window: %s ... frame: %s"

... which is probably missing a "format" here ...

 >            (selected-window) (selected-frame)))
 >
 > , evaluate it, then evaluate (bar).  The window announced under "window:"
 > is *Scratch*, that under "frame:" is *Minibuf-1*.  It seems they should
 > match.
 >
 > I think the problem is that frame->name doesn't get appear to get set on
 > a set-frame-selected-window call.  I think the command loop sets
 > frame->name, and the recursive command loop in read_minibuf sets it to
 > *Minibuf-1*, and nothing else changes it until the next iteration of the
 > main command loop.
 >
 > Also, this bug was in the version of master just before I made my first
 > commit in this area.

That's probably part of the select window/frame mystery.  You just can't
have them both - 'select-window' and 'select-frame' - and hope that they
will live happily ever after.  Maybe a

       wset_redisplay (XWINDOW (window));

after the

       fset_selected_window (XFRAME (frame), window);

is due so that the redisplay mechanism knows what title to draw in that
frame but I don't think we should care much.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

[-- Attachment #1: Type: text/plain, Size: 3282 bytes --]

Hello, Martin and everybody else.

On Mon, Jan 04, 2021 at 10:20:11 +0100, martin rudalics wrote:

[ .... ]

>  > 3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers
>  > to t.   Do C-x C-f  C-x 5 o twice, then C-x C-f a third time.  It was
>  > possible to enter filenames for and visit files for the innermost two
>  > minibuffers, but not the outermost one.  This has (I believe) been
>  > fixed.

> I'm not sure what's missing here, probably a C-x 5 2 to get the frame
> C-x 5 o can act upon.  So I let Gregory tell whether this has been
> fixed.  What I see is that with 'enable-recursive-minibuffers' t C-x 5 2
> followed by two C-x C-f C-x 5 o

> - doesn't get me _always_ into the minibuffer window of the frame
>    switched to (I'm not sure whether it should and under which
>    circumstances - this should be clarified),

I don't think it should, in general, unless the miniwindow is (still) the
frame's current window.

I've found out why, in Gregory's scenario, after the "middle" RET to
visit a file, point was not moving back to the "middle frame": it's
because select_frame is insufficient of itself to move X-Window's focus,
which stays in the "old" frame.  Any command now causes a "switch-frame"
event which moves the minibuffers back into the "old" frame, which isn't
what we want.  The solution (a bit ugly) is to call the lisp function
select-frame-set-input-focus rather than just do_switch_frame near the
end of read_minibuf.

> and

> - typing C-g to quit an inner invocation of C-x C-f sometimes gets me a
>    catatonic minibuffer window where either nothing is displayed or just
>    a simple "Quit" appears - I have to get out of it via C-x o.

Yes.  I still have some work to do in this area.

>  > 4/- With minibuffer-follows-selected-frame nil, and
>  > enable-recursive-minibuffers t, there were problems caused by editing
>  > outer level minibuffers whilst an inner level buffer was still active.
>  > I've tried to fix this by giving outer level MBs the keymap
>  > minibuffer-inactive-mode-map temporariliy whilst a recursive MB is
>  > active.

> How do I edit an outer level minibuffer whilst an inner level buffer is
> active?

At the moment, you can't.  This isn't good.  What do you think of the
following solution?

Instead of setting outer minibuffers' maps temporarily to
minibuffer-inactive-mode-map, I could amend exit-minibuffer so that it
would throw an error when there was a more nested active minibuffer, but
leave the current minibuffers untouched.  Also, C-g should then abort the
current minibuffer's caller, together with those of any more nested MBs.

[ .... ]

The change in the current version of the patch (attached) is that, as
already mentioned, select-frame-set-input-focus is called rather than
just do_select_frame from near the end of read_minibuf.  Also, that call
has been moved from just after the recursive edit to the very end of
read_minibuf.  Also, move_minibuffer_onto_frame now moves the entire
stack of minibuffers, not just the current one (it is not called when
minibuffers-follows-selected-frame is nil).

How would you feel about committing this patch?  It is an improvement
over the current state, even though not yet finished.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).


[-- Attachment #2: diff.20210105.diff --]
[-- Type: text/plain, Size: 14612 bytes --]

diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index c7c8fb30ac..f81e64bdf9 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -76,9 +76,13 @@ Basic Minibuffer
 the user option @code{minibuffer-follows-selected-frame} to
 @code{nil}, then the minibuffer stays in the frame where you opened
 it, and you must switch back to that frame in order to complete (or
-abort) the current command.  Note that the effect of the command, when
-you finally finish using the minibuffer, always takes place in the
-frame where you first opened it.
+abort) the current command.  If you set that option to a value which
+is neither @code{nil} nor @code{t}, the minibuffer moves frame only
+after a recursive minibuffer has been opened in the current command
+(@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
+(approximately) the behavior prior to Emacs 28.1.  Note that the
+effect of the command, when you finally finish using the minibuffer,
+always takes place in the frame where you first opened it.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/etc/NEWS b/etc/NEWS
index b294ff1d23..bd707cb047 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -102,12 +102,13 @@ effect should be negligible in the vast majority of cases anyway.
 By default, when you switch to another frame, an active minibuffer now
 moves to the newly selected frame.  Nevertheless, the effect of what
 you type in the minibuffer happens in the frame where the minibuffer
-was first activated, even if it moved to another frame.  An
-alternative behavior is available by customizing
-'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
-stays in the frame where you first opened it, and you must switch back
-to this frame to continue or abort its command.  The old, somewhat
-unsystematic behavior, which mixed these two is no longer available.
+was first activated.  An alternative behavior is available by
+customizing 'minibuffer-follows-selected-frame' to nil.  Here, the
+minibuffer stays in the frame where you first opened it, and you must
+switch back to this frame to continue or abort its command.  The old
+behavior, which mixed these two, can be approximated by customizing
+'minibuffer-follows-selected-frame' to a value which is neither nil
+nor t.
 
 +++
 ** New system for displaying documentation for groups of functions.
@@ -2046,6 +2047,12 @@ and display the result.
 When non-nil, then functions 'read-char-choice' and 'y-or-n-p' (respectively)
 use the function 'read-key' to read a character instead of using the minibuffer.
 
++++
+** New syntax flag 'e'.
+This indicates that one or two (or more) escape characters escape a
+comment ender with this flag, causing the comment to be continued past
+that comment ender (typically onto the next line).
+
 +++
 ** 'set-window-configuration' now takes an optional 'dont-set-frame'
 parameter which, when non-nil, instructs the function not to select
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 85dd14f628..0293d34d1c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,7 +394,11 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
-             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
+	     (minibuffer-follows-selected-frame
+              minibuffer (choice (const :tag "Always" t)
+                                 (const :tag "When used" hybrid)
+                                 (const :tag "Never" nil))
+              "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/window.el b/lisp/window.el
index cd13e6603a..4b7d2c4677 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4116,7 +4116,10 @@ window-deletable-p
 				     frame))
 			(throw 'other t))))
 		  (let ((minibuf (active-minibuffer-window)))
-		    (and minibuf (eq frame (window-frame minibuf)))))
+		    (and minibuf (eq frame (window-frame minibuf))
+                         (not (eq (default-toplevel-value
+                                    minibuffer-follows-selected-frame)
+                                  t)))))
 	'frame))
      ((window-minibuffer-p window)
       ;; If WINDOW is the minibuffer window of a non-minibuffer-only
diff --git a/src/minibuf.c b/src/minibuf.c
index 8b23569019..a99a208c2b 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,36 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ())
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
-    {
-      Lisp_Object tail, frame;
-
-      FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
-    }
+  {
+    Lisp_Object tail, frame;
+    struct frame *of;
+
+    FOR_EACH_FRAME (tail, frame)
+      if (!EQ (frame, selected_frame)
+          && minibuf_level > 1)
+        {
+          of = XFRAME (frame);
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+
+          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
+                   nth_minibuffer (0)))
+            set_window_buffer (of->minibuffer_window,
+                               nth_minibuffer (0), 0, 0);
+        }
+  }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -135,12 +166,15 @@ void move_minibuffer_onto_frame (void)
       && FRAME_LIVE_P (XFRAME (selected_frame))
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
+      EMACS_INT i;
       struct frame *sf = XFRAME (selected_frame);
       Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
       struct frame *of = XFRAME (old_frame);
-      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
 
-      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      /* Stack up all the (recursively) open minibuffers on the selected
+         mini_window.  */
+      for (i = 1; i <= minibuf_level; i++)
+	set_window_buffer (sf->minibuffer_window, nth_minibuffer (i), 0, 0);
       minibuf_window = sf->minibuffer_window;
       set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
     }
@@ -411,6 +445,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -532,7 +567,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   minibuf_save_list
     = Fcons (Voverriding_local_map,
 	     Fcons (minibuf_window,
-		    minibuf_save_list));
+                    Fcons (BVAR (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                                 keymap),
+                           minibuf_save_list)));
   minibuf_save_list
     = Fcons (minibuf_prompt,
 	     Fcons (make_fixnum (minibuf_prompt_width),
@@ -648,6 +685,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
         }
     }
 
+  if (minibuf_moves_frame_when_opened ())
+  {
+    EMACS_INT i;
+
+    /* Stack up all the (recursively) open minibuffers on the selected
+       mini_window.  */
+    for (i = 1; i < minibuf_level; i++)
+      set_window_buffer (XFRAME (mini_frame)->minibuffer_window,
+                         nth_minibuffer (i), 0, 0);
+  }
+
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -727,8 +775,32 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Prevent the user manipulating outer levels of recursive minibuffers.  */
+  if (minibuf_level > 1)
+    {
+      Lisp_Object inactive_map =
+	find_symbol_value (intern ("minibuffer-inactive-mode-map"));
+      if (!EQ (inactive_map, Qunbound))
+        bset_keymap (XBUFFER (nth_minibuffer (minibuf_level - 1)),
+                     inactive_map);
+    }
+
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     current window away from the expired minibuffer window.  */
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    while (!EQ (prev, minibuf_window)
+	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
+      prev = Fprevious_window (prev, Qnil, Qnil);
+    if (!EQ (prev, minibuf_window))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -767,6 +839,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
      in set-window-configuration.  */
   unbind_to (count, Qnil);
 
+  /* Switch the frame back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil);
+
   /* Add the value to the appropriate history list, if any.  This is
      done after the previous buffer has been made current again, in
      case the history variable is buffer-local.  */
@@ -790,6 +868,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -852,6 +938,7 @@ read_minibuf_unwind (void)
   Lisp_Object old_deactivate_mark;
   Lisp_Object window;
   Lisp_Object future_mini_window;
+  Lisp_Object map;
 
   /* If this was a recursive minibuffer,
      tie the minibuffer window back to the outer level minibuffer buffer.  */
@@ -888,6 +975,8 @@ read_minibuf_unwind (void)
 #endif
   future_mini_window = Fcar (minibuf_save_list);
   minibuf_save_list = Fcdr (minibuf_save_list);
+  map = Fcar (minibuf_save_list);
+  minibuf_save_list = Fcdr (minibuf_save_list);
 
   /* Erase the minibuffer we were using at this level.  */
   {
@@ -901,6 +990,10 @@ read_minibuf_unwind (void)
     unbind_to (count, Qnil);
   }
 
+  /* Restore the keymap of any outer level recursive minibuffer. */
+  if (minibuf_level > 0)
+    bset_keymap (XBUFFER (nth_minibuffer (minibuf_level)), map);
+
   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
@@ -2035,13 +2128,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minniffer there.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> - doesn't get me _always_ into the minibuffer window of the frame
 >>     switched to (I'm not sure whether it should and under which
 >>     circumstances - this should be clarified),
 >
 > I don't think it should, in general, unless the miniwindow is (still) the
 > frame's current window.

OK.  Let's stick to this rule.

 > I've found out why, in Gregory's scenario, after the "middle" RET to
 > visit a file, point was not moving back to the "middle frame": it's
 > because select_frame is insufficient of itself to move X-Window's focus,
 > which stays in the "old" frame.  Any command now causes a "switch-frame"
 > event which moves the minibuffers back into the "old" frame, which isn't
 > what we want.  The solution (a bit ugly) is to call the lisp function
 > select-frame-set-input-focus rather than just do_switch_frame near the
 > end of read_minibuf.

This is indeed ugly and might harm 'redirect-frame-focus'.

 >> How do I edit an outer level minibuffer whilst an inner level buffer is
 >> active?
 >
 > At the moment, you can't.  This isn't good.

I think it is good (enough).  Do we want spaghetti minibuffers?

 >  What do you think of the
 > following solution?
 >
 > Instead of setting outer minibuffers' maps temporarily to
 > minibuffer-inactive-mode-map, I could amend exit-minibuffer so that it
 > would throw an error when there was a more nested active minibuffer, but
 > leave the current minibuffers untouched.  Also, C-g should then abort the
 > current minibuffer's caller, together with those of any more nested MBs.

We're right in hell's kitchen here.

 > The change in the current version of the patch (attached) is that, as
 > already mentioned, select-frame-set-input-focus is called rather than
 > just do_select_frame from near the end of read_minibuf.  Also, that call
 > has been moved from just after the recursive edit to the very end of
 > read_minibuf.  Also, move_minibuffer_onto_frame now moves the entire
 > stack of minibuffers, not just the current one (it is not called when
 > minibuffers-follows-selected-frame is nil).
 >
 > How would you feel about committing this patch?  It is an improvement
 > over the current state, even though not yet finished.

Let's wait for a week at least.  I'd really want to hear the comments
from the rest of the bunch.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello again, Martin.

On Tue, Jan 05, 2021 at 19:53:23 +0100, martin rudalics wrote:
>  >> - doesn't get me _always_ into the minibuffer window of the frame
>  >>     switched to (I'm not sure whether it should and under which
>  >>     circumstances - this should be clarified),

>  > I don't think it should, in general, unless the miniwindow is (still) the
>  > frame's current window.

> OK.  Let's stick to this rule.

:-)

>  > I've found out why, in Gregory's scenario, after the "middle" RET to
>  > visit a file, point was not moving back to the "middle frame": it's
>  > because select_frame is insufficient of itself to move X-Window's focus,
>  > which stays in the "old" frame.  Any command now causes a "switch-frame"
>  > event which moves the minibuffers back into the "old" frame, which isn't
>  > what we want.  The solution (a bit ugly) is to call the lisp function
>  > select-frame-set-input-focus rather than just do_switch_frame near the
>  > end of read_minibuf.

> This is indeed ugly and might harm 'redirect-frame-focus'.

Actualy, I don't think it's as ugly as all that.
select-frame-set-input-focus is an extremely coherent function; it does
one thing and does it well, i.e. switch frames.  Maybe it's a pity that
it's a Lisp function rather than a C function, but it is as it is.

I've been trying to think through the bit about redirect-frame-focus.
It's difficult.  Are you aware of any particular scenarios where it might
go wrong with select-frame-set-input-focus?  Or is it more a general
concern, possibly from past experience?  For example if the source frame
has focus redirected to a MB-only frame, and s-f-s-i-focus is called,
should that redirected focus be undone?  I'm a little confused about the
difference between a MB-only frame being the selected frame, and it being
the focus frame of a different "normal" frame.

>  >> How do I edit an outer level minibuffer whilst an inner level buffer is
>  >> active?

>  > At the moment, you can't.  This isn't good.

> I think it is good (enough).  Do we want spaghetti minibuffers?

I've changed the handling of outer level minibuffers so that they can be
freely edited (but not exited, see below).

>  >  What do you think of the
>  > following solution?

>  > Instead of setting outer minibuffers' maps temporarily to
>  > minibuffer-inactive-mode-map, I could amend exit-minibuffer so that
>  > it would throw an error when there was a more nested active
>  > minibuffer, but leave the current minibuffers untouched.  Also, C-g
>  > should then abort the current minibuffer's caller, together with
>  > those of any more nested MBs.

> We're right in hell's kitchen here.

I've actually implemented the above, on a trial basis.  It was actually
surprisingly easy.  The C-g bit was just 9 extra lines (plus comments) in
internal_catch (eval.c), and another small function in minibuf.c.

You say "hell's kitchen".  Again, is this on general principles, or can
you see some specific problems which might crop up?  My feeling is that
this way of dealing with "not the innermost minibuffer" is simple, and
possibly as good as we're going to get.

Another possibility, is that rather than a stack of minibuffers, we have
a collection of minibuffers, any one of which (which is accessible) can
be used and exited at any time.  But I can foreseen lots of unforeseen
problems happening with this, and I don't want to try to implement it at
the moment.

>  > The change in the current version of the patch (attached) is that,
>  > as already mentioned, select-frame-set-input-focus is called rather
>  > than just do_select_frame from near the end of read_minibuf.  Also,
>  > that call has been moved from just after the recursive edit to the
>  > very end of read_minibuf.  Also, move_minibuffer_onto_frame now
>  > moves the entire stack of minibuffers, not just the current one (it
>  > is not called when minibuffers-follows-selected-frame is nil).

>  > How would you feel about committing this patch?  It is an improvement
>  > over the current state, even though not yet finished.

> Let's wait for a week at least.  I'd really want to hear the comments
> from the rest of the bunch.

OK.  My feeling at the moment is the patch is now finished (apart from
some documentation changes).  Maybe I should push out another patch,
though I'm not doing that right at the moment.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> I've been trying to think through the bit about redirect-frame-focus.
> It's difficult.  Are you aware of any particular scenarios where it might
> go wrong with select-frame-set-input-focus?  

Apologies for chiming in here.  I'm not very knowledgeable about this, and I can't speak directly to the current context.

I can say that I use `redirect-frame-focus' to redirect the focus for a standalone `*Completions*' frame to a standalone minibuffer frame.  And I have problems with Emacs 27, including bad changes in frame focus.  (Dunno whether my problems with Emacs 27 are related to this thread.)

I also call `select-frame-set-input-focus' a fair amount in my code.

And users can, e.g., mouse-click another frame during minibuffer input to select that other frame (or select it in another way), do something with that frame selected, then select the minibuffer frame again, etc.

Again, no idea whether what I'm saying here is relevant to the question at hand.  If not, please ignore.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Actualy, I don't think it's as ugly as all that.
 > select-frame-set-input-focus is an extremely coherent function; it does
 > one thing and does it well, i.e. switch frames.  Maybe it's a pity that
 > it's a Lisp function rather than a C function, but it is as it is.

It does call 'raise-frame' something people with 'focus-follows-mouse' t
(not 'auto-raise') might not want here.  And it may have to move the
mouse cursor according to the 'mouse-autoselect-window' and
'focus-follows-mouse' policies.  Most window managers don't handle the
latter well (IIRC only the otherwise abominable mutter and KDE could do
it approximately).  And the former wants the selected window to be set
up well before calling 'select-frame-set-input-focus'.

 > I've been trying to think through the bit about redirect-frame-focus.
 > It's difficult.  Are you aware of any particular scenarios where it might
 > go wrong with select-frame-set-input-focus?  Or is it more a general
 > concern, possibly from past experience?  For example if the source frame
 > has focus redirected to a MB-only frame, and s-f-s-i-focus is called,
 > should that redirected focus be undone?  I'm a little confused about the
 > difference between a MB-only frame being the selected frame, and it being
 > the focus frame of a different "normal" frame.

I already had to revert one change because I got that wrong.  It's again
mostly about using 'focus-follows-mouse' t with a standalone minibuffer
frame and I've never been able to understand how people manage that when
the normal frame practically completely covers the minibuffer frame.
But sooner or later this point will get moot because with Wayland people
will be no more able to put a standalone minibuffer frame wherever they
want to.

 >> We're right in hell's kitchen here.
 >
 > I've actually implemented the above, on a trial basis.  It was actually
 > surprisingly easy.  The C-g bit was just 9 extra lines (plus comments) in
 > internal_catch (eval.c), and another small function in minibuf.c.
 >
 > You say "hell's kitchen".  Again, is this on general principles,

Just gut feeling.

 > or can
 > you see some specific problems which might crop up?  My feeling is that
 > this way of dealing with "not the innermost minibuffer" is simple, and
 > possibly as good as we're going to get.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

[-- Attachment #1: Type: text/plain, Size: 5982 bytes --]

Hello, Martin.

On Thu, Jan 07, 2021 at 19:26:02 +0100, martin rudalics wrote:
>  > Actualy, I don't think it's as ugly as all that.
>  > select-frame-set-input-focus is an extremely coherent function; it does
>  > one thing and does it well, i.e. switch frames.  Maybe it's a pity that
>  > it's a Lisp function rather than a C function, but it is as it is.

> It does call 'raise-frame' something people with 'focus-follows-mouse' t
> (not 'auto-raise') might not want here.  And it may have to move the
> mouse cursor according to the 'mouse-autoselect-window' and
> 'focus-follows-mouse' policies.  Most window managers don't handle the
> latter well (IIRC only the otherwise abominable mutter and KDE could do
> it approximately).  And the former wants the selected window to be set
> up well before calling 'select-frame-set-input-focus'.

It is nevertheless the standard function to call to move focus to a
different frame.  If there are problems with focus-follows-mouse, they
should surely be fixed in frame.el as a separate problem.

>  > I've been trying to think through the bit about redirect-frame-focus.
>  > It's difficult.  Are you aware of any particular scenarios where it might
>  > go wrong with select-frame-set-input-focus?  Or is it more a general
>  > concern, possibly from past experience?  For example if the source frame
>  > has focus redirected to a MB-only frame, and s-f-s-i-focus is called,
>  > should that redirected focus be undone?  I'm a little confused about the
>  > difference between a MB-only frame being the selected frame, and it being
>  > the focus frame of a different "normal" frame.

> I already had to revert one change because I got that wrong.  It's again
> mostly about using 'focus-follows-mouse' t with a standalone minibuffer
> frame and I've never been able to understand how people manage that when
> the normal frame practically completely covers the minibuffer frame.
> But sooner or later this point will get moot because with Wayland people
> will be no more able to put a standalone minibuffer frame wherever they
> want to.

OK.  My gut feeling is just to ignore this potential problem at the
moment.

>  >> We're right in hell's kitchen here.

>  > I've actually implemented the above, on a trial basis.  It was actually
>  > surprisingly easy.  The C-g bit was just 9 extra lines (plus comments) in
>  > internal_catch (eval.c), and another small function in minibuf.c.

>  > You say "hell's kitchen".  Again, is this on general principles,

> Just gut feeling.

OK.  I can understand that.  ;-)

>  > or can
>  > you see some specific problems which might crop up?  My feeling is that
>  > this way of dealing with "not the innermost minibuffer" is simple, and
>  > possibly as good as we're going to get.

My intention at the moment is to commit my current state of work.  I'm
attaching the patch.

Here's a commit message to go with it:

Fix incompleteness in the implementation of minibuffer-follows-selected-frame

In particular, add a new value to the variable, and fix several bugs apparent
with the implementation up till now.

* doc/emacs/mini.texi (Basic Minibuffer): Add a description of the new
non-nil, non-t value of minibuffer-follows-selected-frame.

* doc/emacs/trouble.texi (Quitting): Add a description of how C-g handles
recursive minibuffers when typed in one which isn't the most nested.

* doc/lispref/minibuf.texi (Intro to Minibuffers): Add an @dfn for "active
minibuffer".
(Minibuffer Commands): Document that exit-minibuffer throws an error when not
invoked from the innermost Minibuffer.
(Recursive Mini): Amend the description of the visibility of outer level
minibuffers.
(Minibuffer Misc): In the description of the minibuffer hooks, replace "the
minibuffer" with "a minibuffer".

* etc/NEWS (Entry announcing minibuffer-follows-selected-frame): Add a
description of the new non-nil, non-t value.

* lisp/cus-start.el (top level): make the customize entry for
minibuffer-follows-selected-frame a choice between three entries.

* lisp/minibuffer.el (exit-minibuffer): throw an error when we're not in the
most nested minibuffer.

* lisp/window.el (window-deletable-p): return the symbol `frame' when (amongst
other things) minibuffer-follows-selected-frame is t.

* src/eval.c (internal_catch): Add a mechanism to (throw 'exit t) repeatedly
when the throw currently being processed doesn't terminate the current
minibuffer.

* src/lisp.h (this_minibuffer_depth): New extern declaration
(minibuf_level): extern declaration moved here from window.h.

* src/minibuf.c (minibuffer_follows_frame, minibuf_stays_put)
(minibuf_moves_frame_when_opened): New and amended functions to query the
value of minibuffer-follows-selected-frame.
(choose_minibuf_frame): check (minibuf > 1) in place of (minibufer > 0) at a
particular place.  At another place, check that an alleged frame is so and is
live.  Before selecting a non-miniwindow on a different frame, ensure it
really is a different frame.
(move_minibuffer_onto_frame): Stack up all recursive minibuffers on the target
frame.  Check the minibuf_window isn't in the old frame before setting that
frame's miniwindow to an inactive minibuffer.
(Finnermost_minibuffer_p): New primitive.
(this_minibuffer_depth): New function.
(read_minibuf): Record the calling frame in a variable, and switch back to it
after the recursive edit has terminated normally, using
select-frame-set-input-focus.  Stack up all the recursive minibuffers on the
miniwindow where a new minibuffer is being opened.  After the recursive edit,
switch the selected window away from the expired minibuffer's window.
(nth_minibuffer): New function.
(minibuffer-follows-selected-frame): Change from a DEFVAR_BOOL to a
DEFVAR_LISP.

* src/window.c (decode_next_window_args): Set *minibuf to w's mini-window's
content when that content is a minibuffer.

* src/window.h (minibuf_level) Declaration moved from here to lisp.h.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).


[-- Attachment #2: diff.20210109c.diff --]
[-- Type: text/plain, Size: 21714 bytes --]

diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi
index c7c8fb30ac..f81e64bdf9 100644
--- a/doc/emacs/mini.texi
+++ b/doc/emacs/mini.texi
@@ -76,9 +76,13 @@ Basic Minibuffer
 the user option @code{minibuffer-follows-selected-frame} to
 @code{nil}, then the minibuffer stays in the frame where you opened
 it, and you must switch back to that frame in order to complete (or
-abort) the current command.  Note that the effect of the command, when
-you finally finish using the minibuffer, always takes place in the
-frame where you first opened it.
+abort) the current command.  If you set that option to a value which
+is neither @code{nil} nor @code{t}, the minibuffer moves frame only
+after a recursive minibuffer has been opened in the current command
+(@pxref{Recursive Mini,,, elisp}).  This option is mainly to retain
+(approximately) the behavior prior to Emacs 28.1.  Note that the
+effect of the command, when you finally finish using the minibuffer,
+always takes place in the frame where you first opened it.
 
 @node Minibuffer File
 @section Minibuffers for File Names
diff --git a/doc/emacs/trouble.texi b/doc/emacs/trouble.texi
index 4da3d4a3e8..13f03814fd 100644
--- a/doc/emacs/trouble.texi
+++ b/doc/emacs/trouble.texi
@@ -57,6 +57,13 @@ Quitting
 successive @kbd{C-g} characters to get out of a search.
 @xref{Incremental Search}, for details.
 
+  If you type @kbd{C-g} in a minibuffer, this quits the command that
+opened that minibuffer, closing it.  If that minibuffer is not the
+most recently opened one (which can happen when
+@code{minibuffer-follows-selected-frame} is @code{nil} (@pxref{Basic
+Minibuffer})), @kbd{C-g} closes the more recently opened ones,
+quitting their associated commands.
+
   On MS-DOS, the character @kbd{C-@key{Break}} serves as a quit character
 like @kbd{C-g}.  The reason is that it is not feasible, on MS-DOS, to
 recognize @kbd{C-g} while a command is running, between interactions
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index f0036f0ccf..da7c22eb9c 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -82,10 +82,12 @@ Intro to Minibuffers
 incrementing the number at the end of the name.  (The names begin with
 a space so that they won't show up in normal buffer lists.)  Of
 several recursive minibuffers, the innermost (or most recently
-entered) is the active minibuffer.  We usually call this @emph{the}
-minibuffer.  You can permit or forbid recursive minibuffers by setting
-the variable @code{enable-recursive-minibuffers}, or by putting
-properties of that name on command symbols (@xref{Recursive Mini}.)
+entered) is the @dfn{active minibuffer}--it is the one you can
+terminate by typing @key{RET} (@code{exit-minibuffer}) in.  We usually
+call this @emph{the} minibuffer.  You can permit or forbid recursive
+minibuffers by setting the variable
+@code{enable-recursive-minibuffers}, or by putting properties of that
+name on command symbols (@xref{Recursive Mini}.)
 
   Like other buffers, a minibuffer uses a local keymap
 (@pxref{Keymaps}) to specify special key bindings.  The function that
@@ -348,7 +350,7 @@ Text from Minibuffer
 @item @key{RET}
 @code{exit-minibuffer}
 
-@item @kbd{M-<}
+@item @key{M-<}
 @code{minibuffer-beginning-of-buffer}
 
 @item @kbd{C-g}
@@ -2380,7 +2382,8 @@ Minibuffer Commands
 
 @deffn Command exit-minibuffer
 This command exits the active minibuffer.  It is normally bound to
-keys in minibuffer local keymaps.
+keys in minibuffer local keymaps.  The command throws an error if the
+current buffer is not the active minibuffer.
 @end deffn
 
 @deffn Command self-insert-and-exit
@@ -2594,8 +2597,11 @@ Recursive Mini
 If this variable is non-@code{nil}, you can invoke commands (such as
 @code{find-file}) that use minibuffers even while the minibuffer is
 active.  Such invocation produces a recursive editing level for a new
-minibuffer.  The outer-level minibuffer is invisible while you are
-editing the inner one.
+minibuffer.  By default, the outer-level minibuffer is invisible while
+you are editing the inner one.  If you have
+@code{minibuffer-follows-selected-frame} set to @code{nil}, you can
+have minibuffers visible on several frames at the same time.
+@xref{Basic Minibuffer,,, emacs}.
 
 If this variable is @code{nil}, you cannot invoke minibuffer commands
 when the minibuffer is active, not even if you switch to another window
@@ -2623,7 +2629,7 @@ Minibuffer Misc
 @end defun
 
 @defvar minibuffer-setup-hook
-This is a normal hook that is run whenever the minibuffer is entered.
+This is a normal hook that is run whenever a minibuffer is entered.
 @xref{Hooks}.
 @end defvar
 
@@ -2641,7 +2647,7 @@ Minibuffer Misc
 @end defmac
 
 @defvar minibuffer-exit-hook
-This is a normal hook that is run whenever the minibuffer is exited.
+This is a normal hook that is run whenever a minibuffer is exited.
 @xref{Hooks}.
 @end defvar
 
diff --git a/etc/NEWS b/etc/NEWS
index eaaf9bfb0e..8c0c809231 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -102,12 +102,13 @@ effect should be negligible in the vast majority of cases anyway.
 By default, when you switch to another frame, an active minibuffer now
 moves to the newly selected frame.  Nevertheless, the effect of what
 you type in the minibuffer happens in the frame where the minibuffer
-was first activated, even if it moved to another frame.  An
-alternative behavior is available by customizing
-'minibuffer-follows-selected-frame' to nil.  Here, the minibuffer
-stays in the frame where you first opened it, and you must switch back
-to this frame to continue or abort its command.  The old, somewhat
-unsystematic behavior, which mixed these two is no longer available.
+was first activated.  An alternative behavior is available by
+customizing 'minibuffer-follows-selected-frame' to nil.  Here, the
+minibuffer stays in the frame where you first opened it, and you must
+switch back to this frame to continue or abort its command.  The old
+behavior, which mixed these two, can be approximated by customizing
+'minibuffer-follows-selected-frame' to a value which is neither nil
+nor t.
 
 +++
 ** New system for displaying documentation for groups of functions.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 85dd14f628..0293d34d1c 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -394,7 +394,11 @@ minibuffer-prompt-properties--setter
 	     ;;    			(directory :format "%v"))))
 	     (load-prefer-newer lisp boolean "24.4")
 	     ;; minibuf.c
-             (minibuffer-follows-selected-frame minibuffer boolean "28.1")
+	     (minibuffer-follows-selected-frame
+              minibuffer (choice (const :tag "Always" t)
+                                 (const :tag "When used" hybrid)
+                                 (const :tag "Never" nil))
+              "28.1")
 	     (enable-recursive-minibuffers minibuffer boolean)
 	     (history-length minibuffer
 			     (choice (const :tag "Infinite" t) integer)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 556f5d3a56..cbdd4a90f1 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2125,8 +2125,10 @@ exit-minibuffer
   ;; A better solution would be to make deactivate-mark buffer-local
   ;; (or to turn it into a list of buffers, ...), but in the mean time,
   ;; this should do the trick in most cases.
-  (setq deactivate-mark nil)
-  (throw 'exit nil))
+  (when (innermost-minibuffer-p)
+    (setq deactivate-mark nil)
+    (throw 'exit nil))
+  (error "%s" "Not in most nested minibuffer"))
 
 (defun self-insert-and-exit ()
   "Terminate minibuffer input."
diff --git a/lisp/window.el b/lisp/window.el
index 38be778906..a6cdd4dec2 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4116,7 +4116,10 @@ window-deletable-p
 				     frame))
 			(throw 'other t))))
 		  (let ((minibuf (active-minibuffer-window)))
-		    (and minibuf (eq frame (window-frame minibuf)))))
+		    (and minibuf (eq frame (window-frame minibuf))
+                         (not (eq (default-toplevel-value
+                                    minibuffer-follows-selected-frame)
+                                  t)))))
 	'frame))
      ((window-minibuffer-p window)
       ;; If WINDOW is the minibuffer window of a non-minibuffer-only
diff --git a/src/eval.c b/src/eval.c
index 706aafdf50..5bf3faebc8 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1167,9 +1167,18 @@ Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
 {
+  /* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
+     throwing t to tag `exit'.
+     Value -1 means there is no (throw 'exit t) in progress;
+     0 means the `throw' wasn't done from an active minibuffer;
+     N > 0 means the `throw' was done from the minibuffer at level N.  */
+  static EMACS_INT minibuffer_quit_level = -1;
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c = push_handler (tag, CATCHER);
 
+  if (EQ (tag, Qexit))
+    minibuffer_quit_level = -1;
+
   /* Call FUNC.  */
   if (! sys_setjmp (c->jmp))
     {
@@ -1183,6 +1192,23 @@ internal_catch (Lisp_Object tag,
       Lisp_Object val = handlerlist->val;
       clobbered_eassert (handlerlist == c);
       handlerlist = handlerlist->next;
+      if (EQ (tag, Qexit) && EQ (val, Qt))
+	/* If we've thrown t to tag `exit' from within a minibuffer, we
+	   exit all minibuffers more deeply nested than the current
+	   one.  */
+	{
+	  EMACS_INT mini_depth = this_minibuffer_depth (Qnil);
+	  if (mini_depth && mini_depth != minibuffer_quit_level)
+	    {
+	      if (minibuffer_quit_level == -1)
+		minibuffer_quit_level = mini_depth;
+	      if (minibuffer_quit_level
+		  && (minibuf_level > minibuffer_quit_level))
+		Fthrow (Qexit, Qt);
+	    }
+	  else
+	    minibuffer_quit_level = -1;
+	}
       return val;
     }
 }
diff --git a/src/lisp.h b/src/lisp.h
index d139df9342..86be25852a 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4346,6 +4346,8 @@ extern Lisp_Object Vminibuffer_list;
 extern Lisp_Object last_minibuf_string;
 extern void move_minibuffer_onto_frame (void);
 extern bool is_minibuffer (EMACS_INT, Lisp_Object);
+extern EMACS_INT this_minibuffer_depth (Lisp_Object);
+extern EMACS_INT minibuf_level;
 extern Lisp_Object get_minibuffer (EMACS_INT);
 extern void init_minibuf_once (void);
 extern void syms_of_minibuf (void);
diff --git a/src/minibuf.c b/src/minibuf.c
index 5ee440f662..758377532e 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -63,9 +63,30 @@ static Lisp_Object minibuf_prompt;
 
 static ptrdiff_t minibuf_prompt_width;
 
+static Lisp_Object nth_minibuffer (EMACS_INT depth);
+
 \f
+/* Return TRUE when a frame switch causes a minibuffer on the old
+   frame to move onto the new one. */
 static bool
 minibuf_follows_frame (void)
+{
+  return EQ (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame),
+             Qt);
+}
+
+/* Return TRUE when a minibuffer always remains on the frame where it
+   was first invoked. */
+static bool
+minibuf_stays_put (void)
+{
+  return NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
+}
+
+/* Return TRUE when opening a (recursive) minibuffer causes
+   minibuffers on other frames to move to the selected frame.  */
+static bool
+minibuf_moves_frame_when_opened (void)
 {
   return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_selected_frame));
 }
@@ -90,7 +111,7 @@ choose_minibuf_frame (void)
       minibuf_window = sf->minibuffer_window;
       /* If we've still got another minibuffer open, use its mini-window
          instead.  */
-      if (minibuf_level && !minibuf_follows_frame ())
+      if (minibuf_level > 1 && minibuf_stays_put ())
         {
           Lisp_Object buffer = get_minibuffer (minibuf_level);
           Lisp_Object tail, frame;
@@ -105,26 +126,40 @@ choose_minibuf_frame (void)
         }
     }
 
-  if (minibuf_follows_frame ())
+  if (minibuf_moves_frame_when_opened ()
+      && FRAMEP (selected_frame)
+      && FRAME_LIVE_P (XFRAME (selected_frame)))
     /* Make sure no other frame has a minibuffer as its selected window,
        because the text would not be displayed in it, and that would be
        confusing.  Only allow the selected frame to do this,
        and that only if the minibuffer is active.  */
-    {
-      Lisp_Object tail, frame;
-
-      FOR_EACH_FRAME (tail, frame)
-        if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (XFRAME (frame))))
-            && !(EQ (frame, selected_frame)
-                 && minibuf_level > 0))
-          Fset_frame_selected_window (frame, Fframe_first_window (frame),
-                                      Qnil);
-    }
+  {
+    Lisp_Object tail, frame;
+    struct frame *of;
+
+    FOR_EACH_FRAME (tail, frame)
+      if (!EQ (frame, selected_frame)
+          && minibuf_level > 1
+	  /* The frame's minibuffer can be on a different frame.  */
+	  && XWINDOW ((of = XFRAME (frame))->minibuffer_window)->frame
+	  != selected_frame)
+        {
+          if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
+            Fset_frame_selected_window (frame, Fframe_first_window (frame),
+                                        Qnil);
+
+          if (!EQ (XWINDOW (of->minibuffer_window)->contents,
+                   nth_minibuffer (0)))
+            set_window_buffer (of->minibuffer_window,
+                               nth_minibuffer (0), 0, 0);
+        }
+  }
 }
 
-/* If `minibuffer_follows_selected_frame' and we have a minibuffer, move it
-   from its current frame to the selected frame.  This function is
-   intended to be called from `do_switch_frame' in frame.c.  */
+/* If `minibuffer_follows_selected_frame' is t and we have a
+   minibuffer, move it from its current frame to the selected frame.
+   This function is intended to be called from `do_switch_frame' in
+   frame.c.  */
 void move_minibuffer_onto_frame (void)
 {
   if (!minibuf_level)
@@ -135,14 +170,18 @@ void move_minibuffer_onto_frame (void)
       && FRAME_LIVE_P (XFRAME (selected_frame))
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
+      EMACS_INT i;
       struct frame *sf = XFRAME (selected_frame);
       Lisp_Object old_frame = XWINDOW (minibuf_window)->frame;
       struct frame *of = XFRAME (old_frame);
-      Lisp_Object buffer = XWINDOW (minibuf_window)->contents;
 
-      set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
+      /* Stack up all the (recursively) open minibuffers on the selected
+         mini_window.  */
+      for (i = 1; i <= minibuf_level; i++)
+	set_window_buffer (sf->minibuffer_window, nth_minibuffer (i), 0, 0);
       minibuf_window = sf->minibuffer_window;
-      set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
+      if (of != sf)
+	set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
     }
 }
 
@@ -336,6 +375,39 @@ return t only if BUFFER is an active minibuffer.  */)
     ? Qt : Qnil;
 }
 
+DEFUN ("innermost-minibuffer-p", Finnermost_minibuffer_p,
+       Sinnermost_minibuffer_p, 0, 1, 0,
+       doc: /* Return t if BUFFER is the most nested active minibuffer.
+No argument or nil as argument means use the current buffer as BUFFER.  */)
+  (Lisp_Object buffer)
+{
+  if (NILP (buffer))
+    buffer = Fcurrent_buffer ();
+  return EQ (buffer, (Fcar (Fnthcdr (make_fixnum (minibuf_level),
+				     Vminibuffer_list))))
+    ? Qt
+    : Qnil;
+}
+
+/* Return the nesting depth of the active minibuffer BUFFER, or 0 if
+   BUFFER isn't such a thing.  If BUFFER is nil, this means use the current
+   buffer.  */
+EMACS_INT
+this_minibuffer_depth (Lisp_Object buffer)
+{
+  EMACS_INT i;
+  Lisp_Object bufs;
+
+  if (NILP (buffer))
+    buffer = Fcurrent_buffer ();
+  for (i = 1, bufs = Fcdr (Vminibuffer_list);
+       i <= minibuf_level;
+       i++, bufs = Fcdr (bufs))
+    if (EQ (Fcar (bufs), buffer))
+      return i;
+  return 0;
+}
+
 DEFUN ("minibuffer-prompt-end", Fminibuffer_prompt_end,
        Sminibuffer_prompt_end, 0, 0, 0,
        doc: /* Return the buffer position of the end of the minibuffer prompt.
@@ -411,6 +483,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object mini_frame, ambient_dir, minibuffer, input_method;
+  Lisp_Object calling_frame = selected_frame;
   Lisp_Object enable_multibyte;
   EMACS_INT pos = 0;
   /* String to add to the history.  */
@@ -648,6 +721,17 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
         }
     }
 
+  if (minibuf_moves_frame_when_opened ())
+  {
+    EMACS_INT i;
+
+    /* Stack up all the (recursively) open minibuffers on the selected
+       mini_window.  */
+    for (i = 1; i < minibuf_level; i++)
+      set_window_buffer (XFRAME (mini_frame)->minibuffer_window,
+                         nth_minibuffer (i), 0, 0);
+  }
+
   /* Display this minibuffer in the proper window.  */
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
@@ -729,6 +813,20 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 
   recursive_edit_1 ();
 
+  /* We've exited the recursive edit without an error, so switch the
+     current window away from the expired minibuffer window.  */
+  {
+    Lisp_Object prev = Fprevious_window (minibuf_window, Qnil, Qnil);
+    /* PREV can be on a different frame when we have a minibuffer only
+       frame, the other frame's minibuffer window is MINIBUF_WINDOW,
+       and its "focus window" is also MINIBUF_WINDOW.  */
+    while (!EQ (prev, minibuf_window)
+	   && !EQ (selected_frame, WINDOW_FRAME (XWINDOW (prev))))
+      prev = Fprevious_window (prev, Qnil, Qnil);
+    if (!EQ (prev, minibuf_window))
+      Fset_frame_selected_window (selected_frame, prev, Qnil);
+  }
+
   /* If cursor is on the minibuffer line,
      show the user we have exited by putting it in column 0.  */
   if (XWINDOW (minibuf_window)->cursor.vpos >= 0
@@ -767,6 +865,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
      in set-window-configuration.  */
   unbind_to (count, Qnil);
 
+  /* Switch the frame back to the calling frame.  */
+  if (!EQ (selected_frame, calling_frame)
+      && FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame)))
+    call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil);
+
   /* Add the value to the appropriate history list, if any.  This is
      done after the previous buffer has been made current again, in
      case the history variable is buffer-local.  */
@@ -790,6 +894,14 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
     && EQ (Fcar (tail), buf);
 }
 
+/* Return the DEPTHth minibuffer, or nil if such does not yet exist.  */
+static Lisp_Object
+nth_minibuffer (EMACS_INT depth)
+{
+  Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
+  return XCAR (tail);
+}
+
 /* Return a buffer to be used as the minibuffer at depth `depth'.
    depth = 0 is the lowest allowed argument, and that is the value
    used for nonrecursive minibuffer invocations.  */
@@ -2032,13 +2144,15 @@ For example, `eval-expression' uses this.  */);
 The function is called with the arguments passed to `read-buffer'.  */);
   Vread_buffer_function = Qnil;
 
-  DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
-               doc: /* Non-nil means the active minibuffer always displays on the selected frame.
+  DEFVAR_LISP ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame,
+               doc: /* t means the active minibuffer always displays on the selected frame.
 Nil means that a minibuffer will appear only in the frame which created it.
+Any other value means the minibuffer will move onto another frame, but
+only when the user starts using a minibuffer there.
 
 Any buffer local or dynamic binding of this variable is ignored.  Only the
 default top level value is used.  */);
-  minibuffer_follows_selected_frame = 1;
+  minibuffer_follows_selected_frame = Qt;
 
   DEFVAR_BOOL ("read-buffer-completion-ignore-case",
 	       read_buffer_completion_ignore_case,
@@ -2196,6 +2310,7 @@ uses to hide passwords.  */);
   defsubr (&Sminibuffer_prompt);
 
   defsubr (&Sminibufferp);
+  defsubr (&Sinnermost_minibuffer_p);
   defsubr (&Sminibuffer_prompt_end);
   defsubr (&Sminibuffer_contents);
   defsubr (&Sminibuffer_contents_no_properties);
diff --git a/src/window.c b/src/window.c
index 5e78aa400b..fe3a93f7ac 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2663,12 +2663,15 @@ static void
 decode_next_window_args (Lisp_Object *window, Lisp_Object *minibuf, Lisp_Object *all_frames)
 {
   struct window *w = decode_live_window (*window);
+  Lisp_Object miniwin = XFRAME (w->frame)->minibuffer_window;
 
   XSETWINDOW (*window, w);
   /* MINIBUF nil may or may not include minibuffers.  Decide if it
      does.  */
   if (NILP (*minibuf))
-    *minibuf = minibuf_level ? minibuf_window : Qlambda;
+    *minibuf = this_minibuffer_depth (XWINDOW (miniwin)->contents)
+      ? miniwin
+      : Qlambda;
   else if (!EQ (*minibuf, Qt))
     *minibuf = Qlambda;
 
diff --git a/src/window.h b/src/window.h
index 332cb3091f..79eb44e7a3 100644
--- a/src/window.h
+++ b/src/window.h
@@ -1124,10 +1124,6 @@ extern Lisp_Object echo_area_window;
 
 extern EMACS_INT command_loop_level;
 
-/* Depth in minibuffer invocations.  */
-
-extern EMACS_INT minibuf_level;
-
 /* Non-zero if we should redraw the mode lines on the next redisplay.
    Usually set to a unique small integer so we can track the main causes of
    full redisplays in `redisplay--mode-lines-cause'.  */

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> It is nevertheless the standard function to call to move focus to a
> different frame.

Yes, but since setting focus is problematic in general (because of the
many different ways it can be handled depending on the GUI and window
manager and age of the captain), we usually try to refrain from doing it
at all: it's usually a source of problems even if it looks like
a solution in the short term.

IIRC `raise-frame` is often a good middle ground which gets most of the
benefit of `select-frame-set-input-focus` with much fewer problems.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jan 09, 2021 at 20:34:12 -0500, Stefan Monnier wrote:
> > It is nevertheless the standard function to call to move focus to a
> > different frame.

> Yes, but since setting focus is problematic in general (because of the
> many different ways it can be handled depending on the GUI and window
> manager and age of the captain), we usually try to refrain from doing it
> at all: it's usually a source of problems even if it looks like
> a solution in the short term.

In this case, selecting the frame is the essential part of the process.
It happens after a minibuffer is exited, and selects the frame in which
the minibuffer was opened, the one in which the coming action is to take
place.

> IIRC `raise-frame` is often a good middle ground which gets most of the
> benefit of `select-frame-set-input-focus` with much fewer problems.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> It does call 'raise-frame' something people with 'focus-follows-mouse' t
 >> (not 'auto-raise') might not want here.  And it may have to move the
 >> mouse cursor according to the 'mouse-autoselect-window' and
 >> 'focus-follows-mouse' policies.  Most window managers don't handle the
 >> latter well (IIRC only the otherwise abominable mutter and KDE could do
 >> it approximately).  And the former wants the selected window to be set
 >> up well before calling 'select-frame-set-input-focus'.
 >
 > It is nevertheless the standard function to call to move focus to a
 > different frame.  If there are problems with focus-follows-mouse, they
 > should surely be fixed in frame.el as a separate problem.

The 'focus-follows-mouse' problem is a window manager problem and cannot
be fixed in frame.el.  It typically happens when he mouse pointer is (i)
over frame-1, one (ii) gives focus to frame-2 and (iii) moves the mouse
which causes the WM to refocus frame-1.  Some WMs here move the mouse
pointer in (ii) to frame-2 (and forcefully do that for pop up windows)
which can be however a pain for Emacs because the WM doesn't know where
in frame-2 to move it to and so with 'mouse-autoselect-window' a wrong
window may get auto-selected.

And please remain aware of the fact that focus stealing is, in general,
considered bad practice.  It shouldn't happen in the case at hand
because _some_ Emacs frame should already have focus when invoking
'select-frame-set-input-focus'.  Still, a window manager's local policy
settings might make it refrain from giving focus to some frame on behalf
of our request.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sun, Jan 10, 2021 at 17:04:57 +0100, martin rudalics wrote:
>  >> It does call 'raise-frame' something people with 'focus-follows-mouse' t
>  >> (not 'auto-raise') might not want here.  And it may have to move the
>  >> mouse cursor according to the 'mouse-autoselect-window' and
>  >> 'focus-follows-mouse' policies.  Most window managers don't handle the
>  >> latter well (IIRC only the otherwise abominable mutter and KDE could do
>  >> it approximately).  And the former wants the selected window to be set
>  >> up well before calling 'select-frame-set-input-focus'.

>  > It is nevertheless the standard function to call to move focus to a
>  > different frame.  If there are problems with focus-follows-mouse, they
>  > should surely be fixed in frame.el as a separate problem.

> The 'focus-follows-mouse' problem is a window manager problem and cannot
> be fixed in frame.el.  It typically happens when he mouse pointer is (i)
> over frame-1, one (ii) gives focus to frame-2 and (iii) moves the mouse
> which causes the WM to refocus frame-1.  Some WMs here move the mouse
> pointer in (ii) to frame-2 (and forcefully do that for pop up windows)
> which can be however a pain for Emacs because the WM doesn't know where
> in frame-2 to move it to and so with 'mouse-autoselect-window' a wrong
> window may get auto-selected.

> And please remain aware of the fact that focus stealing is, in general,
> considered bad practice.  It shouldn't happen in the case at hand
> because _some_ Emacs frame should already have focus when invoking
> 'select-frame-set-input-focus'.  Still, a window manager's local policy
> settings might make it refrain from giving focus to some frame on behalf
> of our request.

The need to set the focus is as follows.  Suppose we replace the
select-frame-set-input-focus with the select-frame (actually,
do_switch_frame) that was previously there.

With minibuffer-follows-selected-frame t (the default),
enable-recursive-minibuffers t:

Three frames F1, F2, F3:

On F1, C-x C-f foo.el.  Move to F2: C-x C-f bar.el.  Move to F3 C-x C-f
baz.el RET.

baz.el is visited in F3.  The minibuffers remain in F3.  Move point to
 *Minibuf-2* in F3, and type RET.  bar.el is visited in F2, BUT THE
FOCUS REMAINS IN F3.  This is suboptimal.  If we visit a file in a
frame, the focus should be on that frame, not somewhere else.  As an
analogy, C-x 5 f foo.el visits foo.el on another (typically new) frame
and MOVES THE FOCUS TO THAT FRAME.  Why shouldn't that be done in the
current scenario?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> On F1, C-x C-f foo.el.  Move to F2: C-x C-f bar.el.  Move to F3 C-x C-f
> baz.el RET.
>
> baz.el is visited in F3.  The minibuffers remain in F3.  Move point to
>  *Minibuf-2* in F3, and type RET.  bar.el is visited in F2, BUT THE
> FOCUS REMAINS IN F3.  This is suboptimal.

It depends on many aspects.  I don't expect `C-x C-f` to affect
focus, so this "suboptimal" looks OK to me (with "me" wearing my cap
of Emacs user using a WM where the focus follows the mouse).
It would also be OK (and probably better) to raise the frame F2, since
it might be (partly) hidden by F3.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > Three frames F1, F2, F3:
 >
 > On F1, C-x C-f foo.el.  Move to F2: C-x C-f bar.el.  Move to F3 C-x C-f
 > baz.el RET.
 >
 > baz.el is visited in F3.  The minibuffers remain in F3.  Move point to
 >   *Minibuf-2* in F3, and type RET.  bar.el is visited in F2, BUT THE
 > FOCUS REMAINS IN F3.  This is suboptimal.  If we visit a file in a
 > frame, the focus should be on that frame, not somewhere else.  As an
 > analogy, C-x 5 f foo.el visits foo.el on another (typically new) frame
 > and MOVES THE FOCUS TO THAT FRAME.

This "MOVES THE FOCUS TO THAT FRAME" is done by the WM.  Emacs doesn't
care normally because it usually can't fight it anyway (you can try by
setting the ‘no-focus-on-map’ frame parameter but it's no general cure).
With practically all WMs, a new window always gets focus automatically.

 > Why shouldn't that be done in the
 > current scenario?

Because we are talking about a frame (F2) that already exists in your
scenario.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sun, Jan 10, 2021 at 18:49:03 +0100, martin rudalics wrote:
>  > Three frames F1, F2, F3:

>  > On F1, C-x C-f foo.el.  Move to F2: C-x C-f bar.el.  Move to F3 C-x C-f
>  > baz.el RET.

>  > baz.el is visited in F3.  The minibuffers remain in F3.  Move point to
>  >   *Minibuf-2* in F3, and type RET.  bar.el is visited in F2, BUT THE
>  > FOCUS REMAINS IN F3.  This is suboptimal.  If we visit a file in a
>  > frame, the focus should be on that frame, not somewhere else.  As an
>  > analogy, C-x 5 f foo.el visits foo.el on another (typically new) frame
>  > and MOVES THE FOCUS TO THAT FRAME.

> This "MOVES THE FOCUS TO THAT FRAME" is done by the WM.  Emacs doesn't
> care normally because it usually can't fight it anyway (you can try by
> setting the ‘no-focus-on-map’ frame parameter but it's no general cure).
> With practically all WMs, a new window always gets focus automatically.

>  > Why shouldn't that be done in the current scenario?

> Because we are talking about a frame (F2) that already exists in your
> scenario.

Sorry, that answer doesn't fit the question I though I was asking.

What I meant was that it is surely a good thing that after visiting a
file with C-x C-f, the focus ends up in the frame where the file's
buffer is.  Why does this cease to be a good thing if the frame already
exists?

Note other scenarios where the frame already exists, such as C-x 5 b
foo.el RET when foo.el is already displayed in another frame.  The focus
is moved to that other frame.  Whether that is done by Emacs or the WM
is immaterial, the focus MUST be moved, otherwise there'd be no point to
doing the C-x 5 b.

Similarly with a "deferred" C-x C-f, the focus must also be moved.
Surely?

I'll need to go back a bit to try and understand the arguments against
shifting the focus.  Right at the moment, I'm not seeing them.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > What I meant was that it is surely a good thing that after visiting a
 > file with C-x C-f, the focus ends up in the frame where the file's
 > buffer is.  Why does this cease to be a good thing if the frame already
 > exists?

We do call `select-frame-set-input-focus' in `pop-to-buffer' when the
buffer is on another frame and obviously in C-x 5 o.  These are probably
its most prominent clients.

 > Note other scenarios where the frame already exists, such as C-x 5 b
 > foo.el RET when foo.el is already displayed in another frame.  The focus
 > is moved to that other frame.  Whether that is done by Emacs or the WM
 > is immaterial, the focus MUST be moved, otherwise there'd be no point to
 > doing the C-x 5 b.

I talked about the WM because you mentioned showing a buffer in a
"typically new" frame.

 > Similarly with a "deferred" C-x C-f, the focus must also be moved.
 > Surely?
 >
 > I'll need to go back a bit to try and understand the arguments against
 > shifting the focus.  Right at the moment, I'm not seeing them.

It's completely up to you whether to use it or not.  But in my
experience any code is better without dealing with frame focus.  In
particular when there's still a hanging visit for foo.el in F1.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> I do still find his manner of expression difficult to deal with.
>

I apologized once, I will not do this again.  I've read my previous mails 
to you again, and don't see anything wrong in what I said.

>> It did not "turn out", I explained in detail that the behavior that 
>> Alan considered buggy was not at all buggy before he started working on 
>> this.
>
> I don't think you "explained" at all, and certainly not before I started 
> working on it - I initiated the discussion with a proposed patch so as 
> to minimise the risk of just wasting people's time with bikeshedding.
>

I did tell you that the behavior you found incoherent was not, and that 
this behavior was an old one dating back to Emacs 21 at least, three days 
before you initiated the discussion.  That happened in the "New 
multi-command facility displays in the wrong echo area" thread.

>
> You keep referring to an "old behaviour" that I removed, as though there 
> were something coherent, something valuable, something worth keeping. I 
> don't think there's anything of the kind.  I think the former behaviour 
> just happened by accident as a result of people working on other things, 
> and nobody consciously made it happen.  I am now consciously trying to 
> fix it.  If you've argued for an old behaviour on its merits, possibly 
> in the thread "stealing eachother's minibuffers", could you perhaps 
> point out the place in that thread, so that I can read it again.
>

The old behavior is indeed valuable, if only because it is an old 
behavior.  Emacs' stability is important.  I don't see why the burden of 
proof that a behavior about which virtually no Emacs user in the last 
twenty years complained is not a bad one would be on me.

You believe that the old behavior is chaotic and happened by accident, but 
it is also possible that your belief is wrong.

The old behavior is, at the very least, not chaotic, it is well defined: 
from a user's point of view, when a recursive minibuffer is entered in a 
frame F2 while one or more recursive minibuffers are active on a frame F1, 
these minibuffers are moved from frame F1 to frame F2 before the new 
minibuffer is created.  Saying that this is not an "ad hoc unsystematic 
mess" is not expressing an opinion among other opinions.

>> What could have been done instead is to add some new code next to the 
>> existing one to conditionally provide a new behavior,
>
> That could not have been done, due to the state of the code in 
> minibuf.c, in particular, due to the lack of any coherent "existing 
> behaviour".

I looked at your 2ecbf4cfae7, c3edaa55249 and 6e469709c55 commits, and at 
your patch, and I don't see why the old code could not continue to exist 
next to the new one.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> The old behavior is indeed valuable, if only because it is an old behavior.
> Emacs' stability is important.  I don't see why the burden of proof that
> a behavior about which virtually no Emacs user in the last twenty years
> complained is not a bad one would be on me.

    M-x lisp-date-mode RET

signaled an error in all Emacsen until now.
Yet no user complained about it over all these years.
Should we add a config var so users can get back the old behavior?


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> The old behavior is indeed valuable, if only because it is an old 
>> behavior. Emacs' stability is important.  I don't see why the burden of 
>> proof that a behavior about which virtually no Emacs user in the last 
>> twenty years complained is not a bad one would be on me.
>
>    M-x lisp-date-mode RET
>
> signaled an error in all Emacsen until now. Yet no user complained about 
> it over all these years. Should we add a config var so users can get 
> back the old behavior?
>

I think you meant "lisp-data-mode".  I'm not sure you are teasing me, so:

(1) The "[No match]" error in earlier Emacsen is clear, there is no reason 
a user would have complained about it.

(2) The likelihood that a user tries to type M-x lisp-data-mode RET when 
no such mode exists is very, very low compared to the likelihood that a 
user interacts with the minibuffer.  Admittedly the scenario that is being 
discussed here is more precise than "interacting with the minibuffer", but 
I did experience the old behavior several times without ever thinking it 
was a bug, and found it perfectly coherent.  And I never tried to type M-x 
lisp-data-mode RET.

(3) The old behavior is in this case very easy to get back AFAICS: (fset 
'lisp-data-mode nil).

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> I think you meant "lisp-data-mode".

Indeed.

> I'm not sure you are teasing me, so:

No, I'm just pointing out that even such an "obviously nothing but a new
feature" implies a change in old behavior.  The same applies to the most
obvious "bug fixes" and to basically every single commit we ever apply.
Even adding a config var to recover the old behavior is itself a change
in old behavior.

So your rule is simply inapplicable.  You seem to think it's obvious to
distinguish between a change in behavior and a bug fix or a new feature
or other categories, and while in many cases it is, there are also many
cases where it's not and *that* is the reason why we sometimes introduce
a change without a clean way to recover the old behavior: we failed to
recognize that it wasn't just a bug fix or a plain improvement.

New rules won't help.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So your rule is simply inapplicable.  You seem to think it's obvious to
  > distinguish between a change in behavior and a bug fix or a new feature
  > or other categories, and while in many cases it is, there are also many
  > cases where it's not and *that* is the reason why we sometimes introduce
  > a change without a clean way to recover the old behavior: we failed to
  > recognize that it wasn't just a bug fix or a plain improvement.

Yes, that does happen.  We can't avoid that.

But, as the y-or-n-p problem shows, there are times when people make a
change that is obviously intended to change the UI, and isn't fixing a
bug.  And yet we changed the default and did not add a variable to
control the change.

If we adopt a rule about these situations, we will do better.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 07 Jan 2021 02:52:33 -0500
> Cc: ghe@sdf.org, acm@muc.de, emacs-devel@gnu.org
> 
> But, as the y-or-n-p problem shows, there are times when people make a
> change that is obviously intended to change the UI, and isn't fixing a
> bug.

That is incorrect: the change was made to fix annoying
(a.k.a. "buggy") behavior, whereby some async message displayed while
y-or-n-p was prompting the user would completely hide the prompt, and
Emacs would be left in a state where it expects the user to type
something, but doesn't say so.

> If we adopt a rule about these situations, we will do better.

It depends on the rules.  The rules proposed until now will definitely
cause us to do worse, which is unjustified given how rare these cases
happen.

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Wed, Jan 06, 2021 at 00:14:45 +0000, Gregory Heytings wrote:


> > I do still find his manner of expression difficult to deal with.

> I apologized once, I will not do this again.  I've read my previous
> mails to you again, and don't see anything wrong in what I said.

Let me repeat, it is not the content of your posts I find difficult to
deal with.  It's their rudeness and aggressiveness.  If you'd said what
you had to say in a gentle and co-operative manner, as for example Martin
does when disagreeing with me, I wouldn't now be asking myself if
responding to your posts is worth it at all.
 
> >> It did not "turn out", I explained in detail that the behavior that
> >> Alan considered buggy was not at all buggy before he started working
> >> on this.

> > I don't think you "explained" at all, and certainly not before I started 
> > working on it - I initiated the discussion with a proposed patch so as 
> > to minimise the risk of just wasting people's time with bikeshedding.

> I did tell you that the behavior you found incoherent was not, and that 
> this behavior was an old one dating back to Emacs 21 at least, three days 
> before you initiated the discussion.  That happened in the "New 
> multi-command facility displays in the wrong echo area" thread.

You "told" me, and seem to expect that I accept what you say without
question, as though you were some sort of guru.  On this particular
point, you seem to be mistaken, or at the very least in a minority of
one.

> > You keep referring to an "old behaviour" that I removed, as though there 
> > were something coherent, something valuable, something worth keeping. I 
> > don't think there's anything of the kind.  I think the former behaviour 
> > just happened by accident as a result of people working on other things, 
> > and nobody consciously made it happen.  I am now consciously trying to 
> > fix it.  If you've argued for an old behaviour on its merits, possibly 
> > in the thread "stealing eachother's minibuffers", could you perhaps 
> > point out the place in that thread, so that I can read it again.

> The old behavior is indeed valuable, if only because it is an old 
> behavior.

So you're defending old bugs as valuable, simply because they're old.  You
decline to defend this behaviour on its merits.  Nobody else has done so
either, as far as I'm aware.

> Emacs' stability is important.  I don't see why the burden of proof
> that a behavior about which virtually no Emacs user in the last twenty
> years complained is not a bad one would be on me.

Ratchet your level of abstraction down a notch or two, please.  We're
talking about a particular bit of behaviour, which if somebody proposed
as new on emacs-devel would get rejected out of hand, and indeed
ridiculed.  I was asking you to provide me with missing information,
something which might persuade me that this behaviour was less chaotic
and more systematic than it outwardly appears.

Emacs's "stability", in the way you seem to mean it would prevent new
developments and old bug fixing from happening.

> You believe that the old behavior is chaotic and happened by accident, but 
> it is also possible that your belief is wrong.

Not really.  You're not telling me somebody sat down at his computer one
day, and said "hey, it'd be a great idea if the minibuffer changed frames
when and only when a recursive minibuffer were opened on another frame"?
Be serious, such an abstruse "design" can only have arisen by accident.

> The old behavior is, at the very least, not chaotic, it is well defined: 
> from a user's point of view, when a recursive minibuffer is entered in a 
> frame F2 while one or more recursive minibuffers are active on a frame F1, 
> these minibuffers are moved from frame F1 to frame F2 before the new 
> minibuffer is created.  Saying that this is not an "ad hoc unsystematic 
> mess" is not expressing an opinion among other opinions.

> >> What could have been done instead is to add some new code next to the 
> >> existing one to conditionally provide a new behavior,

> > That could not have been done, due to the state of the code in 
> > minibuf.c, in particular, due to the lack of any coherent "existing 
> > behaviour".

> I looked at your 2ecbf4cfae7, c3edaa55249 and 6e469709c55 commits, and
> at your patch, and I don't see why the old code could not continue to
> exist next to the new one.

I am the person doing the work, not you.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> Let me repeat, it is not the content of your posts I find difficult to 
> deal with.  It's their rudeness and aggressiveness.
>

I think we are miscommunicating.  I honestly don't understand where you 
perceive "rudeness and aggressiveness" in my posts.  I can only say again 
that this was not at all my intention.

>
>> The old behavior is indeed valuable, if only because it is an old 
>> behavior.
>
> So you're defending old bugs as valuable, simply because they're old. 
> You decline to defend this behaviour on its merits.  Nobody else has 
> done so either, as far as I'm aware.
>

I did defend it on its merits, multiple times.  What I said did not 
convince you; I should perhaps have written something more detailed, as I 
do below.

I experienced the behavior which surprised you from time to time, and 
found it coherent with the general Emacs behavior.

Let's first define that behavior again: from a user's point of view, in 
Emacs 21 (and possibly earlier) to 27, when minibuffers MB1 to MBn are 
active on a frame F1, and a command that activates the minibuffer is 
started on a frame F2, the minibuffers MB1 to MBn are moved to frame F2, 
and the minibuffer MBn+1 is created.  This behavior happens with 
enable-recursive-minibuffers set to t, either globally or temporarily.

The other possible behaviors are, AFAICS, the ones you try to implement:

1. Either tying each minibuffer to the frame in which it is created.  If 
you tie each minibuffer to the frame in which it was created, there are 
two options:

1.1. Either it becomes possible to interact with them.  From an UI point 
of view, the problem of that behavior is that it is not coherent with 
recursive edits in Emacs, of which recursive minibuffers are an instance. 
When you enter a recursive edit you cannot act on the non-recursive edit 
level or on the previous recursive edit levels anymore, you first have to 
leave the current recursive edit.  As the Emacs manual explains, recursive 
edits "constrain you to go back in a particular order---from the innermost 
level toward the top level."  IOW, that behavior would violate the general 
recursive editing constraint.

1.2. Or you make sure in one way or another that it is not possible to 
interact with them, which means that the user sees a minibuffer that it 
cannot use (for instance by clicking on it).  From an UI point of view, 
this would be counter-intuitive; I don't know any other UI element that is 
displayed by Emacs and that you cannot interact with.

2. Or always moving the minibuffers to the currently active frame.  From 
an UI point of view, the problem is that such a movement is, in most 
cases, gratuitious: when you start a command in a frame and switch to 
another frame, in most cases this switch is a temporary one (for example 
to check the documentation of the command you just started), and what you 
intend to do is to switch back to the frame in which you started the 
command to complete it.

The old behavior, which you despise, is not "chaotic" (see the definition 
of that word in Wordnet: "completely unordered and unpredictable and 
confusing", or in Wiktionary: "extremely disorganized"), it is 
well-defined, and it is a reasonable solution which avoids (at least) 
these three problems.  And it has worked well for virtually all Emacs 
users in the last twenty years.

There is, in fact, a fourth possible behavior, which AFAICT has not been 
discussed in this thread:

1.3. Tying each minibuffer to the frame in which it is created, but make 
it invisible when a recursive minibuffer is entered in another frame, and 
visible again when that recursive minibuffer is left.  The problem I see 
in this potential behavior is that, upon leaving the recursive minibuffer, 
the user would have no indication that another minibuffer is still (or 
rather, again) open in another frame, waiting for their input.  This is 
yet another problem that the old behavior avoids.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

> Also, how often do people actually select minibuffer-only frames?
> Unless I'm missing something, it seems a rather strange thing to want to
> do.

It's an integral part of the minibuffer-only frame setup: When you start
a non-modal dialogue and want to do something else in between, then you
eventually want to select the minibuffer-only frame in order to continue
that dialogue.

martin

Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Thu, Nov 26, 2020 at 16:43:13 +0100, martin rudalics wrote:
> > Also, how often do people actually select minibuffer-only frames?
> > Unless I'm missing something, it seems a rather strange thing to want to
> > do.

> It's an integral part of the minibuffer-only frame setup: When you start
> a non-modal dialogue and want to do something else in between, then you
> eventually want to select the minibuffer-only frame in order to continue
> that dialogue.

OK.  Thanks!

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets]

martin rudalics <rudalics@gmx.at> writes:

> Can both of you confirm that reverting that change fixes the behavior?
> Patch attached.

With the patch applied, normal frame became selected and accept input
after 'C-h f setq RET' and remains the same after typing 'q' in the
*Help* buffer.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 >> Can both of you confirm that reverting that change fixes the behavior?
 >> Patch attached.
 >
 > With the patch applied, normal frame became selected and accept input
 > after 'C-h f setq RET' and remains the same after typing 'q' in the
 > *Help* buffer.

The 'Type C-x 1 ...' text would be more appropriate but apparently the
'quit-restore parameter doesn't get set up accordingly.  I won't change
that.

Thank you, martin

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> reveals another aspect broken by your change.  The values reported by
> 'selected-window' and 'select-frame' do not match up any more (unless
> our masochistic way or printing frame names hides an important detail).

You mean that (selected-frame) != (window-frame)?
That's an important invariant to preserve.  We've had problems with this
for years and I've worked pretty hard to fix them over the years (I've
been tempted to remove the `selected_frame` variable and define
SELECTED_FRAME on top of `selected_window` instead, but that's proved
difficult in the `select-frame` and `select-window` code).


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > You mean that (selected-frame) != (window-frame)?

Yes.  But Alan's last fix might have fixed this part now.

 > That's an important invariant to preserve.  We've had problems with this
 > for years and I've worked pretty hard to fix them over the years (I've
 > been tempted to remove the `selected_frame` variable and define
 > SELECTED_FRAME on top of `selected_window` instead, but that's proved
 > difficult in the `select-frame` and `select-window` code).

Maybe we should try again.

martin

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > But if it results in regressions with packages to maple-minibuffer or
 > mini-frame, we should of course try and address that (either by refining
 > the behavior or by changing the default).

Both, Andrii's and Madhu's scenarios, have to be fixed.  Then we might
be able to get rid of other oddities like 'redirect-frame-focus' and
frame auto hiding as well.  What we want to do here is to track
non-modal user dialogues in our own way.  In particular, we want to
handle the case that a user wants to suspend such a dialogue and do
something else in between, either in Emacs or in another application.

The major issues then are how to handle the following actions wrt the
Emacs windows participating in that dialogue: mouse clicks and hovering,
alt-tabbing and altering the window configuration via C-x o, C-x 5 o,
window creation and deletion.  Before and after Alan's changes all of
these do not work satisfactorily.

Most applications I know of do not allow such non-modal dialogues.  And
I know of no other application that may display messages in the same
area where a prompt appears which further complicates things with Emacs.

martin

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> Both, Andrii's and Madhu's scenarios, have to be fixed.  Then we might
> be able to get rid of other oddities like 'redirect-frame-focus' 

What do you mean by that?  I certainly don't want Emacs
to get rid of being able to redirect a frame's focus to
a different frame.  This is an important (even necessary)
feature, IMO.

> Most applications I know of do not allow such non-modal dialogues.

I don't know what this means, e.g. what you mean by
"application" here.  Emacs has always let you use other
windows and frames while a minibuffer remains active,
and it should continue to allow that.

But I'm probably misunderstanding you, here.  At least
I hope I am.

Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

 > What do you mean by that?  I certainly don't want Emacs
 > to get rid of being able to redirect a frame's focus to
 > a different frame.  This is an important (even necessary)
 > feature, IMO.

Not IMO.

 >> Most applications I know of do not allow such non-modal dialogues.
 >
 > I don't know what this means, e.g. what you mean by
 > "application" here.  Emacs has always let you use other
 > windows and frames while a minibuffer remains active,
 > and it should continue to allow that.
 >
 > But I'm probably misunderstanding you, here.  At least
 > I hope I am.

You've been misunderstanding me here.

martin

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> The defaults are selected for the common usage patterns.  It is not
> clear to me that the test case you presented is common.  But if it is,
> perhaps we do need to consider changing the default.
> 
> Does anyone else think this is common usage, to have a minibuffer-only
> frame while other frames also have minibuffers?
> 
> Alternatively, perhaps minibuffers activated in minibuffer-only frames
> should behave specially in this regard?

FWIW (not much, I'm afraid):

I can't speak to this, as Emacs 27 has totally broken
Emacs for me.  And specifically wrt changing frame
focus while using the minibuffer (which in my case is
in a standalone frame).

(I've mentioned this before.  And yes, it's too bad
that I have no specifics that might help track down
the problem.  I have to continue to use Emacs 26, to
be able to use Emacs at all.)

Something - dunno what, and dunno whether I'll ever
have the time to somehow track it down - makes it
impossible to use Emacs 27 with my setup, which has
a dedicated frame for *Completions* whose focus is
automatically redirected to the standalone minibuffer
frame.

Just sayin', to mention that at least one user has
been bit badly by _something_ that changed from Emacs
26 to 27 - something in the area of frame focus and
the minibuffer.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> I can't speak to this, as Emacs 27 has totally broken
> Emacs for me.  And specifically wrt changing frame
> focus while using the minibuffer (which in my case is
> in a standalone frame).

Do you have a bug#nb for it?


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Andrii Kolomoiets
>  <andreyk.mad@gmail.com>,  enometh@meer.net
> Date: Tue, 10 Nov 2020 14:51:23 -0500
> 
> > I can't speak to this, as Emacs 27 has totally broken
> > Emacs for me.  And specifically wrt changing frame
> > focus while using the minibuffer (which in my case is
> > in a standalone frame).
> 
> Do you have a bug#nb for it?

Nice try.

RE: Stop frames stealing eachothers' minibuffers!

[Drew Adams]

> > I can't speak to this, as Emacs 27 has totally broken
> > Emacs for me.  And specifically wrt changing frame
> > focus while using the minibuffer (which in my case is
> > in a standalone frame).
> 
> Do you have a bug#nb for it?

I filed bug #41087 for it, but as I said (there & here), I
haven't been able to come up with operational info about it.

Maybe at some point I'll have some time to dig into it.

Otherwise, I'm vaguely hoping that someone will run into
a related problem that will eventually lead to fixing or
reverting whatever (also) caused my problems in this regard.

That's perhaps unlikely, if it inherently involves a
*Completions* frame whose input is redirected to a standalone
minibuffer.  There are no doubt few, if any, others in a
similar boat.  I don't know that those things are inherent
to the problems, however, so I still have a glimmer of hope.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

Hi Eli,

>
> You should try this with the emacs-27 branch, because Gregory's patch 
> installed there (and will be soon merged to master) changes the behavior 
> quite a bit.
>

It only changes the behavior for the echo area, not for minibuffers.  For 
minibuffers the behavior has not changed since Emacs 24: when a recursive 
minibuffer is entered in a frame, all other recursive minibuffers (if any) 
are moved from the frame in which they were to that frame.

>> The current master seems to me to be inconsistent, in that whether the 
>> minibuffer moves from F1 to F2 depends on whether the Isearch used a 
>> (recursive) minibuffer.
>
> AFAICT, this no longer happens.
>

It does.  As I said a few hours ago, there are three possible behaviors 
when each frame has its miniwindow:

A. when a (recursive) minibuffer is entered in a frame, all other 
minibuffers (if any) are moved from the frame in which they were to that 
frame

B. if one or more (recursive) minibuffers are active when switching to 
another frame (for example with C-x 5 o) these minibuffers are moved to 
that other frame

C. each (recursive) minibuffer is tied to the frame in which it was 
activated, that is, minibuffers are never moved from one frame to another

Behavior A is the current one.  Behavior B is what Stefan seems to favor. 
Behavior C is what Alan seems to favor.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> I'm not quite sure what a mini-window is.  Does it mean the window 
> within which the minibuffer is displayed?  As in max-mini-window-height?
>

The mini-window is usually at the bottom of the Emacs frame and is usually 
only one line tall.  It does not have a mode-line.  It displays the 
minibuffer (for interactive use, with C-x C-f, M-x, ...) and the echo area 
(for messages).

>> So if we cannot reconcile our preferences, maybe we should have a user 
>> option to decide which behavior to choose.
>
> Perhaps.  If we can formulate the two (or several) options in a 
> non-confusing way.  This is a fairly arcane matter.
>

AFAIU, the possible options include at least:

- keep the current behavior, with which all recursive minibuffers are 
moved from one frame to another when one or more minibuffers are active in 
one frame, and a new recursive activation happens in another frame (which 
happens only when enable-recursive-minibuffers is t)

- move all recursive minibuffers from one frame to the other when 
switching to another frame

- tie each one of the recursive minibuffers to the frame in which it was 
activated

(Of course the above options only make sense when there is one miniwindow 
in each frame.)

Re: Stop frames stealing eachothers' minibuffers!

[Andreas Schwab]

On Okt 13 2020, Gregory Heytings via "Emacs development discussions." wrote:

> I agree with you on one thing: C-x 8 RET should raise a "Command attempted
> to use minibuffer while in minibuffer" error in this case (when 
> enable-recursive-minibuffers is nil, which is its default value).  I'm not
> sure why it doesn't.

Because read-char-by-name binds enable-recursive-minibuffers to t.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>> I agree with you on one thing: C-x 8 RET should raise a "Command 
>> attempted to use minibuffer while in minibuffer" error in this case 
>> (when enable-recursive-minibuffers is nil, which is its default value). 
>> I'm not sure why it doesn't.
>
> Because read-char-by-name binds enable-recursive-minibuffers to t.
>

That's it.  I should have checked.  Thank you!

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> I agree with you on one thing: C-x 8 RET should raise a "Command attempted
>> to use minibuffer while in minibuffer" error in this case (when 
>> enable-recursive-minibuffers is nil, which is its default value).  I'm not
>> sure why it doesn't.
> Because read-char-by-name binds enable-recursive-minibuffers to t.

Which it does to allow you to use `C-x 8 RET` to insert unicode chars
into minibuffers.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> Seeing as how a minibuffer often has a strong association with its frame
>> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
>> this shifting of minibuffers from one frame to another is confusing.
> Is it?  It makes sure the minibuffer is on the selected frame, which
> is natural in many/most use cases.

But it only makes sure after you used another minibuffer, so in the
remaining 90% of the cases you're still left with an active minibuffer
that is not on the selected frame.

If that 90% is not considered a problem, then I wonder what's different
after using a nested minibuffer to justify the current behavior?


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 18:28:39 -0400
> 
> >> Seeing as how a minibuffer often has a strong association with its frame
> >> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
> >> this shifting of minibuffers from one frame to another is confusing.
> > Is it?  It makes sure the minibuffer is on the selected frame, which
> > is natural in many/most use cases.
> 
> But it only makes sure after you used another minibuffer

Maybe that's the bug we should fix, then?  Not "play along" with it by
making the exceptions be the rule?

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

>> >> Seeing as how a minibuffer often has a strong association with its frame
>> >> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
>> >> this shifting of minibuffers from one frame to another is confusing.
>> > Is it?  It makes sure the minibuffer is on the selected frame, which
>> > is natural in many/most use cases.
>> But it only makes sure after you used another minibuffer
> Maybe that's the bug we should fix, then?

You mean, we'd make the active minibuffer follow along with changes to
the selected frame?  Yes, that would be more consistent.
I think that's what we do with the echo area already, so there's
precedent for it.

I can't tell if it would be an improvement or a regression (I think it
wouldn't affect my use cases either way).


        Stefan


PS: Just trying out now the echo-area case to check I remembered it
right, I see we have a bug there (that dates back to Emacs-25 at least):

    % emacs -Q src/emacs.c
    C-x 5 b RET
    M-: (message "hello") RET
    ... use your window manager to select the other frame ...

we now see "hello" in both miniwindows, whereas I expected it to be seen
only in the selected frame (i.e. to be erased from the previously
selected frame).

    C-g

we now see "Quit" in one of the miniwindows and "hello" in the other.

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

>
> You mean, we'd make the active minibuffer follow along with changes to 
> the selected frame?  Yes, that would be more consistent. I think that's 
> what we do with the echo area already, so there's precedent for it.
>

Why not, but it's not what Alan would have wanted.  IIUC, what he wants is 
to tie each one of the recursive minibuffers to the frame in which it was 
activated.

>
> % emacs -Q src/emacs.c
> C-x 5 b RET
> M-: (message "hello") RET
> ... use your window manager to select the other frame ...
>
> we now see "hello" in both miniwindows, whereas I expected it to be seen 
> only in the selected frame (i.e. to be erased from the previously 
> selected frame).
>
>    C-g
>
> we now see "Quit" in one of the miniwindows and "hello" in the other.
>

I just checked.  This behavior is not present in Emacs 21-23.  It is 
present since Emacs 24.

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 17:32:56 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Eli Zaretskii <eliz@gnu.org>, acm@muc.de, emacs-devel@gnu.org
> 
> > % emacs -Q src/emacs.c
> > C-x 5 b RET
> > M-: (message "hello") RET
> > ... use your window manager to select the other frame ...
> >
> > we now see "hello" in both miniwindows, whereas I expected it to be seen 
> > only in the selected frame (i.e. to be erased from the previously 
> > selected frame).
> >
> >    C-g
> >
> > we now see "Quit" in one of the miniwindows and "hello" in the other.
> >
> 
> I just checked.  This behavior is not present in Emacs 21-23.  It is 
> present since Emacs 24.

Crystal ball says that this is one consequence of not redisplaying
non-selected frames as much as Emacs 21-23 did.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> Crystal ball says that this is one consequence of not redisplaying
> non-selected frames as much as Emacs 21-23 did.

Indeed, it sounds like a result of my changes in this area.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 13:22:28 -0400
> 
> >> >> Seeing as how a minibuffer often has a strong association with its frame
> >> >> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
> >> >> this shifting of minibuffers from one frame to another is confusing.
> >> > Is it?  It makes sure the minibuffer is on the selected frame, which
> >> > is natural in many/most use cases.
> >> But it only makes sure after you used another minibuffer
> > Maybe that's the bug we should fix, then?
> 
> You mean, we'd make the active minibuffer follow along with changes to
> the selected frame?  Yes, that would be more consistent.
> I think that's what we do with the echo area already, so there's
> precedent for it.

Yes.

> I can't tell if it would be an improvement or a regression (I think it
> wouldn't affect my use cases either way).
> 
> 
>         Stefan
> 
> 
> PS: Just trying out now the echo-area case to check I remembered it
> right, I see we have a bug there (that dates back to Emacs-25 at least):
> 
>     % emacs -Q src/emacs.c
>     C-x 5 b RET
>     M-: (message "hello") RET
>     ... use your window manager to select the other frame ...
> 
> we now see "hello" in both miniwindows, whereas I expected it to be seen
> only in the selected frame (i.e. to be erased from the previously
> selected frame).
> 
>     C-g
> 
> we now see "Quit" in one of the miniwindows and "hello" in the other.

We are slowly eradicating problems like this one.  Alan's proposal
suggests that we move in the opposite direction, which I think would
be a mistake.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> We are slowly eradicating problems like this one.  Alan's proposal
> suggests that we move in the opposite direction, which I think would
> be a mistake.

I think both behaviors make sense: keep the echo-areas and minibuffers
in the mini-window to which they "belong" (e.g. the mini-window
associated with the `minibuffer-selected-window`), or make them follow
the `selected-frame`.


        Stefan

Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via Emacs development discussions.]

Hi Alan,

>
> In recent versions of master (and, I believe the emacs-27 branch) frames 
> steal eachothers' minibuffers.
>
> By this I mean:
> (i) Have two frames open displaying buffers.
> (ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
> (iii) Move to F2.
> (iv) Do C-x 8 RET <enter some character>.
>
> F1's minibuffer is now on F2.  This is bad.
>

As I told you a few days ago, this is not a new Emacs behavior, it dates 
back to at least Emacs 24 (and probably earlier, I did not check).  IMO 
this behavior is not problematic: the minibuffer has moved to F2, but when 
you press RET after choosing the buffer you want, the buffer switch 
happens in F1, where it should happen.  And on a TTY, Emacs even goes back 
to F1.

Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

> Comments?

FWIW, I really like this patch.  I haven't tried it to see how it
behaves, but from the look of it, it seems very unlikely to affect my
usage pattern (I only have a single mini window shared by all my frames,
anyway).


        Stefan