bug#10348: 24.0.92; Save and load window states

[martin rudalics]

>> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>>     This will not solve the more general problem mentioned above.
>
> As mentioned, it's not a really convincing solution.

It would allow us to silently ignore this problem until 24.2.  And it
would obviously allow Michael to go on with his work.  His feedback
would be overly welcome here.

>> (3) Save only parameters whose value have a read syntax.  This can be
>>     done either in `window-state-get' or in `my-save-frame'.
>
> This can make the save&restore work and fail in somewhat
> unpredictable ways.  Too magical.

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.

>> (4) Convert parameter values to something with a read syntax.  Basically
>>     this is what we already do with buffers (using the name of the
>>     buffer instead of the buffer object) and can be easily done with
>>     windows (save the window number instead of the window object).
>
> This would be a good change, especially if by "window number" you mean
> a number meaningful in an output file rather than only in the current
> session (see Juri's example)

... exactly (and that won't be easy since `window-state-put' could be
called at any time in a new session and not only before the first window
is created in that session).

> but it doesn't fix all cases.

I'm afraid so.

>> (5) Make functions like `my-load-frame' aware that components of saved
>>     window states might not have a read syntax and have them take the
>>     appropriate action.
>
> This is like (3) except the magic is done elsewhere.

Yes.  Just that (3) seems better.

>> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
>> try to propose a combination of (3) and (4) for later releases.
>
> I think the best course of action is to only save the window
> parameters listed in some variable (window-state-saved-parameters?).

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

> Adding some of (4) would be a good additional refinement.

If it can be reasonably done.

> Actually, it might even be good to filter which params to keep not just
> when saving but already when constructing the window-state object (some
> params may simply not belong in a window-state object because restoring
> them would make no sense).

Agreed.

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

martin