bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

Description of the bug:

When I have action to repeatedly be asked something from mini buffer,
then I often move cursor from mini buffer to some other buffer. Normally
screen is split into two or more buffer. If I move the other window's
buffer to something else like picture by using (next-buffer) bound on
the key, I am then reading the picture and getting information which I
then enter into mini buffer. When I press enter in the minibuffer the
other window's buffer where the picture was switches back to what it was
previously. In my opinion it should not as user has decided to switch
buffer of that window to something else.

To repeat:

- bind command next-buffer to F5

- you may split window, but need not. Just have more than 1 buffer in total

- run this function

(defun ask-repeat ()
  (unless (string= (read-from-minibuffer "What? ") "bye")
    (ask-repeat)))

(ask-repeat)

- from mini buffer move cursor to the window

- press F5 to switch to next buffer

- move cursor back to mini buffer and enter something

At that point one may see that the window's buffer switched back to
what it was previously. User's workflow is disturbed.


In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
 of 2020-11-25 built on protected.rcdrun.com
Repository revision: 30c437752df0a3a9410f1249fa0f237110811af2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=/package/text/emacs --with-modules
 --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  text-scale-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny rfc822 mml
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map text-property-search seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils macros kmacro time-date subr-x help-fns
radix-tree cl-print debug backtrace help-mode easymenu find-func
dired-aux cl-loaddefs cl-lib dired dired-loaddefs face-remap tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 61185 11565)
 (symbols 48 7938 1)
 (strings 32 22818 2137)
 (string-bytes 1 719909)
 (vectors 16 12953)
 (vector-slots 8 179043 11957)
 (floats 8 33 37)
 (intervals 56 359 8)
 (buffers 984 15))

-- 
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> At that point one may see that the window's buffer switched back to
> what it was previously. User's workflow is disturbed.

Yes, when exiting a recursive edit, Emacs will (try to) restore the
window configuration in place when the recursive edit was entered.

This can be somewhat confusing -- I can see why somebody would want to
avoid that.  Is there some user option to control this?  I have a brief
look, but didn't find anything.  If not, would it make sense to add one?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-07 19:11]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > At that point one may see that the window's buffer switched back to
> > what it was previously. User's workflow is disturbed.
> 
> Yes, when exiting a recursive edit, Emacs will (try to) restore the
> window configuration in place when the recursive edit was entered.
> 
> This can be somewhat confusing -- I can see why somebody would want to
> avoid that.  Is there some user option to control this?  I have a brief
> look, but didn't find anything.  If not, would it make sense to add one?

What makes sense is not to have that by default and let users switch
windows as they wish. If I have horizontally split windows:

1
--
2
--
minibuffer

and I change window 1 to 4, upon completing minibuffer window 1
becomes 4. I cannot see why. I need to consult 2-3 buffers while using
minibuffer.

Why is that default there?

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Eli Zaretskii]

> Date: Mon, 7 Dec 2020 19:42:45 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45072@debbugs.gnu.org
> 
> Why is that default there?

Because minibuffer input can easily create one or more additional
windows, e.g. to show the completion candidates, and we don't want
that to be left on display when you exit the minibuffer.

My recommendation is not to "abuse" the recursive editing; the ELisp
manual rightfully warns against that, albeit indirectly.  If you
frequently need ti switch away of the minibuffer without exiting it, I
suggest to use a separate frame for your excursions: when exiting the
minibuffer, Emacs only restores the windows on the frame where you
entered the minibuffer (assuming you aren't using minibuffer-only
frames).

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-07 20:20]:
> > Date: Mon, 7 Dec 2020 19:42:45 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 45072@debbugs.gnu.org
> > 
> > Why is that default there?
> 
> Because minibuffer input can easily create one or more additional
> windows, e.g. to show the completion candidates, and we don't want
> that to be left on display when you exit the minibuffer.
> 
> My recommendation is not to "abuse" the recursive editing; the ELisp
> manual rightfully warns against that, albeit indirectly.  If you
> frequently need ti switch away of the minibuffer without exiting it, I
> suggest to use a separate frame for your excursions: when exiting the
> minibuffer, Emacs only restores the windows on the frame where you
> entered the minibuffer (assuming you aren't using minibuffer-only
> frames).

If there is logic and reason fine, we close this?

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Eli Zaretskii]

> Date: Mon, 7 Dec 2020 21:49:02 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, 45072@debbugs.gnu.org
> 
> > My recommendation is not to "abuse" the recursive editing; the ELisp
> > manual rightfully warns against that, albeit indirectly.  If you
> > frequently need ti switch away of the minibuffer without exiting it, I
> > suggest to use a separate frame for your excursions: when exiting the
> > minibuffer, Emacs only restores the windows on the frame where you
> > entered the minibuffer (assuming you aren't using minibuffer-only
> > frames).
> 
> If there is logic and reason fine, we close this?

The defaults are definitely fine, IMO.  But if you want very much to
have an opt-in behavior to disable restoring of the window
configuration of the frame, I won't object to such an option.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-07 22:28]:
> > Date: Mon, 7 Dec 2020 21:49:02 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: larsi@gnus.org, 45072@debbugs.gnu.org
> > 
> > > My recommendation is not to "abuse" the recursive editing; the ELisp
> > > manual rightfully warns against that, albeit indirectly.  If you
> > > frequently need ti switch away of the minibuffer without exiting it, I
> > > suggest to use a separate frame for your excursions: when exiting the
> > > minibuffer, Emacs only restores the windows on the frame where you
> > > entered the minibuffer (assuming you aren't using minibuffer-only
> > > frames).
> > 
> > If there is logic and reason fine, we close this?
> 
> The defaults are definitely fine, IMO.  But if you want very much to
> have an opt-in behavior to disable restoring of the window
> configuration of the frame, I won't object to such an option.

I think I am only one and is not necessary. I can setup environment
better like you said. I was editing geographic coordinates one after
the other and one cannot make a mistake there and I need to watch
pictures while editing which are in various buffers.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

 > The defaults are definitely fine, IMO.  But if you want very much to
 > have an opt-in behavior to disable restoring of the window
 > configuration of the frame, I won't object to such an option.

Patch attached, just in case.  99% untested.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuf.c.diff --]
[-- Type: text/x-patch; name="minibuf.c.diff", Size: 2155 bytes --]

diff --git a/src/minibuf.c b/src/minibuf.c
index fc3fd92a88..9874e71a2f 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -500,19 +500,21 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,

   record_unwind_protect_void (choose_minibuf_frame);

