bug#10348: 24.0.92; Save and load window states

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Yup.

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

Not quite "never", but at least not before we manage to serialize its value.

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

That's right.  We should probably try to make the code a bit more robust
so that the "invalid read syntax" error gets turned into a warning.

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

I can't see any scenario where such errors could really be detected earlier.

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

I must be missing something: set-window-parameter does "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.

Is it?
The irregularity I'm referring to, is that set-window-configuration will
remove parameters that were added since the save, but will not undo the
changes to the parameters that were modified since the save.


        Stefan