emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quit-window


From: Christoph Scholtes
Subject: Re: quit-window
Date: Sun, 23 Oct 2011 10:01:28 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (windows-nt)

martin rudalics <address@hidden> writes:

>> quit-window bound to `q' in a keymap provides a nice, consistent UI for
>> getting rid of the window and killing/burying its buffer.
>
> But only when you are viewing a buffer.

Yes. I was referring to viewing buffers in `special-mode'.

> I think this could be fixed by changing `Info-exit' appropriately.  The
> prefix argument should be passed on to `quit-window'.  (We can't run
> `quit-window' directly in Info-mode since we have to deal with the
> Info-standalone case.)

Yes. You could do that as a short-term solution, but long term that a
kludge. There are so many of these `exit-wrappers' that could be
eliminated with a more consistent interface.

>> I have identified at least 18 modes that do something similar. Maybe
>> some special case even needs to, but most of the time it could be
>> cleaned up, IMO.
>
> These were written before I rewrote `quit-window'.  Indeed I shall have
> to look into these.

I will provide a list of the ones I have found.

>> Also, some of these exit wrappers explicitely restore a previous
>> window configuration. Doesn't quit-window handle that already?
>
> It should do better, because `quit-window' is able to quit a window
> shown on another frame too.  So all this configuration stuff should be
> eliminated eventually.

Excellent, that's what I thought. 

> You mean that `kill-buffer-hook' is not sufficient for you?  One problem
> with a simple quit-window-hook is that it could falsely create the
> impression that after `quit-window' the associated buffer is no more
> displayed at all.  This might be wrong.  Basically, what you need is
> provided by `window-configuration-change-hook'.  The problem with the
> latter is that application programmers don't know how to use it because
> they can't know _what_ precisely has changed.  That information would
> have to be provided somewhere, somehow.  Suggestions welcome.

No, `kill-buffer-hook' is too general, IMO. What if the buffer is buried
and not killed? `quit-window-hook' would be a hook that is mainly used
internally by modes to do their mode-specific cleanup before calling
`quit-window'. `window-configuration-change-hook' also seems to be too
general.

We have to distinguish between two cases when calling the
`quit-window-hook':

1. quit-window, buffer killed, clean up
2. quit-window, buffer buried, maybe do nothing?

All of this decision making could be moved to the `quit-window-hook' so
only modes that care implement it.

Christoph



reply via email to

[Prev in Thread] Current Thread [Next in Thread]