From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Hori Newsgroups: gmane.emacs.devel Subject: Re: Window configurations (was: Gtk tabs in emacs, new branch) Date: Thu, 29 Apr 2010 20:19:24 -0700 Message-ID: References: <4BB4CF6B.2000007@alice.it> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1272597598 11473 80.91.229.12 (30 Apr 2010 03:19:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Apr 2010 03:19:58 +0000 (UTC) Cc: martin rudalics , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 30 05:19: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 1O7glR-0005z5-3N for ged-emacs-devel@m.gmane.org; Fri, 30 Apr 2010 05:19:55 +0200 Original-Received: from localhost ([127.0.0.1]:35472 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O7glL-0005oE-UO for ged-emacs-devel@m.gmane.org; Thu, 29 Apr 2010 23:19:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O7glG-0005nX-An for emacs-devel@gnu.org; Thu, 29 Apr 2010 23:19:30 -0400 Original-Received: from [140.186.70.92] (port=48187 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O7glE-0005nO-4L for emacs-devel@gnu.org; Thu, 29 Apr 2010 23:19:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O7glC-0007K0-7p for emacs-devel@gnu.org; Thu, 29 Apr 2010 23:19:27 -0400 Original-Received: from mail-pw0-f41.google.com ([209.85.160.41]:41579) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O7glB-0007Jt-IB for emacs-devel@gnu.org; Thu, 29 Apr 2010 23:19:26 -0400 Original-Received: by pwi10 with SMTP id 10so6524401pwi.0 for ; Thu, 29 Apr 2010 20:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gHNAdT3oYZtEUrF3E2snbgXDjF6Sr9BMnCN8c2aCeNs=; b=mvVqUBy2+TfG9BY3grnL0nFfBH0Tx5TYx5IAK1V0H2sTb7F8uZcoVJH7kdjIMcoGlN B58/Ll9jlRRyqSMVEH7LIDGQ+YciFTBY4gZ1pvLWKxaLL5tzsq+56AqhxClL98cr/6Xf utO0pzfSepfcmnPfI+uRKzzM71Zf9H7snFyOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wrcXzK7J/CGvqun6oyCyiG02yIvRHjK7xCYvPGAjYimI+80SnTTSB+jPpnNkxLH4DH +4Z/cE/lw4ujC0IxUAxrDKw4WcXuwSlN4rbTmmsGjhaUgmzx9LTSGazWhD5h54abTOvf r6+I8DQiKoHevguoAAu5PUsPWIa3ymAW3268M= Original-Received: by 10.140.251.11 with SMTP id y11mr328718rvh.279.1272597564521; Thu, 29 Apr 2010 20:19:24 -0700 (PDT) Original-Received: by 10.141.2.15 with HTTP; Thu, 29 Apr 2010 20:19:24 -0700 (PDT) In-Reply-To: <87zl0rtmqy.fsf@mail.jurta.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:124338 Archived-At: Juri, Could we add as an extra `buffer-file-name' alist element in the sexp of a window-configuration or is that a bad idea? (I was just tring to reconstruct a window-configuration after an emacs reboot but quickly found out filenames weren't just there.) On Sun, Apr 25, 2010 at 11:33 AM, Juri Linkov wrote: >>> ... Currently the design >>> is at the stage of deciding what format is better to represent the >>> window configuration. =A0There are two options: a window tree and >>> a plain list of windows. =A0I 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. > > Yes. =A0That's why I added a new argument `live-p' to > `current-window-configuration-to-sexp'. =A0When non-nil, it adds live dat= a > (window objects, buffer objects, markers, etc.) that are necessary > when its Lisp expression will be used in the same session. =A0When nil, > it returns bare minimum necessary to save and restore in another session. > >> EWCs should IMHO strip window configurations to the absolutely needed >> bare minimum. =A0In 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) > > Do you plan to create a branch for your rewrite of window.c? > It would be very interesting to look at it. > >> Coordinates should probably be rather stored as fractions instead of >> absolute lines and columns. =A0This would make it easier to (1) eventual= ly >> 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. > > There are no problems with storing coordinates as absolute lines and > columns. =A0After restoring absolute coordinates `set-window-configuratio= n' > resizes the frame thus keeping original relative sizes unchanged. > >> 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. =A0Note that CWCs don't do this since they nee= d >> to restore the configuration from the stored "coordinates" anyway, but >> the design is a bit awkward as code like >> >> =A0if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) >> >> in `set-window-configuration' shows. > > No, I don't use `split-window'. =A0I use exactly the same algorithm as in > `set-window-configuration', and additionally make new windows. > In my tests, this works correctly. > >> 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. > > Currently `set-window-configuration-from-sexp' works without these > parameters. =A0But maybe they would be useful for user-defined window > configurations. > >> BTW in the earlier example structure you posted here I'm missing entries >> for window-point, window-start, ... =A0Was that intentional? > > There are entries `pointm' and `start' in the output of of the really > working function `current-window-configuration-to-sexp'. > > But the example of the output of `window-configuration-to-sexp' is for > demonstration purposes only. =A0It doesn't work yet, because I'm not sure= yet > whether it's better than `current-window-configuration-to-sexp'. > > -- > Juri Linkov > http://www.jurta.org/emacs/ > > >