From: Christoph Scholtes <cschol2112@googlemail.com>
To: rms@gnu.org
Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
Subject: Re: quit-window
Date: Mon, 24 Oct 2011 19:24:04 -0600 [thread overview]
Message-ID: <867h3tdft7.fsf@googlemail.com> (raw)
In-Reply-To: <E1RINYY-00035N-0g@fencepost.gnu.org> (Richard Stallman's message of "Mon, 24 Oct 2011 12:39:22 -0400")
Richard Stallman <rms@gnu.org> writes:
> As far as buffers are concerned, it is no different from any other
> change in selection. That's not supposed to change anything about
> any buffer.
Except for the buffer associated with the temporary window, right? If the
content of the window is of temprary nature (in most cases) I would want
to kill the associated buffer when the window is quit.
> Thus, if a mode tries to do something nontrivial to the buffer on the
> occasion of quitting, that makes me worry. Should that be done at
> all?
That would have to be decided on a case by case basis, I think.
> 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.
>
> I think we need to study carefully what things they do, and whether there
> is a good reason for them.
I agree. I basically just looked for cases where the keymap bound `q',
but did not bind it to quit-window, but some other function,
e.g. ibuffer-quit.
Take this:
(defun ibuffer-quit ()
"Quit this `ibuffer' session.
Try to restore the previous window configuration if
`ibuffer-restore-window-config-on-quit' is non-nil."
(interactive)
(if ibuffer-restore-window-config-on-quit
(progn
(bury-buffer)
(unless (= (count-windows) 1)
(set-window-configuration ibuffer-prev-window-config)))
(bury-buffer)))
Here I am wondering if the same couldn't be achieved by a call to
(the new and improved) `quit-window'.
> I looked at Info-exit and it seems ok, because it is only doing
> something special in the case of stand-alone Info.
It wraps `quit-window' in a way that I cannot use `C-u q' to quit the
window and *kill* the buffer, though.
Something like
(defun Info-exit (kill)
"Exit Info by selecting some other buffer."
(interactive "P")
(if Info-standalone
(save-buffers-kill-emacs)
(quit-window kill)))
would allow that and be consistent with other cases where `q' binds
`quit-window' directly. The next step would then be the previously
discussed `quit-window-hook' to move the additional functionality to (if
applicable).
> We don't want to install these changes now, but there's no need to
> delay the studying.
I will create a list of the occurrences I found and look at if (and what)
functionality would get lost if the function used `quit-window'. This is
obviously only for cases where the additional functionality deals with
window management.
Christoph
next prev parent reply other threads:[~2011-10-25 1:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-22 20:43 quit-window Christoph Scholtes
2011-10-23 7:23 ` quit-window Chong Yidong
2011-10-23 15:02 ` quit-window Christoph Scholtes
2011-10-23 23:49 ` quit-window Chong Yidong
2011-10-24 16:39 ` quit-window Richard Stallman
2011-10-24 17:18 ` quit-window Eli Zaretskii
2011-10-24 17:40 ` quit-window martin rudalics
2011-10-25 12:19 ` quit-window Richard Stallman
2011-10-25 1:24 ` Christoph Scholtes [this message]
2011-10-25 13:01 ` quit-window martin rudalics
2011-10-25 18:55 ` quit-window Richard Stallman
2011-10-23 9:20 ` quit-window martin rudalics
2011-10-23 13:27 ` quit-window Juri Linkov
2011-10-23 16:04 ` quit-window Christoph Scholtes
2011-10-23 18:58 ` quit-window martin rudalics
2011-10-24 5:12 ` quit-window Juri Linkov
2011-10-25 3:59 ` quit-window Chong Yidong
2011-10-25 4:28 ` quit-window Juri Linkov
2011-10-23 16:01 ` quit-window Christoph Scholtes
2011-10-23 19:00 ` quit-window martin rudalics
2011-10-25 1:00 ` quit-window Christoph Scholtes
2011-10-25 10:04 ` quit-window martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2007-10-19 9:00 quit-window martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867h3tdft7.fsf@googlemail.com \
--to=cschol2112@googlemail.com \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).