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: Tue, 21 Jun 2011 19:53:01 -0700 Message-ID: <9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com> References: <4E009EB0.1050903@gmx.at><181538AC4C8B4765A99060E0425B9AB5@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 1308711351 30966 80.91.229.12 (22 Jun 2011 02:55:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 22 Jun 2011 02:55:51 +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 Wed Jun 22 04:55:47 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 1QZDbW-0002Pb-Oq for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jun 2011 04:55:47 +0200 Original-Received: from localhost ([::1]:45125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZDbV-0007gl-Qs for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Jun 2011 22:55:45 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZDZs-0007MZ-Cd for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 22:54:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZDZq-0001D2-Uh for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 22:54:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZDZq-0001Cu-Mc for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 22:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QZDZp-0005Wa-Tn; Tue, 21 Jun 2011 22:54:01 -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 02:54:01 +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.130871119721178 (code B ref 8911); Wed, 22 Jun 2011 02:54:01 +0000 Original-Received: (at 8911) by debbugs.gnu.org; 22 Jun 2011 02:53:17 +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 1QZDZ6-0005VW-Kr for submit@debbugs.gnu.org; Tue, 21 Jun 2011 22:53:16 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QZDZ3-0005VK-I0 for 8911@debbugs.gnu.org; Tue, 21 Jun 2011 22:53:14 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5M2r5IU022380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 02:53:07 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5M2r4Un005396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2011 02:53:05 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5M2qxhR024947; Tue, 21 Jun 2011 21:52:59 -0500 Original-Received: from dradamslap1 (/10.159.50.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jun 2011 19:52:59 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcwwgavphtOlUdbWRCewjnRucTFlywAAyxxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E015913.0057: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: Tue, 21 Jun 2011 22:54:01 -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:47402 Archived-At: > > I would like `bury-buffer' to be decoupled from > > iconification. I would like `bury-buffer' to do > > nothing particular wrt dedicated windows. > > I'm not sure what "particular" means here. I explained what it means in the earlier mail: | [from the doc string:] | | "Also, if BUFFER-OR-NAME is nil or omitted, | remove the current buffer from the selected window | if it is displayed there." | | It is impossible to "remove the current buffer from the | selected window" if that window is dedicated, so this | secondary behavior naturally becomes a no-op in that case. | | If the window is dedicated, then I'd rather see one of | these behaviors than I would iconification of the buffer's | frame: | | a. Do nothing wrt the display. See above: a no-op wrt display. | b. Delete the frame. | | Perhaps the best approach is (a) above: have `bury-buffer' | just bury the buffer (i.e. affect the buffer order) and | not have it do anything wrt the display in this case. IOW, not disappear or move in any way - an unchanged display. The only effect would be the change in buffer order that is the raison d'etre of `bury-buffer': make it least likely to be used as `other-buffer'. > Part of the drive behind iconification is that I want > bury-buffer to be a sort of reverse-display-buffer, 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.) `bury-buffer' is about reducing the priority of the buffer in the buffer order - e.g., for `other-buffer'. Of course display can come into play later, when `other-buffer' (or some other function) does its thing, which can involve display. But `bury-buffer' should not be about affecting the current display of buffers, except in the one case documented. At least that would be my preference, I think. For the case in question (dedicated), if the buffer is to be made to "disappear" then my (second) choice would be for it to disappear via `delete-frame', not iconification. 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. > such that display-buffer followed by bury-buffer should be > a no-op (I know it's not always the case), so as to replace > save-window-excursion with something that does not impose > nesting and that works with frames.