From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#10348: 24.0.92; Save and load window states Date: Wed, 28 Dec 2011 18:09:44 -0500 Message-ID: References: <4ef24371.94110e0a.6fbb.ffffc8f3@mx.google.com> <4EF36318.6000006@gmx.at> <4EF45888.3030204@gmx.at> <4EF59B02.9060608@gmx.at> <4EF72BE9.60604@gmx.at> <4EF8557A.3020001@gmx.at> <4EF8BC0B.6020805@gmx.at> <4EFB3C66.6040104@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325151924 3502 80.91.229.12 (29 Dec 2011 09:45:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Dec 2011 09:45:24 +0000 (UTC) Cc: Michael Bach , 10348@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 29 10:45:19 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RgCY3-0004dZ-49 for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2011 10:45:19 +0100 Original-Received: from localhost ([::1]:56167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgCY1-0000lU-QU for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2011 04:45:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:51339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgCXy-0000lN-QS for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 04:45:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgCXx-0002Ol-N1 for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 04:45:14 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgCXx-0002Oh-LT for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 04:45:13 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RgCag-00040g-7Q for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 04:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Dec 2011 09:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10348 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10348-submit@debbugs.gnu.org id=B10348.132515206615393 (code B ref 10348); Thu, 29 Dec 2011 09:48:01 +0000 Original-Received: (at 10348) by debbugs.gnu.org; 29 Dec 2011 09:47:46 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgCaQ-00040E-Be for submit@debbugs.gnu.org; Thu, 29 Dec 2011 04:47:46 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgCaN-0003zs-Fr for 10348@debbugs.gnu.org; Thu, 29 Dec 2011 04:47:44 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pBT9imIu018973; Thu, 29 Dec 2011 04:44:50 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id E9F9466416; Wed, 28 Dec 2011 18:09:44 -0500 (EST) In-Reply-To: <4EFB3C66.6040104@gmx.at> (martin rudalics's message of "Wed, 28 Dec 2011 16:57:26 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4085=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4085> : streams <714826> : uri <1036800> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 29 Dec 2011 04:48:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:55265 Archived-At: >> And of course the parameters preserved intra-session is a superset of >> the parameters preserved inter-sessions. > I'm not so sure. Maybe a parameter is useful intra-session but not > readable from disk. I don't understand: you first seem to say you disagree with me, but then what you say afterwards seems to agree with me. >> Using window-state-ignored-parameters to specify the difference between >> the two sets seems OK. > You mean that any value present in `window-state-ignored-parameters' > would have to be a member of the `window-persistent-parameters' I used > in my patch? Not necessarily, but an element in window-state-ignored-parameters which is not in window-persistent-parameters would have no effect. > I'd rather not care about `window-state-ignored-parameters' in > `current-window-configuration' or `set-window-configuration'. That's OK, window-configurations are intra-session objects anyway, so if window-state-ignored-parameters specifies the difference between the two sets, it indeed can be ignored by `current-window-configuration' and `set-window-configuration'. > (BTW, I use `window-persistent-parameters' instead of > `window-state-saved-parameters' because they apply to both, > `current-window-configuration` and `window-state-get'.) Yes, the name sounds fine. >> An alternative would be to ignore window-state-saved-parameters (and >> window-state-ignored-parameters) > So far, I didn't care about `window-state-ignored-parameters' when > restoring a state in `window-state-put'. Fine. >> upon restore. Instead, we'd save the parameters in a list where each >> element is either (PARM . VAL) or just PARM where the second form >> indicates that PARM was not set and should hence be unset upon restore. > Fine with me. Obviously, this makes saved states a bit larger. Indeed, but otherwise, as you pointed out, it makes the semantics rather tricky if window-persistent-parameters is changed between the save and the restore (which is something that is very likely to happen sometimes since the restore may happen years after the save). Stefan