From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: display-buffer-alist simplifications Date: Mon, 18 Jul 2011 14:28:11 -0700 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@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 1311024537 31666 80.91.229.12 (18 Jul 2011 21:28:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 21:28:57 +0000 (UTC) Cc: 'Chong Yidong' , 'Stefan Monnier' , emacs-devel@gnu.org To: "'Juanma Barranquero'" , "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 23:28:50 2011 Return-path: Envelope-to: ged-emacs-devel@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 1QivMv-0002bz-Hn for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 23:28:49 +0200 Original-Received: from localhost ([::1]:48129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QivMu-0002Y7-EZ for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 17:28:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QivMa-0002Xd-Vc for emacs-devel@gnu.org; Mon, 18 Jul 2011 17:28:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QivMZ-0001oV-04 for emacs-devel@gnu.org; Mon, 18 Jul 2011 17:28:28 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:17159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QivMY-0001oR-Ko for emacs-devel@gnu.org; Mon, 18 Jul 2011 17:28:26 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6ILSKJl027962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2011 21:28:22 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6ILSIur018578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2011 21:28:19 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6ILSCgH017888; Mon, 18 Jul 2011 16:28:13 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Jul 2011 14:28:12 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: AcxFimRzfNpN+4u/SDujHu8b0Vf8BAAAoQnA X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E24A576.0077:SCFSTAT5015188, ss=1, re=-4.000, fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142139 Archived-At: > IMHO, you've taken a lot of time to think of this, and the added > complexity, if any, is added flexibility. I think we should strive to > make the current funcionality of your changes clearer and better > documented. If we stat removing things now, we'll be doomed to re-add > them some day, not long, when people starts to ask for ways to make it > work like it was before (you've seen enough of my private bug reports > to know how true that is ;-) I tend to agree with what Juanma says here, though I'm not really able to judge what is needed, myself. I expect that Martin has looked at the various requirements more than anyone else, and I imagine he has done a good job of coming up with a coherent solution that covers them. We definitely do not want to start over from scratch and risk destabilizing things a great deal. That said, there is a lot to understand, and I'm guessing that we, including Martin, might not see clearly what TRT is until, in fact, we start trying to explain/describe it better. That sounds backward, I know, but for lack of a functional spec I'm guessing that it is especially when we try to document things more clearly that we might come up with a few ideas that could improve the design. It can sometimes happen that by trying to explain something you understand it better and see some possible simplifications. In a way, that's perhaps what Stefan is doing here: trying to fit it all together in his mind and ask questions about how things might be made simpler. Nothing wrong with that. Probably Martin will be the best judge in the end, having a better grasp of all the ramifications, but it might help Martin for people to express other views, as Stefan has done. I worry a bit about too much redesign destabilizing things now. Like Juanma, I think of all the bugs and corner cases that Martin has dealt with already, incrementally. I posted some questions a while back wrt documenting this stuff. Just trying to answer questions like those might help us see a bit more clearly. Maybe; dunno. http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg00677.html I know that Martin has planned to revisit the doc, in any case. I'm guessing that when we start to focus on the doc/explanation we will try better to look at things as a user (different users, with different use cases), and that might help the design. I'm imagining a bit of iteration on this: explanation, maybe tweak the design a bit, explanation, tweak,... I don't expect perfect user doc or a perfect design the first time around the block. Actually, we've already been around the block a bit. And obviously, repeating what I said above, we want to avoid thrashing and introducing new bugs. Dunno, but I think it might be a mistake at this time for Martin to ask Stefan & Yidong, "I can make such-and-such a change, if that's what you want - let me know." I suspect that it is not yet the time to decide some of these things. Just one opinion.