[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10348: 24.0.92; Save and load window states

From: martin rudalics
Subject: bug#10348: 24.0.92; Save and load window states
Date: Sat, 24 Dec 2011 10:27:30 +0100
User-agent: Thunderbird (Windows/20090302)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]