-  record_unwind_protect (restore_window_configuration,
-                         Fcons (Qt, Fcurrent_window_configuration (Qnil)));
+  if (!read_from_minibuffer_no_restore)
+    record_unwind_protect (restore_window_configuration,
+			   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))
+
+  if (!read_from_minibuffer_no_restore && !EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
 			   Fcons (/* Arrange for the frame later to be
-                                     switched back to the calling
-                                     frame. */
-                                  Qnil,
-                                  Fcurrent_window_configuration (mini_frame)));
+				     switched back to the calling
+				     frame. */
+				  Qnil,
+				  Fcurrent_window_configuration (mini_frame)));

   /* If the minibuffer is on an iconified or invisible frame,
      make it visible now.  */
@@ -2186,6 +2188,14 @@ syms_of_minibuf (void)
 uses to hide passwords.  */);
   Vread_hide_char = Qnil;

+  DEFVAR_BOOL ("read-from-minibuffer-no-restore", read_from_minibuffer_no_restore,
+	       doc: /* Non-nil means `read-from-minibuffer' does not restore window configurations.
+If this is nil, `read-from-minibuffer' will restore, on exit, the window
+configurations of the frame where it was called from and, if it is
+different, the frame that owns the minibuffer window.  If this is
+non-nil, no such restorations are done.  */);
+  read_from_minibuffer_no_restore = false;
+
   defsubr (&Sactive_minibuffer_window);
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Patch attached, just in case.  99% untested.

[...]

> +  DEFVAR_BOOL ("read-from-minibuffer-no-restore", read_from_minibuffer_no_restore,
> +	       doc: /* Non-nil means `read-from-minibuffer' does not restore window configurations.
> +If this is nil, `read-from-minibuffer' will restore, on exit, the window
> +configurations of the frame where it was called from and, if it is
> +different, the frame that owns the minibuffer window.  If this is
> +non-nil, no such restorations are done.  */);
> +  read_from_minibuffer_no_restore = false;

Looks good to me, but I'd revert the logic, as "negative" variables have
a tendency to be misunderstood.  That is, call the variable
`read-from-minibuffer-restore' and default it to t instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-08 17:10]:
> martin rudalics <rudalics@gmx.at> writes:

Thank you all!

Jean

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > Looks good to me, but I'd revert the logic, as "negative" variables have
 > a tendency to be misunderstood.  That is, call the variable
 > `read-from-minibuffer-restore' and default it to t instead.

Coming from the frame/window department I'm usually against defaulting
options to non-nil because nil-valued and absent parameters behave the
same way.  But I have no problems doing what you propose.  Let's see if
anyone really wants such an option.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-08 17:47]:
> > Looks good to me, but I'd revert the logic, as "negative" variables have
> > a tendency to be misunderstood.  That is, call the variable
> > `read-from-minibuffer-restore' and default it to t instead.
> 
> Coming from the frame/window department I'm usually against defaulting
> options to non-nil because nil-valued and absent parameters behave the
> same way.  But I have no problems doing what you propose.  Let's see if
> anyone really wants such an option.

I would prefer by default not to switch windows for me as if I am user
and switched the other buffer why would I need it automatically back?
I switched it because I do not need it.

Please understand how it is to work in a loop in minibuffer, many
coordinates have to be entered carefully and various maps consulted,
and then even though buffers were switched there and back on each new
invocation of minibuffer prompt all those buffers go away.

From the view point of having user control, I would rather have that
option turned off by default.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Eli Zaretskii]

> Date: Tue, 8 Dec 2020 17:58:40 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
>   45072@debbugs.gnu.org
> 
> I would prefer by default not to switch windows for me as if I am user
> and switched the other buffer why would I need it automatically back?
> I switched it because I do not need it.
> 
> Please understand how it is to work in a loop in minibuffer, many
> coordinates have to be entered carefully and various maps consulted,
> and then even though buffers were switched there and back on each new
> invocation of minibuffer prompt all those buffers go away.
> 
> >From the view point of having user control, I would rather have that
> option turned off by default.

I understand your POV, but we cannot possibly change such a
long-standing behavior by default.  It must start as an opt-in
behavior.  Later, when enough people tried it and said they'd like it
to be the default, we might start thinking about making it the
default.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-08 19:09]:
> > Date: Tue, 8 Dec 2020 17:58:40 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
> >   45072@debbugs.gnu.org
> > 
> > I would prefer by default not to switch windows for me as if I am user
> > and switched the other buffer why would I need it automatically back?
> > I switched it because I do not need it.
> > 
> > Please understand how it is to work in a loop in minibuffer, many
> > coordinates have to be entered carefully and various maps consulted,
> > and then even though buffers were switched there and back on each new
> > invocation of minibuffer prompt all those buffers go away.
> > 
> > >From the view point of having user control, I would rather have that
> > option turned off by default.
> 
> I understand your POV, but we cannot possibly change such a
> long-standing behavior by default.  It must start as an opt-in
> behavior.  Later, when enough people tried it and said they'd like it
> to be the default, we might start thinking about making it the
> default.

I totally and generally agree on the approach not to change
default. It is just opinion, I would not change defaults as it would
influence many.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Jean Louis <bugs@gnu.support>,
>   45072@debbugs.gnu.org
> Date: Tue, 08 Dec 2020 15:09:15 +0100
> 
> Looks good to me, but I'd revert the logic, as "negative" variables have
> a tendency to be misunderstood.  That is, call the variable
> `read-from-minibuffer-restore' and default it to t instead.

Yes.  But maybe read-from-minibuffer-restore-windows would be even
better.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

 > Yes.  But maybe read-from-minibuffer-restore-windows would be even
 > better.

