Re: [Emacs-diffs] /srv/bzr/emacs/trunk r106873: Provide persistent window parameters.

[martin rudalics]

> Ah, right so there are 4 different cases, where the 4th is when the
> entry is not on the alist at all.

Precisely.

> Is it really important to ignore clone-of for window-configuration?
> When is clone-of used currently,

Currently it's not used in practice and I earlier proposed to remove it.

Initially, `clone-of' was meant to provide the following:

(1) Save a frame's state giving each window in the saved state a
    `clone-of' reference to the window it was cloned from.

(2) Delete the original frame.

(3) Restore the saved state in a new frame.  In that new frame the
    `clone-of' parameter can be used to simulate the original window
    identities, e.g., for handling overlays with window properties.
    This means that you could continue to work with a frame "as usual"
    even if that frame had been intermittently deleted.

> and what would be the impact of
> saving&restoring it via window-configuration?

In its current version `current-window-configuration' ignores `clone-of'
since its `window-persistent-parameters' value is `state'.  If this
value were t, `current-window-configuration' would have to make a copy
of the `clone-of' parameter for each window.  A subsequential
`set-window-configuration' would usually notice that the parameter has
not changed and skip it.  From an efficiency's POV I don't care about
that extra consing.  But it strikes me as ugly doing conses that are
guaranteed to never serve any purpose.

>>     `nil'
>>           This value specifies that the parameter is saved by
>>           `current-window-configuration' and, provided its IGNORE
>>           argument is `nil', by `window-state-get'.
>
>> This is the "only save for intra-session restore because it can't be
>> saved to disk" type.
>
> I didn't even read the text, assuming that nil meant "never save".

Maybe nil is a bad value here?  I used it because it's in some sense the
standard value for most applications that don't care about saving the
value to disk.

>> But maybe I'm missing something.  Is the documentation that bad?
>
> No it's just fairly complicated since there are 3 different
> save&restore: window-state with ignore=nil, window-state with
> ignore!=nil, and window-configuration.
> If we could bring it down to 2 (ignore=nil, and ignore=non-nil which
> also applies to window-configuration), it would be much better.

You probably mean that window-configuration should be handled like
ignore=nil.  As I mentioned earlier configurations and states differ in
one fundamental aspect:

Configurations protect and revive windows.  This means that those
parameters the windows had at the time of saving the configuration and
that remained unchanged after that are still around since the window
can't be collected due to the window slot in saved_window (I hope my
interpretation is correct this time).

States clone windows.  This means that usually the clone is set up
without any parameters.  Usually, this is TRT but if we eventually want
to use window parameters like frame parameters, we'll probably want to
clone some parameters as well.  When we make such clones, we probably
don't want to care about the semantics of `save-window-excursion'.  The
easiest solution seems to give the parameter a persistence value which
has `current-window-configuration' simply ignore it.

martin