From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8911: bs-cycle-next deletes window in some cases. Date: Wed, 22 Jun 2011 15:01:13 -0700 Message-ID: <8E864413162C4814BE8EFFD0C1FA1989@us.oracle.com> References: <4E009EB0.1050903@gmx.at><181538AC4C8B4765A99060E0425B9AB5@us.oracle.com><9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308780143 17804 80.91.229.12 (22 Jun 2011 22:02:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 22 Jun 2011 22:02:23 +0000 (UTC) Cc: 'Juanma Barranquero' , 8911@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 23 00:02:19 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 1QZVV4-00042a-WB for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Jun 2011 00:02:19 +0200 Original-Received: from localhost ([::1]:35256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVV3-0007wV-PY for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jun 2011 18:02:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVUq-0007wN-3l for bug-gnu-emacs@gnu.org; Wed, 22 Jun 2011 18:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZVUp-0007ej-1v for bug-gnu-emacs@gnu.org; Wed, 22 Jun 2011 18:02:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVUo-0007ef-VE for bug-gnu-emacs@gnu.org; Wed, 22 Jun 2011 18:02:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QZVUo-0006Wo-Ej; Wed, 22 Jun 2011 18:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Jun 2011 22:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8911-submit@debbugs.gnu.org id=B8911.130878009225052 (code B ref 8911); Wed, 22 Jun 2011 22:02:02 +0000 Original-Received: (at 8911) by debbugs.gnu.org; 22 Jun 2011 22:01:32 +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 1QZVUI-0006W1-PY for submit@debbugs.gnu.org; Wed, 22 Jun 2011 18:01:31 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QZVUG-0006Vn-5n for 8911@debbugs.gnu.org; Wed, 22 Jun 2011 18:01:28 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5MM1K4e025694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 22:01:21 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5MM1Ilc017328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2011 22:01:18 GMT Original-Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5MM1CVE019489; Wed, 22 Jun 2011 17:01:12 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jun 2011 15:01:12 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwxGBbl9Tb6ItZLSiaWYrFSXRjlGQAAaTkA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E026632.004E:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 22 Jun 2011 18:02:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:47414 Archived-At: > > As I also said earlier, to me (and per the doc string and the > > function's past behavior) `bury-buffer' is not about display. (That > > is, it is only secondarily about display, and only in the one > > particular case quoted above.) > > There are two ways to call bury-buffer, which correspond to two fairly > different behaviors. One is with a non-nil argument, where it only > touches the order in the buffer-list. This one is uncontroversial and > doesn't matter much to me. Right. Glad that at least in this case you're OK with not doing anything wrt display. > The other is when the argument is nil, in which case it is > *specifically* meant to make the buffer disappear I'm sure I won't be able to convince you, but that is not what the doc string indicates. It speaks only about removing the current buffer _from the selected window_ (if displayed there). To you maybe that suggests something about "disappearing" in the case of a dedicated window. To me it suggests nothing of the kind. To me it suggests on the contrary that this is not at all about that particular case, but is instead _ONLY_ about the case where the buffer _CAN_ be removed from the window. To me, that sentence, which has been around since Day One, covers only the special case that does _not_ include dedicated windows, since the current buffer cannot be removed from such a window. Dedicated windows have also been around a long time, yet the `bury-buffer' doc never said anything about doing anything to a dedicated window or its frame. Never UNTIL, that is, Emacs 23, when you (Emacs Dev) changed it - in the manual. You added this: "But if the selected window is dedicated to its buffer, it deletes that window if there are other windows left on its frame. Otherwise, if the selected window is the only window on its frame, it iconifies that frame." That was never the behavior or the interpretation (doc) before that. AFAIK, before Emacs 23 `bury-buffer' never did anything about the window in the dedicated case. It certainly never made the buffer "disappear" in any way for that case. Instead, it raised the error "Cannot switch buffers in a dedicated window", which to me sounds right. No doubt you consider that previous behavior a bug, but I expect it was by design, and I think it was not a bad choice. > (additionally to changing the buffer-list order). This case is > very much about display, not just secondarily so. Not for the dedicated case - not until Emacs 23, that is. That behavior was grafted on, and IMO it was a mistake. > > The reason is primarily the annoyance that iconifying can > > produce - on Windows it is kind of animated, essentially > > sweeping across the display down to the task bar. With > > frame deletion it just disappears instantly - poof. > > Then we could add an option so that bury-buffer uses delete-frame > instead of iconify-frame. Or `ignore' instead of `iconify-frame'... But why not instead do as I suggested earlier: 1. Return to the pre-23 behavior, so that `bury-buffer' is once again not about display. 2. Add a `bury-buffer-hook', to let people tack on any behavior they like, whether related to display or not. You might tack on `iconify-frame'. I might (or might not) tack on `delete-frame'. Joe Lambda might tack on a logging function to record buffer activity or something. I agree that it will not be uncommon to want to associate some display behavior with `bury-buffer'. I don't think the right idea is to try to decide on one display behavior that fits all. And I would opt for a hook (keeping `bury-buffer' display-free) rather than an option whose default value is some display behavior (e.g. `iconify-frame'). > But doing nothing is not an option since the caller > specifically asked to undisplay the buffer. Not until you changed the meaning to that. A caller of `bury-buffer' wants to change the buffer order. Why mix in additional behavior, so that a caller must now "want" to do a particular mix of things that don't necessarily go together? FWIW.