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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Bach <phaebz <at> gmail.com>, 10348 <at> debbugs.gnu.org
Subject: bug#10348: 24.0.92; Save and load window states
Date: Sat, 24 Dec 2011 10:27:30 +0100

> No, it would address this particular bug-report, but similar problems
> may reappear at any time.

Yes.  Someone could do (set-window-dedicated-p nil (selected-window)).

>> IIUC this is what desktop does.  The problem is rather that we would
>> have to distinguish between values needed for intra-session purposes and
>> those that make sense for inter-session purposes too.
>
> I'm not sure distinguishing the two is needed (especially for
> window-state-*).

So your proposed `window-state-saved-parameters' would never save and
restore a thing like the "clone-of" parameter?

>> You mean that anyone who misuses that variable (by including, for
>> example, a parameter that actually stores a window object as value)
>> would be on her own?
>
> I don't see any harm in it.

Any application setting a window parameter to some non-standard value
would be held responsible for this.  Fine with me, but ...

>> Doesn't look so attractive to me since the effect will only be seen in
>> a new session, some time after the problematic save happened.
>
> Not if we make this variable specify which parameters to include in
> window-states, rather than only which parameters to write to a file.
> Or maybe I don't understand the problem you're referring to.

The window-state-* functions are primarily intended for inter-session
use.  So if we can save a bad value, the bug will be usually detected
when it's too late.

>>> After all the window-configurations don't save&restore
>>> window parameters.
>> Currently they do (unless you modify them destructively).  Otherwise,
>> side windows and atomic windows won't work.
>
> Oh, I see that's another change in Emacs-24.  It's actually problematic
> because set-window-parameter does operate destructively,

`set-window-parameter' is harmless.  The problem occurs only if you
modify a window parameter's value destructively.

> so it makes the
> semantics rather irregular.

It's precisely the same as for the dedicated status of a window.

martin

Previous Next

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