From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Scholtes Newsgroups: gmane.emacs.devel Subject: Re: quit-window Date: Mon, 24 Oct 2011 19:24:04 -0600 Message-ID: <867h3tdft7.fsf@googlemail.com> References: <86mxcsvjsk.fsf@googlemail.com> <867h3vhht5.fsf@googlemail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319505860 16577 80.91.229.12 (25 Oct 2011 01:24:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2011 01:24:20 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 03:24:16 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RIVkW-0002K5-DT for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2011 03:24:16 +0200 Original-Received: from localhost ([::1]:49304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIVkV-00025V-Rc for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2011 21:24:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIVkU-00025N-BP for emacs-devel@gnu.org; Mon, 24 Oct 2011 21:24:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIVkS-0003I6-VP for emacs-devel@gnu.org; Mon, 24 Oct 2011 21:24:14 -0400 Original-Received: from mail-qw0-f41.google.com ([209.85.216.41]:36486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIVkS-0003Hq-RO; Mon, 24 Oct 2011 21:24:12 -0400 Original-Received: by qadc11 with SMTP id c11so3285061qad.0 for ; Mon, 24 Oct 2011 18:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=1bNFsntblEOAdebagm0/eMDlZFlRSWDy/i16CYmiZ4Y=; b=Fa3MxTb72oJZL+3mOxpPX06qYyxUXKzQEVa6FYx2i1UZdexZoG0uw8BQCWF02nLdtO splfV0NXVw6G5Nha4bcvFHPvV00fQM70FKWSZixm5OTZ82W+hMfGHgo6rZvD3sLVeSr5 DSQg8OnkvpvsDjq0PHG9TRQjM5kw/qHNJjkQ4= Original-Received: by 10.224.78.198 with SMTP id m6mr8195050qak.77.1319505852111; Mon, 24 Oct 2011 18:24:12 -0700 (PDT) Original-Received: from MARVIN (71-208-77-210.hlrn.qwest.net. [71.208.77.210]) by mx.google.com with ESMTPS id en3sm10244750qab.22.2011.10.24.18.24.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 18:24:11 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Mon, 24 Oct 2011 12:39:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (windows-nt) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.216.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145488 Archived-At: Richard Stallman 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