Should killing a help or compile buffer also delete the window?

Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

I've always found it annoying that Emacs seems to have a habit of
leaving junk windows around whenever you invoke something that needs
to display information in a temporary buffer.  I think it just gives a
really sloppy impression, especially when you aren't used to it.
Two of the most common examples might be `M-x compile' and `C-h f'.
It also happens with things like `M-x grep' and `M-x locate'.

I realize that you can't expect Emacs to know when you are done with a
window unless you actually tell when.  The obvious way to tell when is
to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
lingering, which makes me nervous.

When I was new to Emacs, I would always kill a garbage buffer before
deleting its temporary window.  Eventually, I discovered `C-x 4 0' and
started using that.  As time went by (and I got lazier), I gradually
began to accept the fact that you really can't avoid having a bunch of
old garbage buffers unless you spend a lot of time chasing them down,
so I started just doing `C-x 1', though it always made me feel dirty.

Now to the point of this message.  Some time ago I started using
Dictionary Mode[1], which has caused me to once again pick up the
habit of killing temporary buffers.  As you might know, killing a
dictionary buffer automatically kills the window as well, unless the
window was already there when the dictionary buffer was created.
This makes a lot of sense to me --- so much sense that the normal
Emacs behavior has once again started to annoy me.

I believe the Right Thing to do when the user kills a temporary buffer
whose window was created as a side-effect of displaying the buffer in
question is to restore the old window configuration.  At least when
the automatically created window hasn't been used for anything else,
Emacs should take the hint and get the window out of the user's face.

I'm sorry if this is an old argument, or if this is not the right time
to discuss this matter.

-- 
Daniel Brockman <daniel@brockman.se>

[1] http://www.myrkr.in-berlin.de/dictionary/

Re: Should killing a help or compile buffer also delete the window?

[Robert J. Chassell]

On 24 Apr 2005, Daniel Brockman wrote,

    I've always found it annoying that Emacs seems to have a habit of
    leaving junk windows around whenever you invoke something ...

Most often, I just want to bury the buffer, not delete it.  Your two
examples of buffers you want to delete are buffers I tend to want to
look at again, the ones created by `M-x compile' and `C-h f'
(describe-function).

To me, it looks that you want `C-x 4 0' (kill-buffer-and-window) to be
documented more prominently.  What would you like specifically?

Put another way, how should we change the documentation in
(emacs)Change Window?  Right now `C-x 4 0' is third in the sequence,
after `C-x 0' and `C-x 1'.  That looks right to me.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Should killing a help or compile buffer also delete the window?

[Alan Mackenzie]

On Sun, 24 Apr 2005, Robert J. Chassell wrote:

>On 24 Apr 2005, Daniel Brockman wrote,

>    I've always found it annoying that Emacs seems to have a habit of
>    leaving junk windows around whenever you invoke something ...

>Most often, I just want to bury the buffer, not delete it.  Your two
>examples of buffers you want to delete are buffers I tend to want to
>look at again, the ones created by `M-x compile' and `C-h f'
>(describe-function).

>To me, it looks that you want `C-x 4 0' (kill-buffer-and-window) to be
>documented more prominently.  What would you like specifically?

I'd like C-x 4 0 to just do its job without mithering me with "kill
buffer `foo'? (yes or no)", unless it's an actual changed buffer that's
getting killed.

>Put another way, how should we change the documentation in
>(emacs)Change Window?  Right now `C-x 4 0' is third in the sequence,
>after `C-x 0' and `C-x 1'.  That looks right to me.

>-- 
>    Robert J. Chassell                         

-- 
Alan Mackenzie (Munich, Germany).

Re: Should killing a help or compile buffer also delete the window?

