From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pascal Bourguignon Newsgroups: gmane.emacs.help Subject: Re: New balance-windows Date: Sun, 07 Aug 2005 22:42:31 +0200 Organization: Informatimago Message-ID: <878xzdtr60.fsf@thalassa.informatimago.com> References: <87pssv3kai.fsf@thalassa.informatimago.com> <1123035204.009217.187300@g14g2000cwa.googlegroups.com> <87fytr3ea2.fsf@thalassa.informatimago.com> <87vf2juij1.fsf@thalassa.informatimago.com> <878xzevlop.fsf@thalassa.informatimago.com> <87mznttxl9.fsf@thalassa.informatimago.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1123447698 16480 80.91.229.2 (7 Aug 2005 20:48:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2005 20:48:18 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Aug 07 22:48:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E1s39-0002GV-MZ for geh-help-gnu-emacs@m.gmane.org; Sun, 07 Aug 2005 22:47:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E1s67-0002Xh-Qn for geh-help-gnu-emacs@m.gmane.org; Sun, 07 Aug 2005 16:50:19 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!colt.net!easynet-quince!easynet.net!easynet-post2!not-for-mail Original-Newsgroups: gnu.emacs.help Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:KBdWEzyaNnwa7D+bhnS939Umb14= Original-Lines: 56 Original-NNTP-Posting-Host: 62.93.174.79 Original-X-Trace: DXC=ebeaekJO@I_E0f4FL\EY<>`XO4V7]>Uh List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:28526 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:28526 Lennart Borgman writes: > Pascal Bourguignon wrote: > >>>>File: elisp, Node: Window Internals >>>> >>>> >>>> >>>Thanks, I did not know this was available. Then the windows in each >>>frame can be seen as a tree using those fields you mentioned. But what >>>should then be done with this? What should the mapping between this >>>tree and the visual view be? It looks to me that the level in the tree >>>alone will not give any useful hint. The topology (ie whether the >>>splitting was horizontal or vertical) must be taken into account, but >>>maybe the level in the tree can be used too? It actually looks a bit >>>difficult... >>> >>> >> >>Well, it's only available to the C programmer... >> >> > I noticed when I tried to implement the algorithm I suggested. However > it should be possible to find the split tree with a bit of work. It > may fail when window borders meat each like a + so to say, but maybe > trying to change the window sizes can resolve such cases. So I was > wrong I think. It is not absolutely necessary to have the access to > those hchild etc. > > I guess you are counting the children in each sub tree (something > similar to what I suggested though you may not have read that)? Maybe > it should be good with some weights for a user to customize? > > Finding the split tree is a bit tricky to say the least. You have to > imagine a split tree and start to pick up the windows from the leafs > and work upwards. Maybe thinking in sets helps? There are certain > cases where you can not know how the split tree actually was (like > three windows above each other), but from a user perspective those are > perhaps better handled as a node with three childs whether that is the > case in the internal split tree or not. (Perhaps this shows that it is > better not to use the internal split tree?) Indeed, the + case can be distinguished enlarging one window, | getting either __|-- or -+-+-, or still +, and checking for | changes in the other windows. So it's possible to recover the split tree from the window list. -- "You cannot really appreciate Dilbert unless you read it in the original Klingon"