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 15:30:31 +0200 Message-ID: <481722F7.1080108@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> 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 1209475950 16912 80.91.229.12 (29 Apr 2008 13:32:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2008 13:32:30 +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 15:33:06 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 1Jqpx0-0004fg-U2 for ged-emacs-devel@m.gmane.org; Tue, 29 Apr 2008 15:32:55 +0200 Original-Received: from localhost ([127.0.0.1]:56889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqpwJ-00039F-Hn for ged-emacs-devel@m.gmane.org; Tue, 29 Apr 2008 09:32:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JqpwF-00038y-C1 for emacs-devel@gnu.org; Tue, 29 Apr 2008 09:32:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JqpwC-00037x-Mz for emacs-devel@gnu.org; Tue, 29 Apr 2008 09:32:06 -0400 Original-Received: from [199.232.76.173] (port=54445 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqpwC-00037t-DF for emacs-devel@gnu.org; Tue, 29 Apr 2008 09:32:04 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JqpwB-00045k-TY for emacs-devel@gnu.org; Tue, 29 Apr 2008 09:32:04 -0400 Original-Received: (qmail invoked by alias); 29 Apr 2008 13:32:02 -0000 Original-Received: from 62-47-34-225.adsl.highway.telekom.at (EHLO [62.47.34.225]) [62.47.34.225] by mail.gmx.net (mp045) with SMTP; 29 Apr 2008 15:32:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19a8Jkg2Vha3Nq0F9zB5XGRpuYE+qDA4BTunotd+x u9a2iKx355/pnj User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E342A0EB@mucmail3.sdm.de> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: 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:96139 gmane.emacs.code-browser:2125 Archived-At: > The compile-window is used to display all stuff like help-buffers, compile- > grep-buffer etc... Do you mean that C-h ... are not allowed to display the help buffer in the edit-area? How do you achieve that? > is customizable by mode and regexp which buffers should > be automatically alwasy being displayed in the compile-buffer - example: > When you do switch-to-buffer in one of the edit-windows and you insert a > buffer which is customized to be displayed in the compile-window then > ECB will switch to this buffer in the compile-window (if it is displayed > in the current layout) - in generell the advices of switch-to-buffer and > pop-to-buffer are one of the most important ones currently because > the do all the needed smartness to display the right buffer in the right > window... Did you ever try to tackle these problems with `same-window-regexps' or `same-window-buffer-names'? Though I suppose they are too fuzzy for your purposes. > Redraw the ECB screen according to the layout set in `ecb-layout-name'. How do you get the structure needed for splitting windows into a layout - do you use the `window-tree' function? > After > this function the edit-window is selected which was current before redrawing. > If no-buffer-sync is not nil then the ecb-buffers will not be synchronized. If > ecb-windows-creator is not nil then it will be used to draw the layout instead > of the standard layout. If window-configuration-data is not nil it must be an > object returned by `ecb-window-configuration-data' and will be used for > restoring the layout. Is `ecb-window-configuration-data' based on `current-window-configuration'? In this case you always get edit-area, special windows, and whatever have you in one big pot. Do you trim away windows you don't need then? > If emergency is not nil then all other args will be > ignored and the layout will be redrawn like defined in the current layout and > the edit-area will be unsplitted and will just contain the buffer before the > emergency-redraw. > --- > > Not important, you understand this function but what you see is, there > are some parameter (e.g. NO-ECB-WINDOWS) which determine what should be done. > This is quite long and compley function and what it does is basically: It completely > cleans the whole ECB-frame and then redraws exactly that window-layout which > is needed in the current context. 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). >>I meant "select", for example, using `other-window'. How do you >>select >>the compile-window or the other special ECB-windows when you're in the >>edit-area? > > Ah, now i understand: I simple use `select-window' with right window- > object...the window-object of the compile-window is always stored > in a variable and the dedicated browsing windows are selectable > by buffer-name... ... 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.