From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Thu, 13 May 2010 15:53:28 +0200 Message-ID: <4BEC0458.8050600@gmx.at> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@gmx.de> <4BEA74B7.2070609@gmx.at> <4BEA8D2D.4090109@gmx.de> <4BEAA73F.4060608@gmx.at> <4BEAF487.1070605@gmx.de> <4BEBD2E3.8020200@gmx.at> <4BEBE52D.5080102@gmx.de> 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 1273758978 24493 80.91.229.12 (13 May 2010 13:56:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 May 2010 13:56:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 13 15:56:15 2010 connect(): No such file or directory 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 1OCYta-00061x-CS for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 15:56:14 +0200 Original-Received: from localhost ([127.0.0.1]:59289 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCYtZ-0004pB-S6 for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 09:56:13 -0400 Original-Received: from [140.186.70.92] (port=55386 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCYqz-0003SG-3e for emacs-devel@gnu.org; Thu, 13 May 2010 09:53:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCYqx-0001F3-J6 for emacs-devel@gnu.org; Thu, 13 May 2010 09:53:32 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:53630) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCYqx-0001EZ-89 for emacs-devel@gnu.org; Thu, 13 May 2010 09:53:31 -0400 Original-Received: (qmail invoked by alias); 13 May 2010 13:53:28 -0000 Original-Received: from 62-47-53-1.adsl.highway.telekom.at (EHLO [62.47.53.1]) [62.47.53.1] by mail.gmx.net (mp061) with SMTP; 13 May 2010 15:53:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18L2wcOF9oLxykfatskZviy6UP5jlK1p6+rDt4QZM 0g34yRT41oP02T User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4BEBE52D.5080102@gmx.de> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:124743 Archived-At: > I remember that differently. With ECB you can really choose from layouts > visually and even create new ones with a sort of interactive layout editor. > It is true that it stored the layouts as procedural sequences internally, > but that is just an implementation detail. I was talking about practical issues, i.e., implementation. > Aside from that it is really trivial to specify any reasonably complex > layouts as simple lisp structure, with sizes in percent, similar to say > framesets in html: > > (setq my-layout '( And we'd get this structure from `window-tree', I suppose? Things like that have been proposed and written a number of times already. > That simple thing would be a pretty detailed layout already suited for > almost all purposes (except GUD perhaps). More precisely, a layout > _configuration_, which means that the elements (windows) are shown only > when needed. > > Now you'd have a function that processes the tree to remove the unshown > components, resizes the remaining components proportionally and then put > it on screen in one go using good old split-window and then shows the > buffers That's what XEmacs does IIUC ... > on top of each window's buffer stack. ... just that it has no such stack. > For that of course you need a second set of preferences, that is what > buffer show in what pane: For example, *messages*, *compilation*, > *completion*, etc. can be assigned to "tool-window", *speedbar* to > sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ... That's what ECB's layouts are supposed to accomplish. But I still don't know how we want to use a window's buffer stack. It's probably trivial when the only operation popping the stack also kills that buffer. However, if the buffer remains alive where put it on the stack? The only reasonable answer is burying it. But usually that buffer is the one a user most likely wants to see first when unshowing another buffer in that window. martin