GNU bug report logs - #10348
24.0.92; Save and load window states

Previous Next

Full log

Message #95 received at 10348 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Michael Bach <phaebz <at> gmail.com>, 10348 <at> debbugs.gnu.org
Subject: Re: bug#10348: 24.0.92; Save and load window states
Date: Wed, 28 Dec 2011 18:09:44 -0500

>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.