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, 29 Jun 2011 08:36:23 -0700 Message-ID: References: <4E009EB0.1050903@gmx.at><181538AC4C8B4765A99060E0425B9AB5@us.oracle.com><9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com><8E864413162C4814BE8EFFD0C1FA1989@us.oracle.com><4E06FBF8.9040205@gmx.at> 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 1309370968 7532 80.91.229.12 (29 Jun 2011 18:09:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Jun 2011 18:09:28 +0000 (UTC) Cc: 8911@debbugs.gnu.org To: "'Stefan Monnier'" , "'Juanma Barranquero'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 29 20:09:24 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 1QbzCV-00028i-Lj for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 Jun 2011 20:09:23 +0200 Original-Received: from localhost ([::1]:41763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbzCU-00069o-JA for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 Jun 2011 14:09:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbwp7-0005eJ-LE for bug-gnu-emacs@gnu.org; Wed, 29 Jun 2011 11:37:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbwp5-0007hy-D7 for bug-gnu-emacs@gnu.org; Wed, 29 Jun 2011 11:37:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbwp4-0007hG-Rq for bug-gnu-emacs@gnu.org; Wed, 29 Jun 2011 11:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Qbwp3-00073X-VR; Wed, 29 Jun 2011 11:37: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, 29 Jun 2011 15:37: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.130936180427092 (code B ref 8911); Wed, 29 Jun 2011 15:37:01 +0000 Original-Received: (at 8911) by debbugs.gnu.org; 29 Jun 2011 15:36:44 +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 1Qbwol-00072v-TD for submit@debbugs.gnu.org; Wed, 29 Jun 2011 11:36:44 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qbwoj-00072e-TU for 8911@debbugs.gnu.org; Wed, 29 Jun 2011 11:36:43 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5TFaXBi014221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 15:36:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5TFaVFU008588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 15:36:32 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5TFaPZk012647; Wed, 29 Jun 2011 10:36:26 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Jun 2011 08:36:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acw2DHzoxaLoBGkWRimq6ibo+Ktv9QAXGSMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E0B4683.014C:SCFSTAT5015188, 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, 29 Jun 2011 11:37: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:47568 Archived-At: > M-x bury-buffer RET *should* iconify the current frame > if it shows a single dedicated window (with the caveat > that Drew wants it to delete the frame instead). So...it *SHOULD*...(but Drew wants something different). Hm. "Drew wants". What Drew might want for his personal use is one thing. What Drew wants for Emacs is another thing. In either case you misrepresent what Drew wants. I made it clear that I did _not_ "want it to delete the frame instead". That is _not_ the behavior I prefer for Emacs, and it is not even my preference for my own use all of the time. I said, speaking about the dedicated-window case: > 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'. NO deletion and NO iconification, by default. That's what Drew wants for Emacs. But also with the possibility for a _user_ to add deletion or iconification - or anything else s?he might like. I said that we should give users control. Users who, like Stefan, might want `bury-buffer' for a dedicated window to always be accompanied by iconification, and users who might want it to instead always delete the frame, should be able to get what they want. But also users who might want `bury-buffer' to iconify in context A, delete in context B, thumbify in context C, and do nothing at all to the display in context D -- those users too should be able to get the behavior they prefer. There's nothing holy about Stefan's or Drew's preferences for personal use - those personal preferences should not preclude other users from getting other behaviors that they prefer. I proposed adding a `bury-buffer-hook', which users can use to do anything they like after `bury-buffer' changes the buffer order: > so users like Stefan can make it also do after > just changing the buffer order. In particular, the > could play with the display (iconify or delete frame etc.) > > Without doing anything in the hook, a dedicated > window/frame/buffer would just stay there. Simple, clean, easy to use, decoupled. Flexible for different contexts. Stefan countered with a (reluctant "Drew wants") proposal to add an option to give users just a little control of the display behavior: S> add an option so that bury-buffer uses delete-frame S> instead of iconify-frame. But he refused to let users (a) do _nothing_ in terms of display (e.g. leave the dedicated window/frame, with its buried buffer) or (b) do something different altogether. The option he proposed does not let users choose any other behavior (or no behavior), besides deletion and iconification. And naturally he wants iconification to be the default. My argument isn't to delete the frame. My argument is to give the _user_ control. My argument is that `bury-buffer' is essentially about changing the buffer order, and any choice about what to do (if anything) about the _display_ of the buried buffer (delete, iconify, leave alone,...) should be the _user's_ choice, not Stefan's choice hard-wired into the design. Even if you insisted on prepopulating the hook so that the _default_ behavior was whatever you prefer (e.g. iconifying), what I would like is for users to have real control over the behavior - not just some binary option to delete instead of iconify. That's what "Drew wants". If you refuse to give the user real control, however, and you insist on coupling some display behavior with the changing of the buffer order (`bury-buffer's raison d'etre), then yes, in that desperate case _only_, I said: > _if_ the buffer is to be made to "disappear" then my (second) choice > would be for it to disappear via `delete-frame', not iconification. But why not let users get whatever behavior they want, easily? Why insist on deciding for them? We know we want `bury-buffer' to bury the buffer: change the buffer order. That's not in question. What's not agreed upon is what else it should do, particularly in the case of a dedicated window. I say, let users themselves decide. Buffer display, and especially so for dedicated windows, can be a complex, personal matter. Please don't force automatic frame iconification (or deletion for that matter) on everyone. There's no need for that.