From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 19:29:29 +0200 Message-ID: <4E6263F9.4000207@gmx.at> References: <831uw0dukq.fsf@gnu.org> <4E6208FA.1030404@gmx.at> <834o0t266l.fsf@gnu.org> <4E62319B.3050509@gmx.at> <83y5y5zozj.fsf@gnu.org> 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 1315071045 17189 80.91.229.12 (3 Sep 2011 17:30:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2011 17:30:45 +0000 (UTC) Cc: 9419@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 03 19:30:37 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 1Qzu3A-0000iu-NY for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2011 19:30:37 +0200 Original-Received: from localhost ([::1]:40475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qzu3A-0001YV-6B for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2011 13:30:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qzu36-0001YB-Bk for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:30:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qzu35-0006u9-Bw for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:30:32 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qzu35-0006u5-8z for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2011 13:30:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Qzu6T-0007sR-Ua; Sat, 03 Sep 2011 13:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics 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:34:01 +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.131507118730212 (code B ref 9419); Sat, 03 Sep 2011 17:34:01 +0000 Original-Received: (at 9419) by debbugs.gnu.org; 3 Sep 2011 17:33:07 +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 1Qzu5b-0007rF-0K for submit@debbugs.gnu.org; Sat, 03 Sep 2011 13:33:07 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Qzu5X-0007r5-IC for 9419@debbugs.gnu.org; Sat, 03 Sep 2011 13:33:05 -0400 Original-Received: (qmail invoked by alias); 03 Sep 2011 17:29:30 -0000 Original-Received: from 62-47-50-116.adsl.highway.telekom.at (EHLO [62.47.50.116]) [62.47.50.116] by mail.gmx.net (mp051) with SMTP; 03 Sep 2011 19:29:30 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18SPWp7oW8SJU6hWP94wtGxBHAFM+EkUatU1qpEv2 2Fd1Q59PkhTVKR User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <83y5y5zozj.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 03 Sep 2011 13:34:01 -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:50569 Archived-At: >> The problem I originally wanted to solve is the following idiom >> >> (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. > 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. > 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. >> I can remove this restriction and kill the buffer in the "kill foo first >> and bar afterwards" scenario too, but then I will delete a window always >> when all buffers I've ever shown in it have gone. What do you mean? > > 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. 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). > Anything else is inconsistent, IMO, and inconsistency is always worse > than any consistent alternative, in my experience. I can do whatever people want. But consistency should also cover the window/frame dichotomy. martin