bug#4914: completions - remove window after use?

bug#4914: completions - remove window after use?

[David Reitter]

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

bug#4914: completions - remove window after use?

[martin rudalics]

 > 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

bug#4914: completions - remove window after use?

[David Reitter]

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?

bug#4914: completions - remove window after use?

[martin rudalics]

 > 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

bug#4914: completions - remove window after use?

[Stefan Monnier]

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

bug#4914: completions - remove window after use?

[martin rudalics]

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

bug#4914: completions - remove window after use?

[David Reitter]

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.

bug#4914: completions - remove window after use?

[Stefan Monnier]

> 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

bug#4914: completions - remove window after use?

[Chong Yidong]

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

bug#4914: completions - remove window after use?

[David Reitter]

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

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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

bug#4914: marked as done (completions - remove window after use?)

[Emacs bug Tracking System]

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

Your message dated Mon, 18 Jan 2010 10:07:53 -0500
with message-id <5C420BAC-187B-4B19-BF13-CC1A71745D59@gmail.com>
and subject line Re: completions - remove window after use?
has caused the Emacs bug report #4914,
regarding completions - remove window after use?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
4914: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4914
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 4705 bytes --]

From: David Reitter <david.reitter@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: Re: completions - remove window after use?
Date: Thu, 12 Nov 2009 08:31:52 -0500
Message-ID: <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com>

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

[-- Attachment #3: Type: message/rfc822, Size: 4369 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 412 bytes --]

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.

[-- Attachment #3.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]