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: Tue, 2 Aug 2011 09:41:16 -0700 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com><4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> <4E380918.3060806@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 1312303305 14324 80.91.229.12 (2 Aug 2011 16:41:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 16:41:45 +0000 (UTC) Cc: 'Chong Yidong' , emacs-devel@gnu.org To: "'martin rudalics'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 18:41:37 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 1QoI2D-0005no-4m for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 18:41:37 +0200 Original-Received: from localhost ([::1]:33475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoI2C-0000lQ-C2 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 12:41:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoI29-0000lL-F7 for emacs-devel@gnu.org; Tue, 02 Aug 2011 12:41:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoI27-0006TE-Lw for emacs-devel@gnu.org; Tue, 02 Aug 2011 12:41:33 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:62792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoI27-0006T7-Fb for emacs-devel@gnu.org; Tue, 02 Aug 2011 12:41:31 -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 p72GfOwQ023701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 16:41:26 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 p72GfMSq000636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 16:41:23 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p72GfHUm004519; Tue, 2 Aug 2011 11:41:17 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 09:41:16 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E380918.3060806@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: AcxRIDu9s0lTSPu5Rbi3VJ0ue7OgGQAC16Qg X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E3828B6.007F,ss=1,re=0.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:142711 Archived-At: > `special-display-buffer-names' had only one serious user, > namely Drew Adams. I know that because my rewrite had a > number of bugs which we eliminated in a period of two > weeks mostly by trial and error. In all that time no one else > complained. I suppose you use it as well but since you apparently > advice `display-buffer' (or some subset of its routines) you > were not hit by these bugs. > > `special-display-buffer-names' is complex because it prescribes > behavior for reusing the same window, reusing some other window > on the same frame, popping up a new window, reusing a window on > another frame and popping up a new frame. That's the kind of > expressiveness Drew needs because he's got no other choice. > It's far too expressive for all other users. A comment, since my case has been identified as unique - 1. `special-display-buffer-names' is _very_, very old. It has been in GNU Emacs as far back as the introduction of frames, I believe. Someone can check the origin and the original design arguments; I'm no expert on this. 2. AFAIK, from the outset it has been just as "complex" as it is today - all of the possibilities have been there since Day One. They were not added incrementally because someone thought that it would be neat to add a bell here or a whistle there. They were thought to be important by the _original designers_, many, many moon ago. 3. The point is that I did not invent `special-display-buffer-names', and it was not invented for me. ;-) I have made use of it for decades (since at least Emacs 19, maybe 18, IIRC), and I have always made the _same_ use of it. 4. Here is the _only_ use I make of it - Drew's weirdo use case. I use only the form (BUFFER FUNCTION OTHER-ARGS...), and only for two buffers: *Help* and *Completions*. This is my value of `special-display-buffer-names': (("*Completions*" 1on1-display-*Completions*-frame ((background-color . "LavenderBlush2") (mouse-color . "VioletRed") (cursor-color . "VioletRed") (menu-bar-lines . 0) (tool-bar-lines . 0) (width . 100))) ("*Help*" 1on1-display-*Help*-frame ((background-color . "Thistle") (mouse-color . "Blue Violet") (cursor-color . "Blue Violet") (height . 40)))) 5. How does it work? Per the definition of `special-display-buffer-names', the alist entry for *Help* or *Completions* is used by `special-display-popup-frame' (the default value of `special-display-function') to display the buffer. That's all. IOW, *Help* is displayed by calling `1on1-display-*Help*-frame', passing the associated background-color, etc. Similarly, *Completions* is shown by `1on1-display-*Completions*-frame'. 6. In sum, my use of `special-display-buffer-names' is to provide a function and associated frame parameters for displaying buffer *Help*, likewise *Completions. Nothing more. No big deal, IMO. 7. For buffer *Completions*, for example, the special-display function `1on1-display-*Completions*-frame' does all of this: a. Display the buffer in a separate frame with the given frame parameters. This also includes positioning it (left or right) per a user option. b. Zoom the buffer text per a user option (typically to show more candidates by reducing the text size). c. Raise the frame to the front. d. Redirect the frame's keyboard input focus to the standalone minibuffer frame, if there is one. HTH. Personally, I do not consider my use of `special-display-buffer-names' to be strange or outlandish - it seems pretty simple to me. If it is true that I am the only one to use this feature, so be it. But that in itself does not make this feature or my use of it "complex". And I would even guess that if more things worked better in GNU Emacs wrt frames (as opposed to just windows) then you might see more people using this feature. FWIW, my code for this works in Emacs 20 through 23, and it also works with Emacs 24 after Martin's efforts to fix some initial bugs (thank you, Martin!). And it works cross-platform, AFAIK. Not so far out, really. [FWIW2: IIRC, my use of a standalone minibuffer and *Help* and *Completions* frames predates my code in GNU Emacs. IIRC (and no, I don't remember this very well), I had the same thing in Epoch. And in Epoch (IIRC) it _just worked_ out of the box to have a standalone minibuffer frame: no fiddling, no "special" frames, no input redirection, nada! Again, that was long ago and I do not remember it well, but I'm pretty sure that I had the same kind of setup as now, and I did not have to jump through any hoops to get it. When I moved back again to GNU Emacs I tried to reproduce some of the nice setup I had in Epoch - with difficulty. And, IIUC, some of Epoch's fine features are still missing from GNU Emacs... On n'arrete pas le progres.]