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

[martin rudalics <rudalics@gmx.at>]

 >> What we talk about here is this form in 'window--state-put-2':
 >>
 >>        (dolist (parameter (window-parameters window))
 >> 	(set-window-parameter window (car parameter) nil))
 >
 > Yes.
 >
 >> which has no equivalent in 'set-window-configuration'.
 >>
 >> The distinction is due to the fact that 'set-window-configuration' works
 >> on already existing (albeit temporarily deleted) windows while
 >> 'window-state-put' as a rule has to work on pristine windows.
 >
 > But the above `dolist` does nothing on pristine windows.
 > So it's been put there explicitly for the case of non-pristine windows.

Because the idea was to keep the behaviors consistent: Regardless of
whether a window is new or old, it should get the same values for all
parameters.  But maybe that idea was misguided: 'window-swap-states' was
added two versions after 'window-state-get'.  So lets get rid of these
lines.

 >> But doesn't the fact that 'set-window-configuration' handles a nil value
 >> of a parameter distinctly from "no value for that parameter has been
 >> stored yet" mean that it handles window parameters specially, unlike
 >> other window components or the way we handle frame parameters?
 >
 > I don't follow.  AFAIK the special handling of nil there is simply an
 > optimization to avoid adding useless nil entries in the parameter list.

'frame-parameters' gets me entries for all parameters including those
that have never been assigned a value to - more than 130 entries here,
half of them nil.  So when you want to save these values from Lisp you
do add "useless nil entries in the parameter list".

 > It was very helpful for me to re-read what those past Stefan and Martin
 > guys had to say.  Tho it seems they didn't talk very much about what
 > happens to the poor window-parameters of the target windows, they only
 > talked about the parameters of the source windows and how/if they should
 > be transferred to a target window (potentially via a file).
 >
 > The current bug report points out that we should also pay attention to
 > the parameters of the target window (because we overwrite them or throw
 > them away).

If you tried to transfer the value of ‘frame-parameters’ from one frame
to another, you would overwrite them in the target frame too.

 >> But 'set-window-configuration' does not DTRT when the region overlay
 >> parameter is made persistent.
 >
 > But that's because that window parameter should *not* be persistent.

The region highlighting code should DTRT regardless of whether its
parameter has been made persistent or not.  So once you removed the
lines above to fix the state transferal, you should try to fix this
case too.

martin