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

[Daniel Brockman]

Stefan Monnier <address@hidden> 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 <address@hidden>