From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer Date: Sat, 03 Sep 2011 20:44:09 +0300 Message-ID: <83ty8tzfkm.fsf@gnu.org> References: <831uw0dukq.fsf@gnu.org> <4E6208FA.1030404@gmx.at> <834o0t266l.fsf@gnu.org> <4E62319B.3050509@gmx.at> <83y5y5zozj.fsf@gnu.org> <4E6263F9.4000207@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1315071885 22406 80.91.229.12 (3 Sep 2011 17:44:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2011 17:44:45 +0000 (UTC) Cc: 9419@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 03 19:44:39 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1QzuGj-0005Yk-Sj for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2011 19:44:38 +0200 Original-Received: from localhost ([::1]:33831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzuGj-0004zo-Bg for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2011 13:44:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzuGf-0004xt-Dr for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:44:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzuGd-0000jq-Nf for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:44:33 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzuGd-0000jm-LM for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:44:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QzuK2-0000QS-IC; Sat, 03 Sep 2011 13:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Sep 2011 17:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9419-submit@debbugs.gnu.org id=B9419.13150720711614 (code B ref 9419); Sat, 03 Sep 2011 17:48:02 +0000 Original-Received: (at 9419) by debbugs.gnu.org; 3 Sep 2011 17:47:51 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QzuJr-0000Py-E6 for submit@debbugs.gnu.org; Sat, 03 Sep 2011 13:47:51 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QzuJo-0000Pq-UZ for 9419@debbugs.gnu.org; Sat, 03 Sep 2011 13:47:50 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LQY00M00JJWQQ00@a-mtaout21.012.net.il> for 9419@debbugs.gnu.org; Sat, 03 Sep 2011 20:44:07 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.83.44]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQY00M2OJXIR210@a-mtaout21.012.net.il>; Sat, 03 Sep 2011 20:44:07 +0300 (IDT) In-reply-to: <4E6263F9.4000207@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 03 Sep 2011 13:48:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:50571 Archived-At: > Date: Sat, 03 Sep 2011 19:29:29 +0200 > From: martin rudalics > CC: 9419@debbugs.gnu.org > > >> (save-window-excursion > >> (display-buffer "foo")) > >> > >> which doesn't DTRT when foo is displayed on a different frame. > > > > You mean, if display-buffer creates a new frame? Or that frame > > already exists, and display-buffer just raises it and makes it the > > selected frame? > > > > And what do you mean by "doesn't DTRT"? What is TRT in that case? > > In the idiom above, when a user has `pop-up-frames' nil, a new window > showing the buffer gets created on the selected frame and gets deleted > when the window excursion terminates. When a user has `pop-up-frames' > non-nil and a new frame gets created that frame is not deleted. This > fact has already caused some vivid discussions here. IMO TRT is to > treat windows and frames the same. Agreed. > > Perhaps I'm missing something, but if we are talking about "long time > > after", then which buffer causes frame deletion is immaterial: they > > both will cause the same amount of surprise. > > Precisely this mechanism is inherent to help frames you quit with "q" in > Emacs 23. Quitting any other buffer in such a frame would not cause its > deletion. That sucks, IMO. > > This is actually how I bumped into this problem in the first place. I > > have a frame where I switch between different *info* buffers > > showing various manuals, using the info-display-manual command. > > Whenever the Emacs or ELisp manuals are rebuilt (because they are > > updated on the trunk), I kill the corresponding buffer and re-read > > that manual anew. When I started using Emacs 24, I was surprised to > > find out that this sometimes, but not always, deleted the entire > > frame. I now understand that this depends on which buffer I was > > killing and in what order, but believe me: the surprise was complete, > > and the apparently inconsistent behavior only added to it. > > You should have protested immediately. Believe it or not, this bug report is my "immediate" protest ;-) It took time for me to realize that the frame deletion was not due to some cockpit error on my part, and then some more time to create a simple recipe suitable for submission. > > I can see 3 possible ways to have a consistent behavior: > > > > . Never delete a frame except by an explicit call to delete-frame. I > > think this is what Emacs 23 did, so it is also backward-compatible. > > There are two exceptions in Emacs 23 to this rule - help frames and > dedicated frames. > > > . A minor variation on the above: never delete a frame, except when > > it was created by display-buffer, and never had more than one > > buffer in its buffer list. IIUC the use case you were trying to > > fix, this will fix it. > > Tracking the "never had more than one buffer" is tedious but could be > done. > > > . Always delete a frame whenever the last buffer in its buffer list > > is killed. This is a change in behavior wrt Emacs 23, so it should > > probably be conditional on some option. > > It is: Setting `frame-auto-delete' to nil should inhibit implicit > deletion of frames. So I think the second alternative is the best, if it is doable. > But it won't inhibit implicit deletion of windows, something hardly > anyone has noticed (Juanma is the only one who suffers from it so > far). I did notice that. I just didn't yet make up my mind whether I like it or not. > I can do whatever people want. But consistency should also cover the > window/frame dichotomy. Agreed. So how about this plan: . Never delete a frame, except when it was created by display-buffer, and never had more than one buffer in its buffer list. . Do the same with windows created by display-buffer: if the user switched buffers in that window, don't delete the window when the excursion ends. . Introduce a window-auto-delete option, by default set the same as frame-auto-delete, to control window deletion like frame-auto-delete controls that of frames. Alternatively, deprecate frame-auto-delete and introduce a new frame-and-window-auto-delete with the old one its alias. Then make this new option control both window and frame auto-deletion alike.