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: Window configurations Date: Tue, 27 Apr 2010 14:54:13 +0200 Message-ID: <4BD6DE75.4060306@gmx.at> References: <4BB4CF6B.2000007@alice.it> <4BC0B692.2000702@alice.it> <4BC0BD6D.3060103@swipnet.se> <4BC0F715.2060605@alice.it> <45EB8DD4-B0F8-4FB3-941F-13FADA4DAD66@swipnet.se> <4BC1854B.2060409@alice.it> <4BC1A9D2.8050607@swipnet.se> <4BC206C0.2010202@alice.it> <87fx2pdvfq.fsf@mail.jurta.org> <87y6gg95ad.fsf@mail.jurta.org> <750140A47B7D4FBD93371813D65478F8@us.oracle.com> <87eii63v4j.fsf@mail.jurta.org> <0840B3F4D9E84706874EDD2CA2CC4236@us.oracle.com> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <4BD5BC62.5070306@gmx.at> <87d3xlfdd8.fsf@mail.jurta.org> 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 1272374637 25157 80.91.229.12 (27 Apr 2010 13:23:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2010 13:23:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 27 15:23:56 2010 connect(): No such file or directory 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 1O6klH-0000Jh-Mw for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 15:23:53 +0200 Original-Received: from localhost ([127.0.0.1]:42666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6klB-0003VO-65 for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 09:23:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6kIw-00042W-W1 for emacs-devel@gnu.org; Tue, 27 Apr 2010 08:54:23 -0400 Original-Received: from [140.186.70.92] (port=50255 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6kIu-00041M-Tr for emacs-devel@gnu.org; Tue, 27 Apr 2010 08:54:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6kIt-00063P-2K for emacs-devel@gnu.org; Tue, 27 Apr 2010 08:54:20 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:52145) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O6kIs-00063D-Nb for emacs-devel@gnu.org; Tue, 27 Apr 2010 08:54:19 -0400 Original-Received: (qmail invoked by alias); 27 Apr 2010 12:54:15 -0000 Original-Received: from 62-47-61-172.adsl.highway.telekom.at (EHLO [62.47.61.172]) [62.47.61.172] by mail.gmx.net (mp057) with SMTP; 27 Apr 2010 14:54:15 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19pefgUAtZpMYadh2eYr1sBeePz2EOGaF0TBtdTeC Q59hMC/he+fxlE User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87d3xlfdd8.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64000000000000001 X-detected-operating-system: by eggs.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:124245 Archived-At: > This suggests that for the generality > window configurations should be defined as a list of windows with their > parameters, i.e. very much like frames are defined now. Frame parameters > to define the frame geometry are `left', `top', `height', and `width'. > Window parameters to define the window geometry are `left-col', `top-line', > `total-lines', and `total-cols'. Perhaps, in an overlapping window manager > they should be in pixels. Sounds reasonable. If we apply this idea today, the restore-from-sexp step would decide how to rebuild the window tree from these geometry parameters - that means how to nest windows into each others. > Yes, currently window coordinates are redundant because of the > limitations of the tiling window manager. So we have to find a minimal > set of window parameters to define the window location. I agree that > a window tree is an implementation detail and users have no idea of the > underlying window tree. Some window managers are tiling window managers, even Windows XP has one built in. So even if Emacs permits overlapping windows it will probably still offer tiled frames too. > Another variant is to define window geometry relative to the neighbor > windows, e.g. `left-window', `right-window' in terms of the package > windmove.el. Such window configurations would be easy to define for users. Hmm ... windmove never helped me that much. I rewrote the core function for my own purposes because there are windows I never want to select interactively but the window behind such an unselectable one (or on the left or right of it) is the window I really want. > I see no problems with window-to-buffer relations. They can be defined > using buffer names. This works successfully with desktop.el from the > x-tabs branch by saving and restoring window configurations in the > desktop file. I have one buffer type which gets killed as soon as it's not shown in any window. Another one gets its name from the name of the window it's shown in. But I admit that in most cases the problematic issue is not the buffer itself but the major or minor mode a window's buffer is in. I suppose the solution is to (1) make the mode take care of saving the relevant information and (2) untie buffer and window management in some way. How this would work for edebug, GDB, or diff sessions is currently beyond my imagination. Note that all I'm concerned here is that we now should probably fix the order in which the restoring steps are perfomed and what impact that has on restoring window configurations. Whether and how modes can be fully restored would be left to their designers. > Window configurations with Info buffers are saved and restored > successfully in the desktop file as well. >> - in particular cloned ones. > > What problems do you see with cloned Info buffers? I never looked into this but I'm surprised that Info buffer would work out of the box. Do help buffers work well too? > Maybe a package that uses window overlays should use a new hook > to restore window overlays after a new window is created from > a window configuration. I recall that Lennart tried to do that. Currently, overlays can be a mess after reverting a buffer so I think there are more important things to do first. Maybe we could try to handle this by giving windows fairly unique print names. > It seems the frame resizing step in `set-window-configuration' already > keeps the size of the window fixed. Probably at the expense of deleting windows when the frame gets too small. But my point was only that we have to process buffer-local variables _before_ resizing frames. martin