unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
To: Christoph Scholtes <cschol2112@googlemail.com>
Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
Subject: Re: quit-window
Date: Tue, 25 Oct 2011 14:55:47 -0400	[thread overview]
Message-ID: <E1RImA7-0006Md-Pg@fencepost.gnu.org> (raw)
In-Reply-To: <867h3tdft7.fsf@googlemail.com> (message from Christoph Scholtes on Mon, 24 Oct 2011 19:24:04 -0600)

    > 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.

Yes, it sometimes does kill the buffer.  But that should work like
killing the same buffer through any other command.

    > 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. 

We need to start by deciding them case by case.  But if we see enough
cases, we might be able to adduce some general rules about how to
handle them.

    > 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. 

You're right that it has a bug.  My point is that the basic idea of
using a special `Info-exit' command is reasonable.  There is no reason
why `quit-window' should try to handle any special needs of
stand-alone Info in Emacs.

However, if stand-alone Info in Emacs is obsolete, we can just delete
`Info-exit' and use `quit-window' directly.

    but did not bind it to quit-window, but some other function,
    e.g. ibuffer-quit.

    Here I am wondering if the same couldn't be achieved by a call to
    (the new and improved) `quit-window'.

It could be so.  Anyway, what we see here is special manipulation of
the window configuration.  That's the sort of thing that makes sense
for `quit-window' to do.  So if it doesn't already do everything
that's most useful for ibuffer, maybe we should extend `quit-window'
to do whatever it is.

    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.

That seems like a very useful thing to do.



-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/



  parent reply	other threads:[~2011-10-25 18:55 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       ` quit-window Christoph Scholtes
2011-10-25 13:01         ` quit-window martin rudalics
2011-10-25 18:55         ` Richard Stallman [this message]
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=E1RImA7-0006Md-Pg@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=cschol2112@googlemail.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@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).