2012/1/20 Stefan Monnier
<monnier@iro.umontreal.ca>
>> I'm not completely sure. The current code doesn't seem that bad since,
>> as you say, it basically reproduces the behavior of
>> window-configurations.
>> So I'd like to first hear of what are concrete cases where the current
>> behavior is a problem.
> It's very simple : with the current code, when you call the
> `window-state-put' function, the mark is restored as active.
That's easy to fix: use (set-marker (mark-marker)) instead of set-mark.
Interesting.
> - Either, remove all the mark stuff from `window-state-get' and
> `window-state-put' functions.
That's not a bad idea, actually.
Yes that's was my first idea in fact. After this discussion I think it's the good
thing to do and ou I attached the corresponding patch to this email.
`window-state-get' and `window-state-put' should not deal with mark as it's not
relevant at all and leads to an unexpected behavior from user point of view.
Stefan
PS: BTW, the "multiple push-mark" issue can be solved by saving the mark
only once per buffer rather than once per window (i.e. the window-state
object would have a separate list of affected buffers with their
corresponding state, including the mark, not sure what else could be
there).
I do agree but it will change several things and while we are in feature freeze I
propose to remove the wrong mark management and see how to do it this way
in future development.