And `read-minibuffer-restore-windows' would be even shorter.  Attached.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-minibuffer-restore-windows.diff --]
[-- Type: text/x-patch; name="read-minibuffer-restore-windows.diff", Size: 3045 bytes --]

--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -458,6 +458,19 @@ Text from Minibuffer
 list is used in the prompt.
 @end defun

+@defvar read-minibuffer-restore-windows
+If this option is non-@code{nil} (the default), getting input from the
+minibuffer will restore, on exit, the window configurations of the frame
+where the minibuffer was entered from and, if it is different, the frame
+that owns the minibuffer window.  This means that if, for example, a
+user splits a window while getting input from the minibuffer on the same
+frame, that split will be undone when exiting the minibuffer.
+
+If this option is @code{nil}, no such restorations are done.  Hence, the
+window split mentioned above will persist after exiting the minibuffer.
+@end defvar
+
+
 @node Object from Minibuffer
 @section Reading Lisp Objects with the Minibuffer
 @cindex minibuffer input, reading lisp objects
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -500,19 +500,21 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,

   record_unwind_protect_void (choose_minibuf_frame);

-  record_unwind_protect (restore_window_configuration,
-                         Fcons (Qt, Fcurrent_window_configuration (Qnil)));
+  if (read_minibuffer_restore_windows)
+    record_unwind_protect (restore_window_configuration,
+			   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))
+
+  if (read_minibuffer_restore_windows && !EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
 			   Fcons (/* Arrange for the frame later to be
-                                     switched back to the calling
-                                     frame. */
-                                  Qnil,
-                                  Fcurrent_window_configuration (mini_frame)));
+				     switched back to the calling
+				     frame. */
+				  Qnil,
+				  Fcurrent_window_configuration (mini_frame)));

   /* If the minibuffer is on an iconified or invisible frame,
      make it visible now.  */
@@ -2186,6 +2188,15 @@ syms_of_minibuf (void)
 uses to hide passwords.  */);
   Vread_hide_char = Qnil;

+  DEFVAR_BOOL ("read-minibuffer-restore-windows", read_minibuffer_restore_windows,
+	       doc: /* Non-nil means restore window configurations on exit from minibuffer.
+If this is non-nil (the default), reading input with the minibuffer will
+restore, on exit, the window configurations of the frame where the
+minibuffer was entered from and, if it is different, the frame that owns
+the associated minibuffer window.  If this is nil, no such restorations
+are done.  */);
+  read_minibuffer_restore_windows = true;
+
   defsubr (&Sactive_minibuffer_window);
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

>> Yes.  But maybe read-from-minibuffer-restore-windows would be even
>> better.
>
> And `read-minibuffer-restore-windows' would be even shorter.  Attached.
>
> +  DEFVAR_BOOL ("read-minibuffer-restore-windows", read_minibuffer_restore_windows,
> +	       doc: /* Non-nil means restore window configurations on exit from minibuffer.
> +If this is non-nil (the default), reading input with the minibuffer will
> +restore, on exit, the window configurations of the frame where the
> +minibuffer was entered from and, if it is different, the frame that owns
> +the associated minibuffer window.  If this is nil, no such restorations
> +are done.  */);
> +  read_minibuffer_restore_windows = true;

I recommend to install this patch.  Maybe it's not perfect, but works
reasonably well, and there is the high demand for this feature.
Only such additional patch is necessary:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-minibuffer-restore-windows-exit-minibuffer.patch --]
[-- Type: text/x-diff, Size: 690 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3751ba80e0..40454eed23 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2319,6 +2333,10 @@ exit-minibuffer
       (error "%s" "Not in most nested command loop"))
     (when (not (innermost-minibuffer-p))
       (error "%s" "Not in most nested minibuffer")))
+  ;; When read_minibuf doesn't restore all previous windows,
+  ;; then at least pop down the completions window.
+  (unless read-minibuffer-restore-windows
+    (minibuffer-hide-completions))
   ;; 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.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> + DEFVAR_BOOL ("read-minibuffer-restore-windows",
>> read_minibuffer_restore_windows,
>> + doc: /* Non-nil means restore window configurations on exit from
>> minibuffer.
>> +If this is non-nil (the default), reading input with the minibuffer will
>> +restore, on exit, the window configurations of the frame where the
>> +minibuffer was entered from and, if it is different, the frame that owns
>> +the associated minibuffer window.  If this is nil, no such restorations
>> +are done.  */);
>> +  read_minibuffer_restore_windows = true;
>
> I recommend to install this patch.  Maybe it's not perfect, but works
> reasonably well, and there is the high demand for this feature.

Oh, I didn't realise that it hadn't been applied already, so I redid it
for the current trunk and tested it, and it seems to work as expected,
so I went ahead and pushed it.

> Only such additional patch is necessary:

[...]

> +  ;; When read_minibuf doesn't restore all previous windows,
> +  ;; then at least pop down the completions window.
> +  (unless read-minibuffer-restore-windows
> +    (minibuffer-hide-completions))

Hm...  Well, I guess that's what most people would want...  but...
should it be user-controllable?  Perhaps read_minibuffer_restore_windows
shouldn't be a boolean, but allow values like t, 'completions and nil,
where 'completions would trigger this behaviour?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>> +  ;; When read_minibuf doesn't restore all previous windows,
>> +  ;; then at least pop down the completions window.
>> +  (unless read-minibuffer-restore-windows
>> +    (minibuffer-hide-completions))
>
> Hm...  Well, I guess that's what most people would want...  but...

The new option read-minibuffer-restore-windows is quite unusable
without the above change: selecting a completion from the
completions buffer will leave the completions buffer on the screen.

> should it be user-controllable?  Perhaps read_minibuffer_restore_windows
> shouldn't be a boolean, but allow values like t, 'completions and nil,
> where 'completions would trigger this behaviour?

Then I propose a new hook, e.g. read-minibuffer-restore-functions
with the default value '(minibuffer-hide-completions).  Then such hook
could be run instead of restoring the window configuration, i.e.
the logic could be:

  if (read_minibuffer_restore_windows)
    record_unwind_protect (restore_window_configuration,
			   list3 (Fcurrent_window_configuration (Qnil),
				  Qt, Qt));
  else
    safe_run_hooks (Qread_minibuffer_restore_functions);

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> +  ;; When read_minibuf doesn't restore all previous windows,
>>> +  ;; then at least pop down the completions window.
>>> +  (unless read-minibuffer-restore-windows
>>> +    (minibuffer-hide-completions))
>>
>> Hm...  Well, I guess that's what most people would want...  but...
>
> The new option read-minibuffer-restore-windows is quite unusable
> without the above change: selecting a completion from the
> completions buffer will leave the completions buffer on the screen.

Yes.  But I think some people would want that -- that is, they might be
`C-g'-ing out of the minubuffer just because they want to copy some of
the text in the completions buffer.

But on the other hand, that may be such a rare thing to do that just
applying your proposed patch is the right thing, and then we could just
see whether anybody actually requests that before tinkering any further
with it...

So...  I think you should just push the patch, and then we'll see.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>>>> +  ;; When read_minibuf doesn't restore all previous windows,
>>>> +  ;; then at least pop down the completions window.
>>>> +  (unless read-minibuffer-restore-windows
>>>> +    (minibuffer-hide-completions))
>>>
>>> Hm...  Well, I guess that's what most people would want...  but...
>>
>> The new option read-minibuffer-restore-windows is quite unusable
>> without the above change: selecting a completion from the
>> completions buffer will leave the completions buffer on the screen.
>
> Yes.  But I think some people would want that -- that is, they might be
> `C-g'-ing out of the minubuffer just because they want to copy some of
> the text in the completions buffer.
>
> But on the other hand, that may be such a rare thing to do that just
> applying your proposed patch is the right thing, and then we could just
> see whether anybody actually requests that before tinkering any further
> with it...
>
> So...  I think you should just push the patch, and then we'll see.

Actually, my previous patch doesn't handle the case of `C-g'-ing
out of the minubuffer.  It hides the completions buffer
only after exiting in the normal way by RET.

