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: Thu, 30 Jun 2011 08:31:29 -0700 Message-ID: References: <4E009EB0.1050903@gmx.at><181538AC4C8B4765A99060E0425B9AB5@us.oracle.com><9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com><8E864413162C4814BE8EFFD0C1FA1989@us.oracle.com><4E06FBF8.9040205@gmx.at> <339CDDF170EF4297B476C3ADC0A7CBCC@us.oracle.com> <4E0C1EF8.5050002@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 1309453725 16458 80.91.229.12 (30 Jun 2011 17:08:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2011 17:08:45 +0000 (UTC) Cc: 'Juanma Barranquero' , 8911@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 30 19:08: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 1QcKjF-00056t-DE for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Jun 2011 19:08:37 +0200 Original-Received: from localhost ([::1]:53964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcKjD-0003Cf-Cm for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Jun 2011 13:08:35 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJDr-0002O8-Bq for bug-gnu-emacs@gnu.org; Thu, 30 Jun 2011 11:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcJDn-00041W-Lh for bug-gnu-emacs@gnu.org; Thu, 30 Jun 2011 11:32:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJDn-00041N-3H for bug-gnu-emacs@gnu.org; Thu, 30 Jun 2011 11:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QcJDm-0006aZ-CS; Thu, 30 Jun 2011 11:32: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: Thu, 30 Jun 2011 15:32: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.130944791225309 (code B ref 8911); Thu, 30 Jun 2011 15:32:02 +0000 Original-Received: (at 8911) by debbugs.gnu.org; 30 Jun 2011 15:31:52 +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 1QcJDb-0006aA-8G for submit@debbugs.gnu.org; Thu, 30 Jun 2011 11:31:51 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QcJDZ-0006Zw-1J for 8911@debbugs.gnu.org; Thu, 30 Jun 2011 11:31:49 -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 p5UFVfY6017352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 15:31:42 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5UFVdVr014508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 15:31:40 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5UFVXv0010041; Thu, 30 Jun 2011 10:31:34 -0500 Original-Received: from dradamslap1 (/10.159.62.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Jun 2011 08:31:33 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acw29K9tf+YBmgYbQIejMav9ZdJhwQAQpXBQ In-Reply-To: <4E0C1EF8.5050002@gmx.at> 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.4E0C96DF.008E: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: Thu, 30 Jun 2011 11:32: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:47629 Archived-At: > > Let me also be clear that it is not about hook vs option. > > It would be fine with me if we had a user option for this > > instead of a hook, as long as it let you do just as much. > > Since I hardly ever bury a buffer please tell me when and how you want > to set up things and what precisely you want that option to > do. I hardly ever (never?) bury a buffer explicitly either. But as Juanma pointed out, we all use (vanilla) Lisp code that calls `bury-buffer'. Anyway, I don't have a precise idea wrt such an option. The general idea is to give users some (easy) way to specify a particular behavior to invoke after `bury-buffer' does its thing of changing the buffer order. IOW, that extra behavior would be invoked/initiated by `bury-buffer'. This is not (for me) about any old change in the buffer order. It is only about complementing the buffer order-changing behavior of `bury-buffer' by adding some user-specified (display) behavior. > We now have an option called `frame-auto-delete' which > might be expanded to do something in this sense. I don't know anything about that. This is not fundamentally about frame deletion. Deleting the frame in this situation would be only one possible user preference. We should not focus on it in particular, I think. > > E.g., a function to be invoked after the buffer order is changed. > > `buffer-list-update-hook' is run when the "buffer order" > changes. Note that there were "f + 1" buffer orders in > Emacs 23 where "f" is the number of live frames and there > are "f + w + 1" buffer orders in Emacs 24 where "w" is > the number of live windows. Again, I'm no expert on this, in any Emacs version. This is about `bury-buffer' (only), and therefore about its particular reordering of the buffer list. After it reorders the list to bury the buffer, a given user (e.g. Stefan, Drew) might want `bury-buffer' to do something about the window or frame that displays that buried buffer. That's the idea - let users specify that display behavior. But I suppose that any behavior whatever could be handled here, not necessarily something to do with displaying that particular buffer window/frame. Put differently, specifying what to do in addition to changing the buffer order could involve other things besides (in addition to or instead of) display. > > Function `ignore' would take care of the do-nothing case. > > The function would need to accept the buffer as its (first) > > argument. > > `buffer-list-update-hook' doesn't have a buffer as argument. We could > change that. But this would not necessarily tell you enough about the > frame that should be deleted or iconified. I don't think (without really knowing anything about that hook) that that hook would be appropriate here. This is only about `bury-buffer' and _its_ particular reordering of the buffer list to bury the buffer. But you're no doubt right that knowing only the buffer would not be enough. Probably the function (option value or new-hook entry) should take the buffer's window as argument also. `bury-buffer' knows what that window is. The idea is to let `bury-buffer' do something about the buffer's window/frame, if the user wants that. That's all. I'd guess that knowing the buffer and the window would be enough. The frame can be gotten from the window. So pretty much anything the user would like to do in this context should be possible by specifying a function that accepts the buffer and window as args. Unless I'm missing something. Ideally, the user should be able to specify a function that accepts those two args and does anything it wants. It could test other things in the current context, besides that buffer and window, and do something appropriate wrt the buffer's display. It could do something different depending on whether this is a special-display situation, or depending on what the buffer name is, or... I'm not trying to specify the exact implementation. No doubt both of you have good ideas about that. My only point is that we should try to: 1. Decouple burying the buffer (changing the buffer order) from doing something about the buffer's display. 2. Let users optionally specify something to do wrt the buffer's display. 3. Make sure that #2 is open-ended, not limited to just choosing between deleting the buffer's frame and iconifying it. A question is whether this is all about just the dedicated-window case or not. We've kind of been talking as if it is only about that case. And that sounds right to me. But we might also want to think about whether such a feature (user specification of what to do about display, after reordering the buffer list) would/should/could also be applicable to other, non dedicated-window, cases for `bury-buffer'. Dunno.