bug#58175: 29.0.50; M-x window-swap-states during an active mark leaves behind a region overlay

[Stefan Monnier]

>> Could be, but the behavior is not documented, AFAICT: the doc seems to
>> suggest that `window-state-put` doesn't touch the parameters that are
>> not mentioned in `window-persistent-parameters` (whereas it actually
>> throws them out unconditionally).
> AFAICT that's consistent with the remaining behavior of these functions.

Could you clarify what you mean by that?
Which other functions and what "remaining behavior" are you thinking of?

> The values of the window where the state is put are completely replaced
> by the values of the window where the state has been obtained from.

That's indeed the behavior of the code, as I pointed it out, but the
docstring of `window-persistent-parameters` says:

    Parameters not saved by ‘current-window-configuration’ or
    ‘window-state-get’ are left alone by ‘set-window-configuration’
    respectively are not installed by ‘window-state-put’.

"not installed" is not the same as "thrown away".

If we want to keep this behavior, we should document it a bit more
clearly, I think.  Maybe that's what you meant by the distinction
between "left alone" and "not installed"?

Also, I think it's worthwhile then to add some hook run before throwing
away that info.

>> I see 3 options:
> I'm still not convinced that window parameters are the best choice for
> keeping information about the highlighted region.

You might be right, but that's a somewhat orthogonal discussion.
I don't think this choice should be imposed by a specific choice of
behavior of `window-state-put`.

> The parameter used here is a conglomerate - 'window-point' is window
> local, the mark is buffer local and which window is the selected one is
> global.  But since, as Eli said, we also may want to highlight the
> region in non-selected windows, there might be no better choice.

Yes, I think we'll have to use a hash-table (weakly) indexed by windows :-(

> In either case, please keep in mind that the persistence of parameters
> must be also handled by ‘set-window-configuration’ though that one
> never has to transfer properties from one window to another.

AFAIK the current code works fine with `set-window-configuration`.
And indeed `set-window-configuration` behaves the way I suggest
`window-state-put` should behave:

          /* Restore any window parameters that have been saved.
             Parameters that have not been saved are left alone.  */


-- Stefan