But fortunately there is an existing hook 'minibuffer-exit-hook'
called in both cases of exiting by `C-g' and RET.
And the users can easily change it, e.g. to not pop down
the *Completions* buffer, or to remove more windows, etc.

diff --git a/etc/NEWS b/etc/NEWS
index f0fa686bc9..cca6956275 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -180,6 +180,8 @@ nor t.
 
 +++
 ** New user option 'read-minibuffer-restore-windows'.
+When customized to nil, it uses 'minibuffer-restore-windows' in
+'minibuffer-exit-hook' to remove only the *Completions* window.
 
 +++
 ** New system for displaying documentation for groups of functions.
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3751ba80e0..79fb7e6afc 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2328,6 +2342,16 @@ exit-minibuffer
   (setq deactivate-mark nil)
   (throw 'exit nil))
 
+(defun minibuffer-restore-windows ()
+  "Restore some windows on exit from minibuffer.
+When `read-minibuffer-restore-windows' is nil, then this function
+added to `minibuffer-exit-hook' will remove at least the window
+with the *Completions* buffer."
+  (unless read-minibuffer-restore-windows
+    (minibuffer-hide-completions)))
+
+(add-hook 'minibuffer-exit-hook 'minibuffer-restore-windows)
+
 (defun minibuffer-quit-recursive-edit ()
   "Quit the command that requested this recursive edit without error.
 Like `abort-recursive-edit' without aborting keyboard macro
diff --git a/src/minibuf.c b/src/minibuf.c
index 3ee0dca5e0..a054f0e20d 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -2535,8 +2535,11 @@ syms_of_minibuf (void)
 If this is non-nil (the default), reading input with the minibuffer will
 restore, on exit, the window configurations of the frame where the
 minibuffer was entered from and, if it is different, the frame that owns
-the associated minibuffer window.  If this is nil, no such restorations
-are done.  */);
+the associated minibuffer window.
+
+If this is nil, no such restorations are done.
+But still `minibuffer-restore-windows' in `minibuffer-exit-hook'
+will remove the window with the *Completions* buffer.  */);
   read_minibuffer_restore_windows = true;
 
   defsubr (&Sactive_minibuffer_window);

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But fortunately there is an existing hook 'minibuffer-exit-hook'
> called in both cases of exiting by `C-g' and RET.
> And the users can easily change it, e.g. to not pop down
> the *Completions* buffer, or to remove more windows, etc.

Looks good to me (but I haven't actually tried the patch).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

tags 45072 fixed
close 45072 28.0.50
quit

>> But fortunately there is an existing hook 'minibuffer-exit-hook'
>> called in both cases of exiting by `C-g' and RET.
>> And the users can easily change it, e.g. to not pop down
>> the *Completions* buffer, or to remove more windows, etc.
>
> Looks good to me (but I haven't actually tried the patch).

So now pushed and this request is closed.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>> The defaults are definitely fine, IMO.  But if you want very much to
>> have an opt-in behavior to disable restoring of the window
>> configuration of the frame, I won't object to such an option.
>
> Patch attached, just in case.  99% untested.

Thanks, sometime ago I asked how this would be possible to do,
and now I'm testing your patch (it missed trailing spaces on diff
context lines, but still applies without problems).

It seems to be really useful this option needs to keep only windows
implicitly created by the user, but remove windows created
automatically by mibibuffer-related commands such as the buffer
*Completions*.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > Thanks, sometime ago I asked how this would be possible to do,
 > and now I'm testing your patch (it missed trailing spaces on diff
 > context lines, but still applies without problems).
 >
 > It seems to be really useful this option needs to keep only windows
 > implicitly created by the user, but remove windows created
 > automatically by mibibuffer-related commands such as the buffer
 > *Completions*.

Such windows must be removed by the mechanism that created them.  I
hardly ever see such windows here because I'm apparently using some
arcane completions mechanism that always puts them in place right away.
But if I'm not mistaken, several such windows may pop up during one and
the same minibuffer input operation and IMO all of them should pop down
automatically as soon as they served their purpose.

A case could be made in the sense that by default the minibuffer window
itself won't shrink back after the completions have been shown there.
But I suppose that people using such a mechanism should also set
'resize-mini-windows' to t.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-09 12:34]:
> > Thanks, sometime ago I asked how this would be possible to do,
> > and now I'm testing your patch (it missed trailing spaces on diff
> > context lines, but still applies without problems).
> >
> > It seems to be really useful this option needs to keep only windows
> > implicitly created by the user, but remove windows created
> > automatically by mibibuffer-related commands such as the buffer
> > *Completions*.
>
> Such windows must be removed by the mechanism that created them.  I
> hardly ever see such windows here because I'm apparently using some
> arcane completions mechanism that always puts them in place right away.
> But if I'm not mistaken, several such windows may pop up during one and
> the same minibuffer input operation and IMO all of them should pop down
> automatically as soon as they served their purpose.

I am not sure if my case was understood, let me use artist-mode:

 +----------------------------+
 |                            |
 | I was changing this        |
 | during minibuffer edit     |
 +----------------------------+
 | I was also changing this   |
 | during minibuffer editd    |		-
 |                    	      |
 +----------------------------+
 +----------------------------+

If I would have larger screen I would put all necessary buffers around
and use them to get references for minibuffer input. Instead I was
switching buffers in upper windows during minibuffer edit. It is not
related to shrinking or completions. My minibuffer was not completing
rather just reading string. During editing I would go up and switch to
one image or other. I was in the loop of minibuffer editing of
multiple coordinates. Upon each editing the already set images in
upper windows would switch back where minibuffer was invoked
initially.

That forces me to use outside program to keep pictures on screen when
required and makes editing less useful.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 >> Such windows must be removed by the mechanism that created them.  I
 >> hardly ever see such windows here because I'm apparently using some
 >> arcane completions mechanism that always puts them in place right away.
 >> But if I'm not mistaken, several such windows may pop up during one and
 >> the same minibuffer input operation and IMO all of them should pop down
 >> automatically as soon as they served their purpose.
 >
 > I am not sure if my case was understood, let me use artist-mode:
 >
 >   +----------------------------+
 >   |                            |
 >   | I was changing this        |
 >   | during minibuffer edit     |
 >   +----------------------------+
 >   | I was also changing this   |
 >   | during minibuffer editd    |		-
 >   |                    	      |
 >   +----------------------------+
 >   +----------------------------+
 >
 > If I would have larger screen I would put all necessary buffers around
 > and use them to get references for minibuffer input. Instead I was
 > switching buffers in upper windows during minibuffer edit. It is not
 > related to shrinking or completions. My minibuffer was not completing
 > rather just reading string. During editing I would go up and switch to
 > one image or other. I was in the loop of minibuffer editing of
 > multiple coordinates. Upon each editing the already set images in
 > upper windows would switch back where minibuffer was invoked
 > initially.
 >
 > That forces me to use outside program to keep pictures on screen when
 > required and makes editing less useful.

Have you tried my latest patch?

