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

[Stefan Monnier]

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

Ah, I remember now, thanks.

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

So the impact would be a very minor inefficiency.  I think we can ignore
this, then.

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

Right, maybe we should treat (PARAM . nil) just like the absence of
PARAM on the list, and use a different value for "don't save 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.

Right (`ignore' is not the best choice of identifier either, it seems ;-).

> As I mentioned earlier configurations and states differ in
> one fundamental aspect:

I understand the difference, but I think we're overengineering the
solution here, making distinctions that are too subtle for the Elisp
programmer to worry about.

So let's not distinguish the cases of ignore=nil and
window-configuration.


        Stefan