GNU bug report logs - #4914
completions - remove window after use?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4914 in the body.
You can then email your comments to 4914 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Re: completions - remove window after use?
Date: Thu, 12 Nov 2009 08:31:52 -0500

> 
> > When showing a *completions* buffer in a new window opened for
> > it (TAB in find-file minibuffer for instance), I wonder why the
> > window doesn't get deleted when completion has finished.  For
> > instance, when an existing file is found, the *Completions*
> > buffer is buried, but I see a split frame with the original
> > buffer in the top window and _some other_ buffer in the lower
> > window.  Shouldn't the window for the completions buffer be
> > removed whenever it has been popped up just for the buffer?
> 


On Nov 12, 2009, at 3:19 AM, martin rudalics wrote:

> This should not happen and doesn't happen with my older builds.  Could
> you please (1) make sure that the behavior also happens with Emacs -Q,
> (2) try to find out when it appeared for the first time, and (3) make a
> corresponding bug report.


I reproduce this with a current build, with emacs -nw -Q.

When reverting to revision e78283bb (Tue Aug 18, just before minibuffer-hide-completions was introduced), the problem goes away and the *Completions* buffer continuous to be shown in the extra window.
I think it's now burying the buffer, but doesn't delete the window.

Again, the desired behavior would be to remove windows (or frames) that were created to display the *Completions* buffer rather than to leave them visible.

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: David Reitter <david.reitter <at> gmail.com>, 4914 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Thu, 12 Nov 2009 18:40:25 +0100

> When reverting to revision e78283bb (Tue Aug 18, just before
> minibuffer-hide-completions was introduced), the problem goes away and
> the *Completions* buffer continuous to be shown in the extra window.
> I think it's now burying the buffer, but doesn't delete the window.

I wasn't aware of that.  Is the new behavior anywhere documented?

> Again, the desired behavior would be to remove windows (or frames)
> that were created to display the *Completions* buffer rather than to
> leave them visible.

Deleting the window isn't necessarily the right thing either - think of
the case where displaying the *completions* buffer reuses an existing
window instead of popping up a new one.  I'm currently experimenting
with a generic solution for this problem.

martin

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4914 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Thu, 12 Nov 2009 12:56:47 -0500

On Nov 12, 2009, at 12:40 PM, martin rudalics wrote:
> > Again, the desired behavior would be to remove windows (or frames)
> > that were created to display the *Completions* buffer rather than to
> > leave them visible.
> 
> Deleting the window isn't necessarily the right thing either - think of
> the case where displaying the *completions* buffer reuses an existing
> window instead of popping up a new one.  I'm currently experimenting
> with a generic solution for this problem.

That would be good.  Quite generally, those windows/frames that are created (e.g. via pop-to-buffer) for a specific window should be removed after we're done with the interaction (see also quit-window).   I've had a kludge for this in Aquamacs for a long time (via an advice to bury-buffer), but it's quite difficult to do consistently when Emacs and 3rd-part packages aren't aware that this is happening.

Are dedicated windows the way to go?

Message #30 received at 4914 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 4914 <at> debbugs.gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Thu, 12 Nov 2009 20:26:46 +0100

> That would be good.  Quite generally, those windows/frames that are
> created (e.g. via pop-to-buffer) for a specific window should be
> removed after we're done with the interaction (see also quit-window).
> I've had a kludge for this in Aquamacs for a long time (via an advice
> to bury-buffer), but it's quite difficult to do consistently when
> Emacs and 3rd-part packages aren't aware that this is happening.

It's practically impossible to find a solution that satisfies all needs
in this area.  Basically, `display-buffer' would set a special slot for
any window it pops up and `quit-window' would try to delete a window if
it has that slot set and still shows the argument of `display-buffer'.

The more difficult part is what to do when `display-buffer' has reused
an existing window.  In that case quitting that window should display
the previous buffer with the old start position and the old point.  All
these values would have to be recorded in the window structure and in
saved window configurations.  Now once we have all these values we could
have `bury-buffer' use them instead of doing a `switch-to-buffer' but
that's too tricky for the moment.

> Are dedicated windows the way to go?

