[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: quit-window
From: |
martin rudalics |
Subject: |
Re: quit-window |
Date: |
Sun, 23 Oct 2011 11:20:39 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> 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.
> However, some modes are inhibiting consistency by wrapping quit-window
> in a function, which in most cases performs some kind of cleanup. This
> creates inconsistency in the interface since, for example, `C-u q' to
> kill the buffer is not available anymore unless the wrapper passes on
> the argument to quit-window.
>
> Take for example `info-emacs-manual', which provides `Info-exit' bound
> to `q' in its map. `q' will quit the window and bury the buffer, but
> `C-u q' will *not* kill the buffer.
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.)
> 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.
> 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.
> Finally, if there is mode-specific cleanup to be done, could we provide
> a quit-window-hook to connect to so we can eliminate the need for
> wrappers?
>
> This would allow a more consistent behavior between the modes. Maybe
> it's just me, but often I am surprised as a user by the difference in
> behavior of certain commands, especially when it comes to window
> manipulation (quit, kill, bury etc.).
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.
martin
- Re: quit-window, (continued)
- Re: quit-window, Chong Yidong, 2011/10/23
- Re: quit-window, Christoph Scholtes, 2011/10/23
- Re: quit-window, Chong Yidong, 2011/10/23
- Re: quit-window, Richard Stallman, 2011/10/24
- Re: quit-window, Eli Zaretskii, 2011/10/24
- Re: quit-window, martin rudalics, 2011/10/24
- Re: quit-window, Richard Stallman, 2011/10/25
- Re: quit-window, Christoph Scholtes, 2011/10/24
- Re: quit-window, martin rudalics, 2011/10/25
- Re: quit-window, Richard Stallman, 2011/10/25
Re: quit-window,
martin rudalics <=
- Re: quit-window, Juri Linkov, 2011/10/23
- Re: quit-window, Christoph Scholtes, 2011/10/23
- Re: quit-window, martin rudalics, 2011/10/23
- Re: quit-window, Juri Linkov, 2011/10/24
- Re: quit-window, Chong Yidong, 2011/10/24
- Re: quit-window, Juri Linkov, 2011/10/25
Re: quit-window, Christoph Scholtes, 2011/10/23