[Robert J. Chassell]

   I'd like C-x 4 0 to just do its job without mithering me with "kill
   buffer `foo'? (yes or no)", unless it's an actual changed buffer
   that's getting killed.

Today's GNU Emacs CVS snapshot, Mon, 2005 Apr 25  09:44 UTC
GNU Emacs 22.0.50.14 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
started with

     /usr/local/src/emacs/src/emacs -Q -D

does not ask me that question in either situation, changed buffer or
not.  It just kills the buffer and the window.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Should killing a help or compile buffer also delete the window?

[Richard Stallman]

    I realize that you can't expect Emacs to know when you are done with a
    window unless you actually tell when.  The obvious way to tell when is
    to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
    lingering, which makes me nervous.

You shouldn't consider these buffers a problem.

    I believe the Right Thing to do when the user kills a temporary buffer
    whose window was created as a side-effect of displaying the buffer in
    question is to restore the old window configuration.

That would definitely be wrong, since you might have changed something
about other windows in the mean time, and those changes should
definitely not be undone.

Finding "the right way" to remove a temporary buffer from the screen
is a very hard problem.  Nobody has ever proposed a solution that
really is right all the time, or even nearly all the time.  View mode
has tried to implement one, but it too has problems.

I don't want to spend time on thinking about it because I think it
is unlikely to get anywhere.

Re: Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

Richard Stallman <rms@gnu.org> writes:

> You shouldn't consider these [temporary] buffers a problem.

You're right, I really shouldn't.  I'm mostly over it these days.
Midnight mode helps, too.

> Finding "the right way" to remove a temporary buffer from the screen
> is a very hard problem.  Nobody has ever proposed a solution that
> really is right all the time, or even nearly all the time.
> View mode has tried to implement one, but it too has problems.

Granted, but I'm not trying to debate "the right way" to remove a
temporary buffer from the screen.  I'm proposing that when a temporary
buffer is killed, TRYING to also remove the associated window might in
itself be the right thing.

The actual algorithm to do this is already in place; it has seen heavy
use by View mode and descendants.  In that case, it's just a matter of
invoking it as a response to `C-x k' as well as to `q' key presses.

