From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Tue, 27 Apr 2010 11:54:11 +0300 Organization: JURTA Message-ID: <87d3xlfdd8.fsf@mail.jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1272361992 9261 80.91.229.12 (27 Apr 2010 09:53:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2010 09:53:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 27 11:53:10 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 1O6hTa-0004GF-7m for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 11:53:10 +0200 Original-Received: from localhost ([127.0.0.1]:58261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6hTZ-0003a6-MG for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 05:53:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6hIR-0007X2-3U for emacs-devel@gnu.org; Tue, 27 Apr 2010 05:41:39 -0400 Original-Received: from [140.186.70.92] (port=48936 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6hIM-0007Sy-Cs for emacs-devel@gnu.org; Tue, 27 Apr 2010 05:41:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6hII-0006o4-57 for emacs-devel@gnu.org; Tue, 27 Apr 2010 05:41:34 -0400 Original-Received: from smtp-out1.starman.ee ([85.253.0.3]:60538 helo=mx1.starman.ee) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6hIG-0006nH-Nq for emacs-devel@gnu.org; Tue, 27 Apr 2010 05:41:30 -0400 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Original-Received: from mail.starman.ee (82.131.35.76.cable.starman.ee [82.131.35.76]) by mx1.starman.ee (Postfix) with ESMTP id AF5423F4158; Tue, 27 Apr 2010 12:41:22 +0300 (EEST) In-Reply-To: <4BD5BC62.5070306@gmx.at> (martin rudalics's message of "Mon, 26 Apr 2010 18:16:34 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/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:124240 Archived-At: > By no means I want to talk you out of this ;-) but `split-window' is a > socially well-established function. Saved window configurations will > hardly ever get used that much. And we'll already have a hard time to > maintain compatibility, for example, when you want to restore a > configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa). I agree that when designing this feature, we should think about the future. Let's imagine that Emacs 27 will switch from the tiling window manager to an overlapping window manager. Then `split-window' in window configurations will make no sense. 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. > Users "define" window configurations by splitting and deleting windows. > They have no idea of the underlying window tree. But if you don't use > `split-window' storing the type of window combinations doesn't make > sense anyway. It's just that current window configurations have lots of > redundancy: For a vertical combination, the widths of all subwindows are > the same as that of the parent window, top-lines can be calculated on > the fly by adding the top-line of the left sibling to its height, ... 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. 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. > Anyway, the greatest problem IMO is to get windows correlate with their > buffers. I don't think that restoring ediff configurations will become > ever feasible (unless you build this into the ediff code) 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. > and I'm also pessimistic about Info buffers 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? > And obviously we'll fail to handle code based on window objects > or overlays with a window property. 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. > But for merely "normal" buffers the integrity of buffer-local variables > affecting size and appearance of windows displaying them must be > preserved. For example, when a buffer has `window-size-fixed' non-nil, > any frame resizing step in your `set-window-configuration' should keep > the size of the window fixed. It seems the frame resizing step in `set-window-configuration' already keeps the size of the window fixed. -- Juri Linkov http://www.jurta.org/emacs/