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: split-window-preferred-function Date: Sat, 05 Apr 2008 17:42:38 +0200 Message-ID: <47F79DEE.6000806@gmx.at> References: <005d01c89719$de92d340$1f45fe91@j4f3n1> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207411366 3249 80.91.229.12 (5 Apr 2008 16:02:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Apr 2008 16:02:46 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 05 18:03:17 2008 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 1JiArL-0004m6-CK for ged-emacs-devel@m.gmane.org; Sat, 05 Apr 2008 18:03:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JiAqi-0003un-NJ for ged-emacs-devel@m.gmane.org; Sat, 05 Apr 2008 12:02:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JiAqe-0003sK-2C for emacs-devel@gnu.org; Sat, 05 Apr 2008 12:02:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JiAqc-0003nE-4K for emacs-devel@gnu.org; Sat, 05 Apr 2008 12:02:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JiAqb-0003mx-PM for emacs-devel@gnu.org; Sat, 05 Apr 2008 12:02:29 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JiAqb-0000vU-La for emacs-devel@gnu.org; Sat, 05 Apr 2008 12:02:29 -0400 Original-Received: (qmail invoked by alias); 05 Apr 2008 16:02:26 -0000 Original-Received: from 62-47-49-2.adsl.highway.telekom.at (EHLO [62.47.49.2]) [62.47.49.2] by mail.gmx.net (mp023) with SMTP; 05 Apr 2008 18:02:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/HdUJuGVHHxcNdOJnd3/dtl9sbEtHDCNHnPt+h0r vxysPADPOZpMG/ User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <005d01c89719$de92d340$1f45fe91@j4f3n1> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.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:94419 Archived-At: > I don't think that tuning the split-window concept will bring you > any further. Such function is simply too low-level than that it > could do what you want, that is to create new layout on-the-fly. Here we are mostly concerned with using `split-window' for displaying a buffer currently not present on the frame. In particular we are concerned with picking the optimal window to split and the optimal way to split it. While this will get us a new layout I wouldn't call it "creating" a new layout. > So why don't you let the user define the layout and make the code > fill in the options. Where LAYOUT means what (class of) content > shall be shown in what place, and OPTIONS for instance can mean > what do do with space where the content is currently not available. > > Have a look at elscreen. Or think about html div tags, they define > layout that only applies if there is content. IIUC elscreen is useful for switching between existing layouts. Such layouts are obtained by recursively splitting a root window horizontally or vertically. You can record such a layout in volatile memory by calling `current-window-configuration' and you can re-create it from there via `set-window-configuration'. But you cannot (easily) define and subsequently create such a layout manually. Hence elscreen seems hardly of any help in this context. Please correct me if I'm wrong. I can think of two options: 1. Make the underlying window structure accessible in Elisp - via parameters or functions like `window-parent' and `set-window-parent'. This would require careful design of things like `set-window-parent' to avoid introducing incoherent or faulty window layouts via Elisp. 2. Write a collection of functions that recursively tile a root window in some well-defined manner according to rules that humans can easily write, read and understand. Maybe some of these layouts should be depicted in a graphical fashion, for example, in the toolbar (my Thunderbird permits me to choose among three basic tilings).