The problem Juri raised is that Emacs itself might pop up or reuse other
windows in order to display text related to the minibuffer interaction
and I think that such windows should be deleted or get their buffer
restored by the interaction itself (using 'quit-window' probably).

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>> Thanks, sometime ago I asked how this would be possible to do,
>> and now I'm testing your patch (it missed trailing spaces on diff
>> context lines, but still applies without problems).
>>
>> It seems to be really useful this option needs to keep only windows
>> implicitly created by the user, but remove windows created
>> automatically by mibibuffer-related commands such as the buffer
>> *Completions*.
>
> Such windows must be removed by the mechanism that created them.  I
> hardly ever see such windows here because I'm apparently using some
> arcane completions mechanism that always puts them in place right away.
> But if I'm not mistaken, several such windows may pop up during one and
> the same minibuffer input operation and IMO all of them should pop down
> automatically as soon as they served their purpose.
>
> A case could be made in the sense that by default the minibuffer window
> itself won't shrink back after the completions have been shown there.
> But I suppose that people using such a mechanism should also set
> 'resize-mini-windows' to t.

What do you think about let-binding a new variable
read-minibuffer-record-windows to nil around functions
that pop up completion windows?

I mean for example in minibuffer-completion-help:

  (let ((read-minibuffer-record-windows nil))
    (display-completion-list completions))

The default value of read-minibuffer-record-windows could be t,
so it will record new windows created by the user, e.g. by C-x 2.
But when let-bound to nil, it won't record windows created
by completion commands, so these windows won't be restored
after exiting the minibuffer.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > What do you think about let-binding a new variable
 > read-minibuffer-record-windows to nil around functions
 > that pop up completion windows?
 >
 > I mean for example in minibuffer-completion-help:
 >
 >    (let ((read-minibuffer-record-windows nil))
 >      (display-completion-list completions))
 >
 > The default value of read-minibuffer-record-windows could be t,
 > so it will record new windows created by the user, e.g. by C-x 2.
 > But when let-bound to nil, it won't record windows created
 > by completion commands, so these windows won't be restored
 > after exiting the minibuffer.

We'd have to augment the 'quit-restore' mechanism somehow and run it on
all windows instead of restoring the configuration.

But I still don't understand the logic of the following:

(1) Start minibuffer interaction, type a-

(2) Pop up a completion window for a- and accept suggestion a-b

(3) Type another - so you now get a-b-

(4) Pop up a completion window for a-b- and accept a-b-c

In this scenario I'd want, after accepting a-b, the completion window to
disappear (or show its old buffer again) without the minibuffer action
having terminated.  So I'm still convinced that restoring a previous
state should be triggered by the completion mechanism and not by the
read from minibuffer mechanism.

One thing that has to be considered too is user interaction during
completion: Suppose I have one window, the completion mechanism pops up
a new one and I delete the old one.  Terminating completion now cannot
delete the new window (especially if it's on the only frame in use) but
has to show another buffer in the new window.  It maybe should try to
show the one previously shown in the old window.

And let's not forget that the completion mechanism might pop up a new
frame or a window on any other frame.  In such case, restoring window
configurations won't help at all.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-10 10:45]:
> > What do you think about let-binding a new variable
> > read-minibuffer-record-windows to nil around functions
> > that pop up completion windows?
> >
> > I mean for example in minibuffer-completion-help:
> >
> >    (let ((read-minibuffer-record-windows nil))
> >      (display-completion-list completions))
> >
> > The default value of read-minibuffer-record-windows could be t,
> > so it will record new windows created by the user, e.g. by C-x 2.
> > But when let-bound to nil, it won't record windows created
> > by completion commands, so these windows won't be restored
> > after exiting the minibuffer.
> 
> We'd have to augment the 'quit-restore' mechanism somehow and run it on
> all windows instead of restoring the configuration.
> 
> But I still don't understand the logic of the following:
> 
> (1) Start minibuffer interaction, type a-
> 
> (2) Pop up a completion window for a- and accept suggestion a-b
> 
> (3) Type another - so you now get a-b-
> 
> (4) Pop up a completion window for a-b- and accept a-b-c
> 
> In this scenario I'd want, after accepting a-b, the completion window to
> disappear (or show its old buffer again) without the minibuffer action
> having terminated.  So I'm still convinced that restoring a previous
> state should be triggered by the completion mechanism and not by the
> read from minibuffer mechanism.

I am trying to see relevance here, maybe I miss something. The
built-in completion does not replace the window which I am looking it.
It may make its visible part somewhat smaller, but not replace it.

Then I change buffers in those windows. Apart from being made somewhat
narrower, windows are not replaced by completion. 

And I did not even use completion. I was entering information on minibuffer.

> One thing that has to be considered too is user interaction during
> completion: Suppose I have one window, the completion mechanism pops up
> a new one and I delete the old one

I have not ever see that in built-in Emacs completion. But maybe it exists. 

I have seen completion poping up new window, but not replacing or
deleting other window.

Jean

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > I am trying to see relevance here, maybe I miss something. The
 > built-in completion does not replace the window which I am looking it.
 > It may make its visible part somewhat smaller, but not replace it.
 >
 > Then I change buffers in those windows. Apart from being made somewhat
 > narrower, windows are not replaced by completion.
 >
 > And I did not even use completion. I was entering information on minibuffer.
 >
 >> One thing that has to be considered too is user interaction during
 >> completion: Suppose I have one window, the completion mechanism pops up
 >> a new one and I delete the old one
 >
 > I have not ever see that in built-in Emacs completion. But maybe it exists.
 >
 > I have seen completion poping up new window, but not replacing or
 > deleting other window.

All these scenarios are with customizations.  I'm not experienced enough
to tell whether they (can) happen in practice.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-10 12:47]:
> > I am trying to see relevance here, maybe I miss something. The
> > built-in completion does not replace the window which I am looking it.
> > It may make its visible part somewhat smaller, but not replace it.
> >
> > Then I change buffers in those windows. Apart from being made somewhat
> > narrower, windows are not replaced by completion.
> >
> > And I did not even use completion. I was entering information on minibuffer.
> >
> >> One thing that has to be considered too is user interaction during
> >> completion: Suppose I have one window, the completion mechanism pops up
> >> a new one and I delete the old one
> >
> > I have not ever see that in built-in Emacs completion. But maybe it exists.
> >
> > I have seen completion poping up new window, but not replacing or
> > deleting other window.
> 
> All these scenarios are with customizations.  I'm not experienced enough
> to tell whether they (can) happen in practice.

Do you refer to standard completion in minibuffer that it may be
customized to replace a present window with the completion instead of
opening new windows?

That would be nice as I would like to avoid those jerks when there are
2 horizontal windows and then third one appears for completion jerking
both of them up and narrowing those visible windows to almost
invisible rendering both of them unusable.

