2012/1/20 Stefan Monnier <monnier@iro.umontreal.ca>

> > into account the previously set mark(s). It looks better to use
> > `push-mark' instead of `set-mark'. Moreover it does not restore the
> > active mark state which lead to an automatically active mark in
> > restored buffer.
>
> `push-mark' is wrong if nothing happened between window-state-get and
> window-state-put.
>
I do agree but the use of set-mark leads to the lost of the potential
previous mark.
Maybe I could just add a control like call `push-mark' only if current if
current mark
is not equal to the saved one.


> And the mark & mark-active are buffer-local but not window-local.
> If we window-state-get in a frame which shows the same buffer several
> times, window-state-put would end up pushing the same mark several times.

That was more of less the subject of  my previous thread ("[PATCH]
window.el: Remove mark saving and restoring")
that I cancel to have time to think about it a little bit more. The
proposition was to remove the mark
stuff (I did provide a patch for this) that looks not relevant in the
`window-state-get' and
`window-state-put'. However but thinking more about it I figured out that
somebody could want the mark restored.

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

In conclusion I think we have to make a choice:
- Either, we accept the idea that the mark is restored and we should take
care of its active state, avoid the previous
potential mark loss and do not push-mark when the current `mark' is equal
to the saved one.
- Either, remove all the mark stuff from `window-state-get' and
`window-state-put' functions.
- Other ?

I have patch almost ready for these two proposals so let me know.

Jérémy