[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 2.0.0.21 (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.
martin
- bug#10348: 24.0.92; Save and load window states, (continued)
- bug#10348: 24.0.92; Save and load window states, Stefan Monnier, 2011/12/22
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/23
- bug#10348: 24.0.92; Save and load window states, Michael Bach, 2011/12/23
- bug#10348: 24.0.92; Save and load window states, Juri Linkov, 2011/12/23
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/24
- bug#10348: 24.0.92; Save and load window states, Juri Linkov, 2011/12/24
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/25
- bug#10348: 24.0.92; Save and load window states, Stefan Monnier, 2011/12/23
- bug#10348: 24.0.92; Save and load window states,
martin rudalics <=
- bug#10348: 24.0.92; Save and load window states, Stefan Monnier, 2011/12/25
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/25
- bug#10348: 24.0.92; Save and load window states, Juri Linkov, 2011/12/25
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/26
- bug#10348: 24.0.92; Save and load window states, Stefan Monnier, 2011/12/25
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/26
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/26
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/28
- bug#10348: 24.0.92; Save and load window states, Stefan Monnier, 2011/12/28
- bug#10348: 24.0.92; Save and load window states, martin rudalics, 2011/12/28