In that case I would find it useful if the bottom window is
temporarily replaced with the completion, without opening the new
window for completion. If that would be the case then restoring
previous buffer that was there before replacement of window would be
necessary and useful.

My complain came from those buffers changed by me, user, to something
else, that completion never even tackled. I have not even use
completion, just minibuffer, and above 2 horizontal windows get
restored even though I have not wanted it. By switching to other
buffer in those windows user said "I need that other buffer".

But if the window is replaced with completion, I do not have any
window where I would switch the buffer. Or maybe it also works that
completion window is switched to something else. Labyrinth.

Do you know how to make such setting to open up completion list in
such way to replace the bottom window instead of poping up with new
window?

I cannot find any variable completion*wind

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 >> All these scenarios are with customizations.  I'm not experienced enough
 >> to tell whether they (can) happen in practice.
 >
 > Do you refer to standard completion in minibuffer that it may be
 > customized to replace a present window with the completion instead of
 > opening new windows?
 >
 > That would be nice as I would like to avoid those jerks when there are
 > 2 horizontal windows and then third one appears for completion jerking
 > both of them up and narrowing those visible windows to almost
 > invisible rendering both of them unusable.

Doesn't it do that already?  Note that here and elsewhere I'm purely
speculating how application writers and users might tweak things.

 > In that case I would find it useful if the bottom window is
 > temporarily replaced with the completion, without opening the new
 > window for completion. If that would be the case then restoring
 > previous buffer that was there before replacement of window would be
 > necessary and useful.
 >
 > My complain came from those buffers changed by me, user, to something
 > else, that completion never even tackled. I have not even use
 > completion, just minibuffer, and above 2 horizontal windows get
 > restored even though I have not wanted it. By switching to other
 > buffer in those windows user said "I need that other buffer".

These should be already addressed by my earlier patch.  But Juri meant
that we have to handle completions windows separately since otherwise
they may persist.

 > But if the window is replaced with completion, I do not have any
 > window where I would switch the buffer. Or maybe it also works that
 > completion window is switched to something else. Labyrinth.
 >
 > Do you know how to make such setting to open up completion list in
 > such way to replace the bottom window instead of poping up with new
 > window?
 >
 > I cannot find any variable completion*wind

I hope Juri can.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-10 14:52]:
> >> All these scenarios are with customizations.  I'm not experienced enough
> >> to tell whether they (can) happen in practice.
> >
> > Do you refer to standard completion in minibuffer that it may be
> > customized to replace a present window with the completion instead of
> > opening new windows?
> >
> > That would be nice as I would like to avoid those jerks when there are
> > 2 horizontal windows and then third one appears for completion jerking
> > both of them up and narrowing those visible windows to almost
> > invisible rendering both of them unusable.
>
> Doesn't it do that already?  Note that here and elsewhere I'm purely
> speculating how application writers and users might tweak things.

That is what I am pointing to, it does not do that what you described,
so descriptions misses the point. They don't apply.

 When I have this window:

  +---------------------+
  |                     |
  |                     |
  |                     |
  |                     |
  +---------------------+
  |                     |
  |                     |
  |                     |
  |                     |
  |---------------------|
   +--------------------+

Then upon completion it becomes this:

  +---------------------+
  |                     |
  +---------------------+
  |                     |
  +---------------------+
  |                     |
  | completion here     |
  |                     |
  |                     |
  |                     |
  |                     |
  |---------------------|
  +---------------------+

So the third window appears there. It is not replacement. I would
rather prefer replacement than third window jerking other two up and
rendering them not usable. But that is not subject of this bug report.

> These should be already addressed by my earlier patch.  But Juri meant
> that we have to handle completions windows separately since otherwise
> they may persist.

Thank you, I will try but not ready. My version is days old, need to
upgrade to new version to test the patch.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

> I would rather prefer replacement than third window jerking other two
> up and rendering them not usable. But that is not subject of this bug report.

Currently *Completions* are displayed by 'display-buffer-at-bottom'.
You can customize this with:

(push `("\\`\\*Completions\\*\\'" display-buffer-use-some-window)
      display-buffer-alist)

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* Juri Linkov <juri@linkov.net> [2020-12-11 13:00]:
> > I would rather prefer replacement than third window jerking other two
> > up and rendering them not usable. But that is not subject of this bug report.
> 
> Currently *Completions* are displayed by 'display-buffer-at-bottom'.
> You can customize this with:
> 
> (push `("\\`\\*Completions\\*\\'" display-buffer-use-some-window)
>       display-buffer-alist)

Thank you, I know you already said it before and I kept email until I
try it out. Now I finally tried it. This will become part of my
init.el

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

> We'd have to augment the 'quit-restore' mechanism somehow and run it on
> all windows instead of restoring the configuration.
>
> But I still don't understand the logic of the following:
>
> (1) Start minibuffer interaction, type a-
>
> (2) Pop up a completion window for a- and accept suggestion a-b

What do you type to accept a suggestion?  I can't find a key
to accept a suggestion without exiting the minibuffer.

> (3) Type another - so you now get a-b-
>
> (4) Pop up a completion window for a-b- and accept a-b-c
>
> In this scenario I'd want, after accepting a-b, the completion window to
> disappear (or show its old buffer again) without the minibuffer action
> having terminated.  So I'm still convinced that restoring a previous
> state should be triggered by the completion mechanism and not by the
> read from minibuffer mechanism.

Then maybe the commands that pop up the completions window
should clean up their windows after use.  What would be the
right place to remove used windows?  Maybe in exit-minibuffer?
Or in some unwind-protect in case the user types C-g?

