From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "grischka" Newsgroups: gmane.emacs.devel Subject: Re: split-window-preferred-function Date: Sat, 5 Apr 2008 20:35:31 +0200 Message-ID: <010001c8974b$da82b680$130990d4@j4f3n1> References: <005d01c89719$de92d340$1f45fe91@j4f3n1> <47F79DEE.6000806@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207420592 31423 80.91.229.12 (5 Apr 2008 18:36:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Apr 2008 18:36:32 +0000 (UTC) To: , "martin rudalics" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 05 20:37:04 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 1JiDG9-0002at-Jj for ged-emacs-devel@m.gmane.org; Sat, 05 Apr 2008 20:37:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JiDFW-0003n6-IO for ged-emacs-devel@m.gmane.org; Sat, 05 Apr 2008 14:36:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JiDFS-0003mo-7o for emacs-devel@gnu.org; Sat, 05 Apr 2008 14:36:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JiDFP-0003mb-Mo for emacs-devel@gnu.org; Sat, 05 Apr 2008 14:36:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JiDFP-0003mY-Im for emacs-devel@gnu.org; Sat, 05 Apr 2008 14:36:15 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JiDFP-0002zz-42 for emacs-devel@gnu.org; Sat, 05 Apr 2008 14:36:15 -0400 Original-Received: (qmail invoked by alias); 05 Apr 2008 18:36:13 -0000 Original-Received: from dialin-212-144-009-019.pools.arcor-ip.net (EHLO j4f3n1) [212.144.9.19] by mail.gmx.net (mp051) with SMTP; 05 Apr 2008 20:36:13 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+3QR1X4OC3+VoQ9qvR0VIaf4LBprhK2qnFxyj0Xa 3kaU/ASx45qn87 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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:94427 Archived-At: From: "martin rudalics": > 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. Actually elscreen has a separate "layout creation" mode (although it is not as easy to use, and also IMO redundant, it could as well just live record user changes made in the "real" frame). But yes, you can save everything to disk, anytime. Means it allows to get used to something, body-language wise. > 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). Option three: Allow zero-width and zero-height windows. For example: +---+-----------+ | | | | | | | | | | | | | | | | | | <-- | | | | | | +===+===========+ As you don't see there is a zero-height window at bottom, which when "on" spans up to the arrow, but is invisible by default. Such there is actually no need for the code to *ever* create new windows automatically, because the "tree" is already either predefined and/or customized. Just the sizes aren't filled in always. All windows would have some target class-properties, like "file", "help", "commandline", so if some buffer needs to be shown, the buffer/window-manager (which of I assume emacs has one) can apply some logic which buffer to show in what window. For example: (window :name "bottom-display" :content-classes '("*help*" "*output*" ...) ... :visible 'if-needed Still the user is allowed to modify the tree anytime of course, by split-window or whatever. Just not the code. --- grischka