From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: The window-pub branch Date: Sat, 20 Nov 2010 15:43:55 +0100 Message-ID: <4CE7DEAB.8030401@gmx.de> References: 4CE031A6.8010403@gmx.at <4CE56872.6050502@gmx.de> <4CE57519.7030403@gmx.at> <4CE59AC2.9030201@gmx.de> <4CE62E91.4030501@gmx.at> <4CE67DC5.7020603@gmx.de> <4CE68D34.1040308@gmx.at> <4CE6A9C3.5060400@gmx.de> <4CE792B7.7090406@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1290264269 26490 80.91.229.12 (20 Nov 2010 14:44:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Nov 2010 14:44:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 20 15:44:19 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PJofp-0005pL-D9 for ged-emacs-devel@m.gmane.org; Sat, 20 Nov 2010 15:44:17 +0100 Original-Received: from localhost ([127.0.0.1]:52679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJofo-0001zI-Ue for ged-emacs-devel@m.gmane.org; Sat, 20 Nov 2010 09:44:16 -0500 Original-Received: from [140.186.70.92] (port=52602 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJofj-0001z3-SO for emacs-devel@gnu.org; Sat, 20 Nov 2010 09:44:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJofi-0004ni-Iv for emacs-devel@gnu.org; Sat, 20 Nov 2010 09:44:11 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:46731 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PJofi-0004nD-5A for emacs-devel@gnu.org; Sat, 20 Nov 2010 09:44:10 -0500 Original-Received: (qmail invoked by alias); 20 Nov 2010 14:44:07 -0000 Original-Received: from unknown (EHLO [10.75.177.38]) [82.113.106.205] by mail.gmx.net (mp053) with SMTP; 20 Nov 2010 15:44:07 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/e+fJRQgPejR452sGl0WCyTSTCjcA1UsGrL1t2gA wsFcVwxoK5Wz/i User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4CE792B7.7090406@gmx.at> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132914 Archived-At: martin rudalics wrote: > I reinstalled `display-buffer-function' so you have one additional > layer. And the override specifier should give you a way to override > anything supplied by an application. Did you try it, by the way? Actually no. I had already switched to (defadvice display-buffer which works anyway ;) Feedback wise I'd note that I was not pleased to see two of three entries I made to 'display-buffer-names' not work. As a user if I write (new-window (root . left)) and then the new window still opens on bottom, I have better things to do. Design wise, I think that the idea with the specifiers to tweak window layout is not that bad actually. In any case however it seems like a pretty bad idea to scatter these specifiers all over the elisp code (whether explicitly passed as parameters or implicitly with all sort of bizarre long convenience function names.) Why is it not possible to have one single function that takes no specifiers and that is used by all applications with no difference, in combination with pre-configured entries in 'display-buffer-names' to get the desired behavior for specific applications. This would be transparent, prove the power of the design, and as a user I can read the real-use entries and learn from them and alter them if I wish. > It's only when I write display code that I can remove invariants like > "every window must be at least one line tall" or "every live window must > have a live buffer associated with it". When I write code for handling > windows I treat the display code as a black box (or a "third party") > with given restrictions and implied invariants. When I write code for > displaying buffers I treat the code for handling windows as a black box > with given restrictions and implied invariants. I'd maybe rather spend 3 days in one box to remove some restrictions first before I spend 10 months in the other box to work around them. > > martin >