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.

Thanks.