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: moving window handling into lisp Date: Mon, 27 Jul 2009 15:37:24 +0200 Message-ID: <4A6DAD94.8040006@gmx.at> References: 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 1248701870 25186 80.91.229.12 (27 Jul 2009 13:37:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 13:37:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 15:37:43 2009 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 1MVQOa-0005ca-3T for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 15:37:40 +0200 Original-Received: from localhost ([127.0.0.1]:42934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVQOZ-0004IJ-Ca for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 09:37:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVQOT-0004Hd-If for emacs-devel@gnu.org; Mon, 27 Jul 2009 09:37:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVQOO-0004Eb-Hj for emacs-devel@gnu.org; Mon, 27 Jul 2009 09:37:32 -0400 Original-Received: from [199.232.76.173] (port=48244 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVQOO-0004EW-Db for emacs-devel@gnu.org; Mon, 27 Jul 2009 09:37:28 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:34374) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MVQON-0000ko-Q7 for emacs-devel@gnu.org; Mon, 27 Jul 2009 09:37:28 -0400 Original-Received: (qmail invoked by alias); 27 Jul 2009 13:37:25 -0000 Original-Received: from 62-47-46-195.adsl.highway.telekom.at (EHLO [62.47.46.195]) [62.47.46.195] by mail.gmx.net (mp011) with SMTP; 27 Jul 2009 15:37:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/KN04dOE7KEynSTmvVjwkJJYDsgn8KkiVUHar9KK biaZpAyTZcs+Na User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 X-detected-operating-system: by monty-python.gnu.org: GNU/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:113213 Archived-At: > Basically keep the same window objects we have today, but allow lisp > to get a handle on non-leaf window objects (today, AFAICT, lisp can > only ever see leaf windows). Elisp can "see" all internal windows. Making internal windows more accessible was the idea underlying my proposal. > window-children WINDOW => (LEFT-CHILD-WIN . RIGHT-CHILD-WIN) An internal window can have more than two children (for no good reason, BTW). > window-parent WINDOW => PARENT-WIN > set-window-children WINDOW LEFT-CHILD-WIN RIGHT-CHILD-WIN `window-parent' and `window-children' would be trivial. Providing `set-window-children' is hardly feasible IMHO. Who'd be responsible for calculating the respective sizes? > (etc) > > A brief look suggests that much of the traditional window handling > code (`window-list', `other-window', `split-window', `delete-window', > `delete-other-windows', etc) could then be moved into lisp; none of > that code looks very complicated or dangerous. The problem with `split-window' and `delete-window' is that you can easily mess up things when you create windows that don't have the right size. From my experience this usually makes Emacs crash pretty soon and we shouldn't allow Elisp code crash Emacs. OTOH doing all the necessary checks wrt window sizes in `set-window-children' would mean hard work. It would be fine to see such code though since we could use it to safely store window configurations on disk in a non-procedural manner. martin, whose `switch-to-buffer' is in window.el