(add-hook 'help-mode-hook
          (lambda ()
            (make-local-hook 'kill-buffer-hook)
            (add-hook 'kill-buffer-hook 'View-leave t t)))

> I don't want to spend time on thinking about it because I think it
> is unlikely to get anywhere.

To be honest, I'm growing less and less confident myself that it would
be the best default behavior.  While many people would definitely find
it convenient, I suspect others would just be confused or annoyed.

-- 
Daniel Brockman <daniel@brockman.se>

Re: Should killing a help or compile buffer also delete the window?

[Richard Stallman]

    Granted, but I'm not trying to debate "the right way" to remove a
    temporary buffer from the screen.  I'm proposing that when a temporary
    buffer is killed, TRYING to also remove the associated window might in
    itself be the right thing.

That's a part of the question of "the right way" to remove a temporary
buffer from the screen.  It's a quagmire we should avoid getting into.

RE: Should killing a help or compile buffer also delete the window?

[Drew Adams]

    I've always found it annoying that Emacs seems to have a habit of
    leaving junk windows around whenever you invoke something that needs
    to display information in a temporary buffer....

    I realize that you can't expect Emacs to know when you are done with a
    window unless you actually tell when.  The obvious way to tell when is
    to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
    lingering, which makes me nervous....

    When I was new to Emacs, I would always kill a garbage buffer before
    deleting its temporary window.  Eventually, I discovered `C-x 4 0' and
    started using that....

    I believe the Right Thing to do when the user kills a temporary buffer
    whose window was created as a side-effect of displaying the buffer in
    question is to restore the old window configuration.  At least when
    the automatically created window hasn't been used for anything else,
    Emacs should take the hint and get the window out of the user's face.

The annoyance you describe is, I think, exacerbated (or perhaps is only
manifest?) when one uses one window per frame by default, as I do. And
commands like `delete-window' and `kill-buffer-and-window' don't help in
this regard, with one-window frames.

FWIW, I customized a few things in my Emacs to deal with this. I mention it
for those who might be interested, not as a proposal to change Emacs itself.
If interested, see the short description at
http://www.emacswiki.org/cgi-bin/wiki/Delete_Frames_Easily_-_But_Not_Too_Eas
ily.

Wrt various efforts to deal with this and your comments on deleting windows
and killing buffers: Deleting a window should not, in general, delete (kill)
its buffer, but killing a buffer _interactively_ can often reasonably delete
its window too (and frame, if `one-window-p').

 - Drew

Re: Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

"Drew Adams" <drew.adams@oracle.com> writes:

> Wrt various efforts to deal with this and your comments on deleting
> windows and killing buffers: Deleting a window should not, in
> general, delete (kill) its buffer, but killing a buffer
> _interactively_ can often reasonably delete its window too (and
> frame, if `one-window-p').

Yes, I completely agree.  Thanks for clarifying.

-- 
Daniel Brockman <daniel@brockman.se>

Re: Should killing a help or compile buffer also delete the window?

[Kevin Rodgers]

Daniel Brockman wrote:
 > I've always found it annoying that Emacs seems to have a habit of
 > leaving junk windows around whenever you invoke something that needs
 > to display information in a temporary buffer.  I think it just gives a
 > really sloppy impression, especially when you aren't used to it.
 > Two of the most common examples might be `M-x compile' and `C-h f'.
 > It also happens with things like `M-x grep' and `M-x locate'.
 >
 > I realize that you can't expect Emacs to know when you are done with a
 > window unless you actually tell when.  The obvious way to tell when is
 > to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
 > lingering, which makes me nervous.
 >
 > When I was new to Emacs, I would always kill a garbage buffer before
 > deleting its temporary window.  Eventually, I discovered `C-x 4 0' and
 > started using that.  As time went by (and I got lazier), I gradually
 > began to accept the fact that you really can't avoid having a bunch of
 > old garbage buffers unless you spend a lot of time chasing them down,
 > so I started just doing `C-x 1', though it always made me feel dirty.
 >
 > Now to the point of this message.  Some time ago I started using
 > Dictionary Mode[1], which has caused me to once again pick up the
 > habit of killing temporary buffers.  As you might know, killing a
 > dictionary buffer automatically kills the window as well, unless the
 > window was already there when the dictionary buffer was created.
 > This makes a lot of sense to me --- so much sense that the normal
 > Emacs behavior has once again started to annoy me.
 >
 > I believe the Right Thing to do when the user kills a temporary buffer
 > whose window was created as a side-effect of displaying the buffer in
 > question is to restore the old window configuration.  At least when
 > the automatically created window hasn't been used for anything else,
 > Emacs should take the hint and get the window out of the user's face.

Have you tried displaying those temporary buffers each in its own frame,
via special-display-buffer-names (or special-display-regexps)?  That
frame's sole window is dedicated to the buffer, and so killing the
buffer deletes the frame.

-- 
Kevin Rodgers

Re: Should killing a help or compile buffer also delete the window?

[Stefan Monnier]

> I realize that you can't expect Emacs to know when you are done with a
> window unless you actually tell when.  The obvious way to tell when is
> to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
> lingering, which makes me nervous.

The way Emacs is expected to deal with it, is via the notion of dedicated
windows.  When a window is created by display-buffer, it is sometimes marked
as dedicated, so that if the buffer it displays is killed the window is
deleted (and if it's the only window in the frame, the frame is also
deleted).

I think Emacs should be a bit more aggressive about marking windows dedicated.

My locally hacked Emacs has changed it to *always* mark the window
as dedicated.  The problem with that is that you can't switch-to-buffer in
a dedicated window, so I introduced the notion of "softly-dedicated" which
basically says "this window was created to display buffer FOO and has never
displayed anything else".  I.e. it's a form of the `dedicated' flag which
does not prevent switch-to-buffer: instead when doing switch-to-buffer the
flag gets set back to nil to indicate that the wnidow is not dedicated
any more.

It works great in my environment, don't know about others's.


        Stefan

Re: Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

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

>> I realize that you can't expect Emacs to know when you are done with a
>> window unless you actually tell when.  The obvious way to tell when is
>> to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
>> lingering, which makes me nervous.
>
> The way Emacs is expected to deal with it, is via the notion of
> dedicated windows.  When a window is created by display-buffer, it
> is sometimes marked as dedicated, so that if the buffer it displays
> is killed the window is deleted (and if it's the only window in the
> frame, the frame is also deleted).

Interesting... I didn't know that.

> I think Emacs should be a bit more aggressive about marking
> windows dedicated.

I see.  What are some examples of windows currently marked dedicated?

> My locally hacked Emacs has changed it to *always* mark the window
> as dedicated.

Does this mean that if you type C-h f cd RET C-x man RET chdir RET,
you end up with three windows (assuming you started with just one)?
I'm not sure whether that would be good or bad; it might just be less
annoying, since in a way you would be more in control of your windows.
I guess I'd really have to try it for a while.

> The problem with that is that you can't switch-to-buffer in a
> dedicated window, so I introduced the notion of "softly-dedicated"
> which basically says "this window was created to display buffer FOO
> and has never displayed anything else".  I.e. it's a form of the
> `dedicated' flag which does not prevent switch-to-buffer:
> instead when doing switch-to-buffer the flag gets set back to nil to
> indicate that the wnidow is not dedicated any more.

That's exactly the semantics I had in mind!

> It works great in my environment, don't know about others's.

It sounds just about perfect.  Where can I get the patch? :-)

-- 
Daniel Brockman <daniel@brockman.se>

Re: Should killing a help or compile buffer also delete the window?

[Stefan Monnier]

>> My locally hacked Emacs has changed it to *always* mark the window
>> as dedicated.

> Does this mean that if you type C-h f cd RET M-x man RET chdir RET,
> you end up with three windows (assuming you started with just one)?

Can't remember what behavior I implemented (I use
special-display-buffer-names for those buffers anyway, so I get 3 frames
even with a vanilla Emacs), but the intention is for this not to be the case
in order to preserve the current behavior (i.e. the M-x man simply uses one
of the two existing windows, setting its dedicated flag to nil as
a side-effect).

>> It works great in my environment, don't know about others's.
> It sounds just about perfect.  Where can I get the patch? :-)

It's lost in the middle of many other changes.
See my monnier@iro.umontreal.ca--first/emacs--monnier--0 branch
in my Arch archive at http://www.iro.umontreal.ca/~monnier/archives/first.
Note that it's a branch I use only to sync my local version between
diferent machines.  It's not signed and can be broken and include temporary
hacks/debugging things, some of them left around way past their due date.

Probably a `tla changes --diffs miles@gnu.org--gnu-2005/emacs--trunk--0'
followed by a good grep for `dedicated' will give you a good idea of what's
been changed for this specific "feature".


        Stefan

Re: Should killing a help or compile buffer also delete the window?

[Richard Stallman]

    I think Emacs should be a bit more aggressive about marking windows dedicated.

I'd be glad to consider specific suggestions.  People could try
implementing changes in this, and try using them; if such a change is
generally liked, we can install it.

Re: Should killing a help or compile buffer also delete the window?

[David Reitter]

Daniel Brockman <daniel <at> brockman.se> writes:

 > > I don't want to spend time on thinking about it because I think it
 > > is unlikely to get anywhere.
 >
 > To be honest, I'm growing less and less confident myself that it would
 > be the best default behavior.  While many people would definitely find
 > it convenient, I suspect others would just be confused or annoyed.

I have the same problem, yet I want the behavior that you suggested in 
most cases.

Here's what we do in AquaMacs (an Emacs distro with UI customizations 
for the Mac).
It's quite a hack considered that the solution is not generic, but 
lists specific buffer names that have
their own behavior.

However, we don't only close windows for killed buffers, but we also 
create new frames (and thus a new
window) for many types of newly buffers. But we can only do so 
selectively, because a lot of modes
open new windows with new buffers that are not supposed to go into a 
new frame (consider ispell).

So this is the solution that I've arrived at after playing around a 
bit; but I don't consider it very universal.
It's a difficult problem as it has been said before.

===

(setq one-buffer-one-frame t)

(defun open-in-other-frame-p (buf default)

(set 'bufname (if (eq (type-of buf) 'string)
							 buf
							 (buffer-name buf)))
  ;; i guess we should use ;; with special-display-regexps instead
(if one-buffer-one-frame
(if   (string-match "[ ]*\\*.*\\*[ ]*" bufname)
     (if (or (equal "\*Messages\*" bufname)
	        (equal "\*info\*" bufname)
		(equal  "\*scratch\*" bufname)
		(equal  "\*Help\*" bufname)
		(equal "\*Backtrace\*" bufname)
		 (string-match "[ ]*\*Customize*" bufname)
		)
	t
       nil)
     default)
nil
))

;; only for certain special buffers
(defadvice switch-to-buffer (around sw-force-other-frame (&rest args) 
activate)
       (if (open-in-other-frame-p (car args) nil)
        (apply #'switch-to-buffer-other-frame args)
        ad-do-it)
        )

;; we'd like to open new frames for some stuff
  (defadvice find-file (around force-other-frame (&rest args) activate)

      (if one-buffer-one-frame
       (apply #'find-file-other-frame args)
       ad-do-it)
       )

;; buffer selected from menu bar (but not from popup menu when doing 
C-mouse-1)
(defadvice menu-bar-select-buffer (around 
select-buffer-force-other-frame (&rest args) activate)
(interactive)
      (if one-buffer-one-frame
       (switch-to-buffer-other-frame last-command-event)
       ad-do-it)
       )

;; delete window when buffer is killed
(defadvice kill-buffer (around force-delete-frame (&rest args) activate)
(setq last-sel-window (selected-window))
(if
     (and (open-in-other-frame-p (car args) t)
	 (not (special-display-p (buffer-name)))
	 (eq (window-buffer) (car args)))
     (list
      (condition-case nil
	 (
	  list
	  ad-do-it

	  (delete-window last-sel-window)
	  )
        (error  ;; if this is the last open frame, just make it invisible

	(make-frame-invisible (selected-frame) t)
	)
        ))
   ;; else  ; don't delete
   ad-do-it
   )
)

Re: Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

David Reitter <david.reitter@gmail.com> writes:

> Daniel Brockman <daniel <at> brockman.se> writes:

I just thought I'd point out that substituting `<at>' for `@' in the
body of a message is counter-effective against harvesting, since this
makes the address slip through [1,2] the filter for the archive web
interface which ordinarily removes all addresses completely (replacing
them with `<address@hidden>' or somesuch).  Of course, if someone has
a copy of the actual message, they can just look in the CC header to
find the address in plaintext.

-- 
Daniel Brockman <daniel@brockman.se>

[1] http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00893.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00476.html