From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: quit-window Date: Tue, 25 Oct 2011 12:04:03 +0200 Message-ID: <4EA68993.7050609@gmx.at> References: <86mxcsvjsk.fsf@googlemail.com> <4EA3DC67.8050607@gmx.at> <8639ejhf3b.fsf@googlemail.com> <4EA46455.5060408@gmx.at> <86d3dldgxa.fsf@googlemail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1319537063 3261 80.91.229.12 (25 Oct 2011 10:04:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2011 10:04:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Christoph Scholtes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 12:04:17 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 1RIdrk-0004yK-Cu for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2011 12:04:16 +0200 Original-Received: from localhost ([::1]:36352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIdrj-0001kY-FK for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2011 06:04:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIdrh-0001kN-Ij for emacs-devel@gnu.org; Tue, 25 Oct 2011 06:04:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIdrb-0007VQ-Sr for emacs-devel@gnu.org; Tue, 25 Oct 2011 06:04:13 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:38078) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RIdrb-0007V3-Hn for emacs-devel@gnu.org; Tue, 25 Oct 2011 06:04:07 -0400 Original-Received: (qmail invoked by alias); 25 Oct 2011 10:04:05 -0000 Original-Received: from 62-47-33-69.adsl.highway.telekom.at (EHLO [62.47.33.69]) [62.47.33.69] by mail.gmx.net (mp044) with SMTP; 25 Oct 2011 12:04:05 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+N4SwRONqNPQR2tV11Zxe8VW2RuR8G3q6aiezFU3 A2joVz04r0lpnp User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <86d3dldgxa.fsf@googlemail.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:145509 Archived-At: >> W'de have to handle this test >> >> (if Info-standalone >> (save-buffers-kill-emacs) >> (quit-window))) >> >> somehow without creating surprises for people using the standalone >> version. > > What surprises are you thinking of? If, in info.el we replace (define-key map "q" 'Info-exit) by (define-key map "q" 'quit-window) anyone who reads Info with the standalone reader won't have his emacs killed when she types "q". This would be surprising. >> The problem is that the more hooks we have in one call, the more the >> order in which these hooks are executed does matter. For example, I >> believe that when I run `kill-buffer', `kill-buffer-hook' is called >> before `window-configuration-change-hook'. When I run `quit-window' >> with the first argument t, the order seems >> `window-configuration-change-hook', `kill-buffer-hook', and possibly >> another `window-configuration-change-hook' if the buffer was displayed >> in a second window. This is already very confusing for me in current >> Emacs. > > That does seem confusing. I wonder why there are differences. It makes sense to run `kill-buffer-hook' immediately after running the `kill-buffer-query-functions' with the buffer to be killed current. Only after that emacs decides that the buffer shall be removed from display. That `quit-window' first removes the window and then decides whether to kill the buffer wouldn't be easy to change (mostly because people don't like that `kill-buffer' calls `quit-window'). martin