> One thing that has to be considered too is user interaction during
> completion: Suppose I have one window, the completion mechanism pops up
> a new one and I delete the old one.  Terminating completion now cannot
> delete the new window (especially if it's on the only frame in use) but
> has to show another buffer in the new window.  It maybe should try to
> show the one previously shown in the old window.

This means that quit-window should be used on the completions window.
It should do the right thing: either restore a previous buffer in that window,
or close the window if no more buffers were displayed in it.

> And let's not forget that the completion mechanism might pop up a new
> frame or a window on any other frame.  In such case, restoring window
> configurations won't help at all.

That's fine, I create a new tab when the minibuffer is active,
to preserve new windows created during the active minibuffer.
For more convenience, now I installed a patch that allows creating
a new tab even from the minibuffer.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > What do you type to accept a suggestion?  I can't find a key
 > to accept a suggestion without exiting the minibuffer.

When I type here

C-h f set- RET

I get a completions window with the "set-" prefixed completions.  When I
now type

auto RET

the completions window pops down and the minibuffer window shows

set-auto-

When I now type another RET, the completions window pops up again and
shows the "set-auto-" prefixed completions with the minibuffer showing

set-auto-

When I now type an "m" I get a help window showing me help for
'set-auto-mode'.

So here the pop down works already and I have no idea why it cannot be
extended to the entire completion mechanism.

 > Then maybe the commands that pop up the completions window
 > should clean up their windows after use.  What would be the
 > right place to remove used windows?  Maybe in exit-minibuffer?
 > Or in some unwind-protect in case the user types C-g?

The completion mechanism should clean up its traces as soon as it is
finished - either a choice has been made or it has been aborted: This
can mean to clean up windows or frames, size back a minibuffer window or
remove a pop up menu or a dialogue box.  But I hardly ever use that
mechanism so I cannot tell how it works (or should work) in practice.

In either case 'exit-minibuffer' is too late.  It must be either the
caller of completions - just in case it wants to, for example, reuse the
present window for refining the list of completions - or the called
which might be more noisy with windows popping up and down.  And I
suppose that completions are not invoked from minibuffer interactions
alone ...

 > This means that quit-window should be used on the completions window.
 > It should do the right thing: either restore a previous buffer in that window,
 > or close the window if no more buffers were displayed in it.

Yes.  But IMO that should be done _before_ reading from the minibuffer
interaction finished.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-10 12:47]:
> > What do you type to accept a suggestion?  I can't find a key
> > to accept a suggestion without exiting the minibuffer.
> 
> When I type here
> 
> C-h f set- RET

I just notice I have never in my life used RET there. I always used
TAB and recently C-j

My habit is that RET I consider dangerous or "final choice" so I never
used it to complete. Other completing packages would mess with my data
if I do.

> set-auto-
> 
> When I now type an "m" I get a help window showing me help for
> 'set-auto-mode'.

When I hear the beep or see that I am on the end of line, that is where I press RET. Never before.

It is interesting and suprising to see how people use Emacs in different way.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > It is interesting and suprising to see how people use Emacs in different way.

I don't use Emacs that way.  But I incidentally noticed that when using
Emacs that way I can pop down the completions window without terminating
the minibuffer interaction.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Jean Louis]

* martin rudalics <rudalics@gmx.at> [2020-12-10 14:53]:
> > It is interesting and suprising to see how people use Emacs in different way.
> 
> I don't use Emacs that way.  But I incidentally noticed that when using
> Emacs that way I can pop down the completions window without terminating
> the minibuffer interaction.

Probably majority of users do not use minibuffer much. I am using it
frequently for database queries and repetitive editing of database
values. Often I have tabulated list mode showing database entries,
with one click I edit such lines in the minibuffer.

Many times I move from minibuffer to other windows, switch buffer, get
references, come back.

That means I am reusing Emacs interface features. Other programmers
would program their GUIs in Gtk or other GUI frameworks. To spare
efforts and times I find Emacs useful for reuse of code. Not because
it is best, because it has useful features for quick reuse. And it
works on console as well.

Thinking on what you said, I could maybe replace minibuffer input for
some functions. I could use forms.el for example. Or similar like
defcustom for variables.

Definitely I would not like having interface that does not work on
console alone.

Minibuffer is handy for single lines. One could accept with C-q C-j a
new line in the minibuffer, but is unlikely to happen. This makes it
handy for various database entries such as names, email addresses and
similar. I am using full buffer when entry should span few lines. So I
am using Emacs interface to help with database entry validation. But I
should rather use program and the database to make sure of entry validation.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>> Then maybe the commands that pop up the completions window
>> should clean up their windows after use.  What would be the
>> right place to remove used windows?  Maybe in exit-minibuffer?
>> Or in some unwind-protect in case the user types C-g?
>
> The completion mechanism should clean up its traces as soon as it is
> finished - either a choice has been made or it has been aborted: This
> can mean to clean up windows or frames, size back a minibuffer window or
> remove a pop up menu or a dialogue box.  But I hardly ever use that
> mechanism so I cannot tell how it works (or should work) in practice.
>
> In either case 'exit-minibuffer' is too late.  It must be either the
> caller of completions - just in case it wants to, for example, reuse the
> present window for refining the list of completions - or the called
> which might be more noisy with windows popping up and down.  And I
> suppose that completions are not invoked from minibuffer interactions
> alone ...
>
>> This means that quit-window should be used on the completions window.
>> It should do the right thing: either restore a previous buffer in that window,
>> or close the window if no more buffers were displayed in it.
>
> Yes.  But IMO that should be done _before_ reading from the minibuffer
> interaction finished.

There is an existing function 'minibuffer-hide-completions'.  For example,
it's used in completion-in-region-mode this way:

        (unless (equal "*Completions*" (buffer-name (window-buffer)))
          (minibuffer-hide-completions))

I tried to add it to 'exit-minibuffer', and it seems working fine
with non-nil read-from-minibuffer-restore-windows, and I know no other
place that could call minibuffer-hide-completions:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 456193d52e..63b9c9996a 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2114,6 +2114,7 @@ minibuffer-hide-completions
 (defun exit-minibuffer ()
   "Terminate this minibuffer argument."
   (interactive)
+  (minibuffer-hide-completions)
   ;; 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.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > I tried to add it to 'exit-minibuffer', and it seems working fine
 > with non-nil read-from-minibuffer-restore-windows, and I know no other
 > place that could call minibuffer-hide-completions:

But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
the completions window unconditionally even when it was only reused for
showing completions.  IMO 'bury-buffer' is practically always the wrong
choice for Lisp functions to call.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>> I tried to add it to 'exit-minibuffer', and it seems working fine
>> with non-nil read-from-minibuffer-restore-windows, and I know no other
>> place that could call minibuffer-hide-completions:
>
> But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
> the completions window unconditionally even when it was only reused for
> showing completions.  IMO 'bury-buffer' is practically always the wrong
> choice for Lisp functions to call.

Maybe 'quit-window' is better?

I tried your previous patch and it has strange effect:

C-x 2 C-x o - so the bottom window is selected.

C-h f C-g - after canceling the minibuffer, the top window is selected,
not the bottom window as before activating the minibuffer.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 > I tried your previous patch and it has strange effect:
 >
 > C-x 2 C-x o - so the bottom window is selected.
 >
 > C-h f C-g - after canceling the minibuffer, the top window is selected,
 > not the bottom window as before activating the minibuffer.

Should be part of the recent "Stop frames stealing each others'
minibuffers!" rampage.  We can look into it when the dust settles -
there are still bugs to fix and riddles to solve in that area.  Till
then it would be good to try the patch on Emacs 27 to catch any
anomalies ...

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

> I tried your previous patch and it has strange effect:
>
> C-x 2 C-x o - so the bottom window is selected.
>
> C-h f C-g - after canceling the minibuffer, the top window is selected,
> not the bottom window as before activating the minibuffer.

It seems that problem is that read_minibuf messes up the windows so much,
that at the end currently the only way to fix this mess is by restoring
the previous window configuration.  This means that there is a need
to fix read_minibuf to restore all previous window states without using
restore_window_configuration.  Only then it will be possible to add
a user option to disable using restore_window_configuration.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Stefan Monnier]

