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: read syntax for window configs Date: Fri, 19 Mar 2010 14:07:32 +0100 Message-ID: <4BA37714.4030207@gmx.at> References: <86bpf7q3fc.wl%lluis@ginnungagap.pc.ac.upc.edu> <87wrxvyijr.fsf@stupidchicken.com> <4B8C42E2.3080308@siege-engine.com> <7697A57B1AD9104F993CDF6A5B69430C09227D1F24@CORPMAIL08.corp.capgemini.com> <878wabxg0x.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxyrhxq8.fsf@lola.goethe.zz> <7697A57B1AD9104F993CDF6A5B69430C09227D1FCE@CORPMAIL08.corp.capgemini.com> <7697A57B1AD9104F993CDF6A5B69430C09227D1FF5@CORPMAIL08.corp.capgemini.com> <87wrxu79r6.fsf@mail.jurta.org> <87wrxuw0pd.fsf@uwakimon.sk.tsukuba.ac.jp> <86716EEF25B64190B631AD85710E965D@us.oracle.com> <4BA35681.4030005@gmx.at> 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: dough.gmane.org 1269004078 31528 80.91.229.12 (19 Mar 2010 13:07:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 19 Mar 2010 13:07:58 +0000 (UTC) Cc: mike@xemacs.org, emacs-devel@gnu.org To: Michael Sperber Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 19 14:07:52 2010 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 1NsbvY-0005lP-Kv for ged-emacs-devel@m.gmane.org; Fri, 19 Mar 2010 14:07:48 +0100 Original-Received: from localhost ([127.0.0.1]:54467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsbvX-0003eZ-SI for ged-emacs-devel@m.gmane.org; Fri, 19 Mar 2010 09:07:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NsbvP-0003dp-R5 for emacs-devel@gnu.org; Fri, 19 Mar 2010 09:07:39 -0400 Original-Received: from [140.186.70.92] (port=33362 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsbvN-0003de-F4 for emacs-devel@gnu.org; Fri, 19 Mar 2010 09:07:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NsbvL-0005TZ-Fu for emacs-devel@gnu.org; Fri, 19 Mar 2010 09:07:37 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:52431) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NsbvL-0005TI-4o for emacs-devel@gnu.org; Fri, 19 Mar 2010 09:07:35 -0400 Original-Received: (qmail invoked by alias); 19 Mar 2010 13:07:33 -0000 Original-Received: from 62-47-38-28.adsl.highway.telekom.at (EHLO [62.47.38.28]) [62.47.38.28] by mail.gmx.net (mp048) with SMTP; 19 Mar 2010 14:07:33 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19LUgMiuMVL0tX9tiKq41NLQN39RKysi22+2Pujid /zn5ItpKqcsxfy User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56000000000000005 X-detected-operating-system: by eggs.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:122274 Archived-At: >> Thank you for posting this. It won't work out of the box for Emacs >> because Emacs lacks `make-window-configuration' and `make-saved-window'. >> Can you post their definitions here or tell us a page on the net where >> we can look at them? > > http://hg.debian.org/hg/xemacs/xemacs/file/45753d9a0dc4/lisp/window-xemacs.el Sorry but this has only a call to `make-window-configuration' in `current-window-configuration'. I've been looking into window.c but didn't find it there either :-( I suppose it simply builds a vector from its arguments. >> Do they check a configuration for integrity (e.g., whether the >> combined window sizes match those of their parents, that of the root >> window the size of the frame, ...) before mapping the frame? > > Yes: Since all restoration happens from Lisp, there's no way to get > anything inconsistent. Well, if something happens in Elisp there's always a chance that things get messed up on the fly. I'd very much prefer to do the elementary checks (those that prevent Emacs from crashing or showing distorted frames) only in C. >> Can you restore on machine A a configuration saved on machine B when A >> and B have different toolkits? > > I don't see why not. You're not always going to get an > identical-looking configurations because the original frame will be > gone, but as close an approximation as the code knows how to recreate. OK. So I presume your code handles the case where window sizes don't fit because, for example, toolbars or scrollbars have different widths. >> Also, am I right that the `next-child' field denotes the right sibling >> of the window? > > If I recall correctly, it depends on whether windows are going right or > down. It's just whatever `window-next-child' returns on XEmacs. I've checked that. It _is_ the right sibling and it doesn't depend on whether windows go right or down (obviously, when windows go down the right sibling denotes the window below). >> And, how do you translate back from pixel values (like `pixel-left' >> ... ) to normal line/column values? Do you? > > No, we don't. That's good (but momentarily not suitable for Emacs). You apparently do all these calculations via window_pixel_height_to_char_height / window_char_height_to_pixel_height and friends. And it will allow to fix any of the scroll- or toolbar problems I mentioned above by giving the remaining pixels to one of the involved windows. Emacs should eventually do something similar ;-) > I don't know anything about ECB, so I don't really know. However, I > would think that it needs to remember the name of the buffer to find the > window, or remember the window's place in the layout. (That's a general > issue with window configurations, but it becomes very clear here - > there's no way to preserve window identity across sessions.) Funnily, nothing would prevent us from keeping window identities across sessions. If and only if a saved configuration is restored _before_ the first user interaction. Well we could check whether a window with such an identity exists already but I wouldn't like that ... Thanks again, martin