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: Gtk tabs in emacs, new branch Date: Sun, 25 Apr 2010 11:15:13 +0200 Message-ID: <4BD40821.70808@gmx.at> References: <4BB4CF6B.2000007@alice.it> <4BB5C01E.10701@alice.it> <4BB608EE.7080101@swipnet.se> <4BB9A469.6050608@alice.it> <4BC072C3.2080302@swipnet.se> <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> 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 1272186937 6594 80.91.229.12 (25 Apr 2010 09:15:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 25 Apr 2010 09:15:37 +0000 (UTC) Cc: 'Emacs' To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 25 11:15:34 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 1O5xw4-0006OV-PG for ged-emacs-devel@m.gmane.org; Sun, 25 Apr 2010 11:15:33 +0200 Original-Received: from localhost ([127.0.0.1]:60307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5xw3-00024w-Ny for ged-emacs-devel@m.gmane.org; Sun, 25 Apr 2010 05:15:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5xvu-00024C-EC for emacs-devel@gnu.org; Sun, 25 Apr 2010 05:15:22 -0400 Original-Received: from [140.186.70.92] (port=47290 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5xvs-00023a-Ca for emacs-devel@gnu.org; Sun, 25 Apr 2010 05:15:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5xvq-00057i-MS for emacs-devel@gnu.org; Sun, 25 Apr 2010 05:15:20 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:36573) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O5xvq-00057J-AE for emacs-devel@gnu.org; Sun, 25 Apr 2010 05:15:18 -0400 Original-Received: (qmail invoked by alias); 25 Apr 2010 09:15:14 -0000 Original-Received: from 62-47-34-186.adsl.highway.telekom.at (EHLO [62.47.34.186]) [62.47.34.186] by mail.gmx.net (mp014) with SMTP; 25 Apr 2010 11:15:14 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+A7uAA6d+A8m55kJACwKtFUhHJwTY2CQKR03Wrv/ 2FsRxKb86iNPY/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87r5m4hz39.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.60999999999999999 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:124191 Archived-At: > ... Currently the design > is at the stage of deciding what format is better to represent the > window configuration. There are two options: a window tree and > a plain list of windows. I am inclined to the second option > since when saved it would be more compact. There's absolutely no need to make window configurations saved by `current-window-configuration' (I call them CWCs here) and window configurations saved for later reconstruction in a possibly different session (called EWCs) save the same states of things. CWCs are needed to restore the appearance of a frame after a short excursion or because some error occurred. They are heavily overused in that respect (for example, every time you drag a window's modeline with the mouse up or down by one line, Emacs saves and discards the current window configuration twice) but certain aspects might be needed to keep the appearance coherent like, for example, `hscroll' related entries. EWCs should IMHO strip window configurations to the absolutely needed bare minimum. In particular `orig-top-line' and `orig-total-lines' do more harm than good in EWCs (BTW, I've completely done away with these in my rewrite of window.c) as all other minibuffer related information. Also hscroll and min-hscroll should not be stored. Whether margin, fringe and scrollbar information should be stored in EWCs depends on whether the appropriate settings for frames and the buffer local values are stored and orderly processed as well - otherwise they make few sense. I'm afraid we'd have to store/restore all of them, although I'm also quite sure that hardly anyone could tell how their final appearance on screen is determined. Coordinates should probably be rather stored as fractions instead of absolute lines and columns. This would make it easier to (1) eventually switch to pixel based coordinates and (2) put an EWC into an Emacs window (that is, put an Emacs frame into an Emacs window) as some IDE advocats mentioned earlier. Since I suppose you're running `split-window' to restore configurations you'd probably also want to remember whether a "split" was a vertical or a horizontal one in EWCs. Note that CWCs don't do this since they need to restore the configuration from the stored "coordinates" anyway, but the design is a bit awkward as code like if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) in `set-window-configuration' shows. That said, the *entire* coordinate information of a particular window in an EWC would consist of (1) whether it is a horizontal or a vertical combination and (2) the proportional space - either a float or the fraction of "some largest integer" - occupied by the window wrt to its parent window. Anything else would be pure overkill. BTW in the earlier example structure you posted here I'm missing entries for window-point, window-start, ... Was that intentional? martin