The completions window could be dedicated so `quit-window' would
automatically delete it.  Windows that may live longer should generally
not be dedicated.

martin

Message #35 received at 4914 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 4914 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#4914: completions - remove window after use?
Date: Thu, 12 Nov 2009 15:22:18 -0500

> Are dedicated windows the way to go?

Yes, soft-dedicated windows might be the way to go.
But the change you refer to (in revision e78283bb, whatever that is) was
not intentional, so we could/should start by fixing that change.


        Stefan

Message #40 received at 4914 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: David Reitter <david.reitter <at> gmail.com>, 4914 <at> debbugs.gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Tue, 17 Nov 2009 18:00:31 -0500

>> That would be good.  Quite generally, those windows/frames that are
>> created (e.g. via pop-to-buffer) for a specific window should be
>> removed after we're done with the interaction (see also quit-window).
>> I've had a kludge for this in Aquamacs for a long time (via an advice
>> to bury-buffer), but it's quite difficult to do consistently when
>> Emacs and 3rd-part packages aren't aware that this is happening.

> It's practically impossible to find a solution that satisfies all needs
> in this area.  Basically, `display-buffer' would set a special slot for
> any window it pops up and `quit-window' would try to delete a window if
> it has that slot set and still shows the argument of `display-buffer'.

How 'bout the patch below?


        Stefan "whose .emacs would have
                (setq display-buffer-mark-dedicated 'soft)"


Index: lisp/minibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v
retrieving revision 1.96
diff -u -r1.96 minibuffer.el
--- lisp/minibuffer.el	12 Nov 2009 23:10:06 -0000	1.96
+++ lisp/minibuffer.el	17 Nov 2009 22:56:12 -0000
@@ -965,9 +965,14 @@
     (if (and completions
              (or (consp (cdr completions))
                  (not (equal (car completions) string))))
-        (with-output-to-temp-buffer "*Completions*"
           (let* ((last (last completions))
-                 (base-size (cdr last)))
+               (base-size (cdr last))
+               ;; If the *Completions* buffer is shown in a new
+               ;; window, mark it as softly-dedicated, so bury-buffer in
+               ;; minibuffer-hide-completions will know whether to
+               ;; delete the window or not.
+               (display-buffer-mark-dedicated 'soft))
+          (with-output-to-temp-buffer "*Completions*"
             ;; Remove the base-size tail because `sort' requires a properly
             ;; nil-terminated list.
             (when last (setcdr last nil))
Index: lisp/window.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/window.el,v
retrieving revision 1.185
diff -u -r1.185 window.el
--- lisp/window.el	13 Nov 2009 22:19:56 -0000	1.185
+++ lisp/window.el	17 Nov 2009 22:56:12 -0000
@@ -1042,6 +1042,11 @@
     (set-window-buffer window buffer)
     (window--display-buffer-1 window)))
 
+(defvar display-buffer-mark-dedicated nil
+  "If non-nil, `display-buffer' marks the windows it creates as dedicated.
+The actual non-nil value of this variable will be copied to the
+`window-dedicated-p' flag.")
+
 (defun display-buffer (buffer-or-name &optional not-this-window frame)
   "Make buffer BUFFER-OR-NAME appear in some window but don't select it.
 BUFFER-OR-NAME must be a buffer or the name of an existing
@@ -1133,8 +1133,10 @@
 			buffer (if (listp pars) pars))))))
      ((or use-pop-up-frames (not frame-to-use))
       ;; We want or need a new frame.
-      (window--display-buffer-2
-       buffer (frame-selected-window (funcall pop-up-frame-function))))
+      (let ((win (frame-selected-window (funcall pop-up-frame-function))))
+        (when display-buffer-mark-dedicated
+          (set-window-dedicated-p win display-buffer-mark-dedicated))
+        (window--display-buffer-2 buffer win)))
      ((and pop-up-windows
 	   ;; Make a new window.
 	   (or (not (frame-parameter frame-to-use 'unsplittable))
@@ -1149,8 +1149,10 @@
 		 (or (window--try-to-split-window
 		      (get-largest-window frame-to-use t))
 		     (window--try-to-split-window
-		      (get-lru-window frame-to-use t))))
-	   (window--display-buffer-2 buffer window-to-use)))
+		      (get-lru-window frame-to-use t)))))
+      (when display-buffer-mark-dedicated
+        (set-window-dedicated-p window-to-use display-buffer-mark-dedicated))
+      (window--display-buffer-2 buffer window-to-use))
      ((let ((window-to-undedicate
 	     ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate
 	     ;; the selected window to its buffer, to avoid that some of

Message #45 received at 4914 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: David Reitter <david.reitter <at> gmail.com>, 4914 <at> debbugs.gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Wed, 18 Nov 2009 09:11:40 +0100

>> It's practically impossible to find a solution that satisfies all needs
>> in this area.  Basically, `display-buffer' would set a special slot for
>> any window it pops up and `quit-window' would try to delete a window if
>> it has that slot set and still shows the argument of `display-buffer'.
>
> How 'bout the patch below?
>
>
>         Stefan "whose .emacs would have
>                 (setq display-buffer-mark-dedicated 'soft)"

This reveals a general problem with all `display-buffer' related (and
maybe all) options.  We really should settle on a policy that strictly
separates user provided settings from application provided ones.  In
particular

> +               ;; If the *Completions* buffer is shown in a new
> +               ;; window, mark it as softly-dedicated, so bury-buffer in
> +               ;; minibuffer-hide-completions will know whether to
> +               ;; delete the window or not.
> +               (display-buffer-mark-dedicated 'soft))
> +          (with-output-to-temp-buffer "*Completions*"
>              ;; Remove the base-size tail because `sort' requires a properly
>              ;; nil-terminated list.
>              (when last (setcdr last nil))

overrides the intentions of a user who has an explicit

(setq display-buffer-mark-dedicated nil)

in her .emacs.  Also I suppose that with your .emacs `display-buffer'
won't be able to reuse a window it popped up earlier for displaying
another buffer.  In the case at hand this would prevent the Completions
window's contents getting overwritten by those of some other buffer
which is good.  But in general this might be a bad idea leading to "more
important" windows getting reused and/or new windows and frames popped
up all the time.

Also note that the greater problem is still how to "correctly" quit a
window that has been reused (instead of popped up) by `display-buffer'.

martin

Message #50 received at 4914 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 4914 <at> debbugs.gnu.org
Subject: Re: bug#4914: completions - remove window after use?
Date: Mon, 23 Nov 2009 08:58:34 -0500

On Nov 17, 2009, at 6:00 PM, Stefan Monnier wrote:
> How 'bout the patch below?
>                (setq display-buffer-mark-dedicated 'soft)"

Didn't work that well for me - the window doesn't disappear. Perhaps the other bug (switching away from *Completions*) would need to be fixed first.

Message #53 received at 4914 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 4914 <at> debbugs.gnu.org
Subject: Re: completions - remove window after use?
Date: Sun, 17 Jan 2010 18:41:11 -0500

> > When showing a *completions* buffer in a new window opened for
> > it (TAB in find-file minibuffer for instance), I wonder why the
> > window doesn't get deleted when completion has finished.  For
> > instance, when an existing file is found, the *Completions*
> > buffer is buried, but I see a split frame with the original
> > buffer in the top window and _some other_ buffer in the lower
> > window.  Shouldn't the window for the completions buffer be
> > removed whenever it has been popped up just for the buffer?
>
> I reproduce this with a current build, with emacs -nw -Q.

Do you still see this bug?  I think it's been fixed for a while now (at
least I don't experience it).

Message #58 received at 4914-done <at> debbugs.gnu.org (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 4914-done <at> debbugs.gnu.org
Subject: Re: completions - remove window after use?
Date: Mon, 18 Jan 2010 10:07:53 -0500

[Message part 1 (text/plain, inline)]

On Jan 17, 2010, at 6:41 PM, Chong Yidong wrote:
> Do you still see this bug?  I think it's been fixed for a while now (at
> least I don't experience it).

Yes, this particular case has been fixed, thank you. 

I recall the general case being discussed but not addressed (closing windows which have popped open just for a specific buffer), but I'll file a separate report when I observe a striking example.

[PGP.sig (application/pgp-signature, inline)]

Message #61 received at 4914 <at> debbugs.gnu.org (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 4914 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: completions - remove window after use?
Date: Mon, 18 Jan 2010 12:58:03 -0500

[Message part 1 (text/plain, inline)]

On Jan 18, 2010, at 10:07 AM, David Reitter wrote:

> I recall the general case being discussed but not addressed (closing windows which have popped open just for a specific buffer), but I'll file a separate report when I observe a striking example.

Actually, it seems to be working:  C-h f foo RET C-x o C-x k RET pops up and removes the window,  iff (eq display-buffer-mark-dedicated 'soft).  I guess that was Stefan's patch.  Very nice.  I can get rid of my kill-buffer kludges now.  Thanks again.

[PGP.sig (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.