2012/1/20 Stefan Monnier
<address@hidden>
> 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