From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel,gmane.emacs.code-browser Subject: Re: patch for optional inhibit of delete-other-windows(IDE feature) Date: Tue, 29 Apr 2008 17:47:48 +0200 Message-ID: <48174324.30505@gmx.at> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429A02@mucmail3.sdm.de> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429AF9@mucmail3.sdm.de> <4815EE7D.6020304@gmx.at> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429DD9@mucmail3.sdm.de> <48164956.1060204@gmx.at> <84D8FEFE8D23E94E9C2A6F0C58EE07E342A0EB@mucmail3.sdm.de> <481722F7.1080108@gmx.at> <84D8FEFE8D23E94E9C2A6F0C58EE07E342A473@mucmail3.sdm.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1209484305 17014 80.91.229.12 (29 Apr 2008 15:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2008 15:51:45 +0000 (UTC) Cc: ecb-list@lists.sourceforge.net, joakim@verona.se, emacs-devel@gnu.org To: klaus.berndl@sdm.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 29 17:52:19 2008 connect(): Connection refused 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.50) id 1Jqs7o-0007qN-3h for ged-emacs-devel@m.gmane.org; Tue, 29 Apr 2008 17:52:12 +0200 Original-Received: from localhost ([127.0.0.1]:54324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jqs77-0000T5-7Y for ged-emacs-devel@m.gmane.org; Tue, 29 Apr 2008 11:51:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jqs5k-000852-5E for emacs-devel@gnu.org; Tue, 29 Apr 2008 11:50:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jqs5g-00083A-Hi for emacs-devel@gnu.org; Tue, 29 Apr 2008 11:50:01 -0400 Original-Received: from [199.232.76.173] (port=47940 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jqs5g-000834-DM for emacs-devel@gnu.org; Tue, 29 Apr 2008 11:50:00 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Jqs5f-0006gE-RZ for emacs-devel@gnu.org; Tue, 29 Apr 2008 11:50:00 -0400 Original-Received: (qmail invoked by alias); 29 Apr 2008 15:49:58 -0000 Original-Received: from 62-47-55-65.adsl.highway.telekom.at (EHLO [62.47.55.65]) [62.47.55.65] by mail.gmx.net (mp004) with SMTP; 29 Apr 2008 17:49:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18ykYwOPeQyvWmn2VdGCcmaOdFxYMKNJoDhLimD// T8G5mreisu4bNJ User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E342A473@mucmail3.sdm.de> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:96146 gmane.emacs.code-browser:2127 Archived-At: > By setting `temp-buffer-show-function' to the following ecb-function > which does this. I see. Maybe we could introduce an option which makes temporary buffers always appear in a window on the bottom of the frame, technically spoken in a subwindow of the root-window of that frame. If Emacs can handle resizing the remaining windows well this wouldn't be very hard. What happens when you want to display a compile- and a help-window (or Info window) appear all at the same time? > To make a long story short: It would be very very great if there is > a commitment that *each* command or function which has to display > a buffer in a window uses internaly `display-buffer', because then > it would probably sufficient for ECB to patch this machanism (either > by adding a full featured display-buffer-function or by advicing > display-buffer itself). > > What is the current state with this respect? `switch-to-buffer' surely won't. > ecb-redraw-layout-full performs all the layouting. For this it does > all the window-structure-independ stuff out-of-the-box and then it > calls a special layout-function `ecb-layout-function-' > which performs all the splits necessary for a certain layout... We can't do this in window.c. We would have to be able to get the current layout independently from how it was obtained in the first place. > another topic: ECB automatically stores all split-window-* calls > and delete-window and delete-other-windows calls performed in the > edit-area (this is simply done by before-advices of these commands). > so after a full redraw ECB "replays" these stored split- and delete- > commands and voila: the edit-area has the same window-structure > as before... but it had cost me huge effort to implement this stable. Plus the perfomance penalty from storing and retrieving this. We have to get away from this "operational" (split-/delete-window operations based) view of the current frame layout. > It would be very great if the object `save-window-configuration' > stores would be "readable" or "accessible" in a way so we could > restore only parts of a frame (in case of ECB the edit-area)... > Do not know the current state of Emacs with this respect?! Currently it works for frames only. We'd have to strip the frame specific parts (like the visibility, toolbar, menubar settings) which is easy. The problem remains _how_ we want to identify the "part of the frame" (the edit-area in your case). Technically it is, as I explained earlier, an internal Emacs window. We have to expose it to the Elisp programmer in a convenient way. For safety reasons I'm against exposing the internal window directly to Elispers (XEmacs does that). >>IIUC the first thing we should provide is find a way to (i) squeeze an >>entire frame into a window and (ii) blow up an internal Emacs window >>to >>a frame. The only problems I see here are how to specify the internal >>window (saying the smallest internal window containing windows 10, 14 >>and 17 seems tedious) and how to preserve identities of windows within >>such configurations (`set-window-configuration' is notorious for >>breaking the 'window overlay-property). > > > Ooops, sorry, but i haven't understand this paragraph..what do you > want to say (maybe my english is to bad)?! Merely what you asked about `save-window-configuration' above - how to turn a collection of windows into a frame and vice versa. But how do we identify collections of windows: By giving every window a group number you might say, specifying a collection as the set of all windows with that number. However, I probably simply want to clone a collection of windows into a second frame. What number do I assign the new windows? I save a collection into a configuration and restore that configuration later. Are numbers retained? Maybe all these issues are trivial, but better think about them now. >>... and `other-window' always stays within one and the same group, I >>presume. We then probably want a command `other-group' and bind it to >>C-x ... o. > > other-window is adviced: [...] > This function has to handle all properly situations for itself. > `ecb-get-other-window-smart' is an example for such a function." I see. Nevertheless, if we talk about groups (or "perspectives") from an Emacs point of view, we'll have to provide primitives for switching between groups, independently from how ECB handles this. Later you can decide whether and how you want to use these primitives from ECB.