> It seems that problem is that read_minibuf messes up the windows so much,
> that at the end currently the only way to fix this mess is by restoring
> the previous window configuration.  This means that there is a need
> to fix read_minibuf to restore all previous window states without using
> restore_window_configuration.  Only then it will be possible to add
> a user option to disable using restore_window_configuration.

But without such an option, it's hard to find and fix the problems,
because they're hidden by the `restore_window_configuration`.
So maybe we should introduce such an option, and then force ourselves to
live with it and then fix the problems we encounter.


        Stefan

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 >> It seems that problem is that read_minibuf messes up the windows so much,
 >> that at the end currently the only way to fix this mess is by restoring
 >> the previous window configuration.  This means that there is a need
 >> to fix read_minibuf to restore all previous window states without using
 >> restore_window_configuration.  Only then it will be possible to add
 >> a user option to disable using restore_window_configuration.
 >
 > But without such an option, it's hard to find and fix the problems,
 > because they're hidden by the `restore_window_configuration`.
 > So maybe we should introduce such an option, and then force ourselves to
 > live with it and then fix the problems we encounter.

Exiting from and quitting `read-minibuffer' is hairy, in particular with
multiple frames.  IIRC it's hard to tell for an application how to clean
up the state when the user quits and throws it back to the top level.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Juri Linkov]

>>> It seems that problem is that read_minibuf messes up the windows so much,
>>> that at the end currently the only way to fix this mess is by restoring
>>> the previous window configuration.  This means that there is a need
>>> to fix read_minibuf to restore all previous window states without using
>>> restore_window_configuration.  Only then it will be possible to add
>>> a user option to disable using restore_window_configuration.
>>
>> But without such an option, it's hard to find and fix the problems,
>> because they're hidden by the `restore_window_configuration`.
>> So maybe we should introduce such an option, and then force ourselves to
>> live with it and then fix the problems we encounter.
>
> Exiting from and quitting `read-minibuffer' is hairy, in particular with
> multiple frames.  IIRC it's hard to tell for an application how to clean
> up the state when the user quits and throws it back to the top level.

Since restore_window_configuration doesn't restore multiple frames,
we already don't clean up the previous state completely.  So maybe
really it should be sufficient for a new option just to select
the original window if it still exists.

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Stefan Monnier]

>> But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
>> the completions window unconditionally even when it was only reused for
>> showing completions.  IMO 'bury-buffer' is practically always the wrong
>> choice for Lisp functions to call.
>
> Maybe 'quit-window' is better?

Part of the problem is one of documentation: it's hard to know which one
to call just by reading the docstrings.

Also the above quoted text sounds counter intuitive: "bury buffer"
sounds like it's mostly focused on hiding the *buffer*, potentially
hiding the window along the way if necessary, whereas "quit window"
sounds like it's mostly going to eliminate the *window*.

Of course, there's also the fact that `quit-window` is fairly new
(introduced in Emacs-24), whereas `bury-buffer` has been with us forever.


        Stefan

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 >>> But 'minibuffer-hide-completions' uses 'bury-buffer' which would delete
 >>> the completions window unconditionally even when it was only reused for
 >>> showing completions.  IMO 'bury-buffer' is practically always the wrong
 >>> choice for Lisp functions to call.
 >>
 >> Maybe 'quit-window' is better?
 >
 > Part of the problem is one of documentation: it's hard to know which one
 > to call just by reading the docstrings.
 >
 > Also the above quoted text sounds counter intuitive: "bury buffer"
 > sounds like it's mostly focused on hiding the *buffer*, potentially
 > hiding the window along the way if necessary, whereas "quit window"
 > sounds like it's mostly going to eliminate the *window*.

That's why Lisp code should call `quit-restore-window' instead of
`quit-window'.

 > Of course, there's also the fact that `quit-window` is fairly new
 > (introduced in Emacs-24), whereas `bury-buffer` has been with us forever.

Both, `bury-buffer' and `quit-window' should be used interactively only.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Stefan Monnier]

>>> Maybe 'quit-window' is better?
>>
>> Part of the problem is one of documentation: it's hard to know which one
>> to call just by reading the docstrings.
>>
>> Also the above quoted text sounds counter intuitive: "bury buffer"
>> sounds like it's mostly focused on hiding the *buffer*, potentially
>> hiding the window along the way if necessary, whereas "quit window"
>> sounds like it's mostly going to eliminate the *window*.
>
> That's why Lisp code should call `quit-restore-window' instead of
> `quit-window'.

I suspect the docstring of the other functions should point to it if we
want this to have any uptake.

>> Of course, there's also the fact that `quit-window` is fairly new
>> (introduced in Emacs-24), whereas `bury-buffer` has been with us forever.
> Both, `bury-buffer' and `quit-window' should be used interactively only.

Maybe we should begin with adding

    (declare (interactive-only quit-restore-window))

to `quit-window` (adding it to `bury-buffer` risks us drowning under
a deluge of warnings)?


        Stefan

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

 >> That's why Lisp code should call `quit-restore-window' instead of
 >> `quit-window'.
 >
 > I suspect the docstring of the other functions should point to it if we
 > want this to have any uptake.

I would have given up on that idea at the latest when `quit-window-hook'
was added.

 > Maybe we should begin with adding
 >
 >      (declare (interactive-only quit-restore-window))
 >
 > to `quit-window` (adding it to `bury-buffer` risks us drowning under
 > a deluge of warnings)?

At the time people call `quit-window' and/or `bury-buffer' they are only
occupied with how to get rid of one of these ASAP.  When they find out
that they overdid things, they usually try to restore some older window
configuration.  These habits will never die.

martin

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[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. ]]]

  > My recommendation is not to "abuse" the recursive editing; the ELisp
  > manual rightfully warns against that, albeit indirectly.

Should we make this warning more direct
so that people notice it more?

-- 
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)

bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bugs@gnu.support, larsi@gnus.org, 45072@debbugs.gnu.org
> Date: Tue, 08 Dec 2020 00:33:05 -0500
> 
>   > My recommendation is not to "abuse" the recursive editing; the ELisp
>   > manual rightfully warns against that, albeit indirectly.
> 
> Should we make this warning more direct
> so that people notice it more?

The user manual has this in the section about recursive editing:

     In general, we try to minimize the use of recursive editing levels in
  GNU Emacs.  This is because they constrain you to go back in a
  particular order—from the innermost level toward the top level.  When
  possible, we present different activities in separate buffers so that
  you can switch between them as you please.  Some commands switch to a
  new major mode which provides a command to switch back.  These
  approaches give you more flexibility to go back to unfinished tasks in
  the order you choose.

Suggestions to add to this text something more direct are welcome.