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

[Stefan Monnier]

>> We could change the above code so it only sets to nil those
>> parameters that are listed in `window-persistent-parameters`, but I'm
>> not sure if that's the right choice.  It might be, tho: it seems odd to
>> just zap properties owned by arbitrary packages without giving them
>> a chance to "say goodbye".
>
> Martin will tell, but I'm pretty sure this wasn't born out of thin
> air.

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

> I'm sure there are window parameters that will do harm if
> copied.

I'm not talking about copying.  I'm talking about leaving them where
they are.

>> Or we could add some kind of hook (similar to a `change-major-mode-hook`
>> but for window state changes rather than major mode changes) so code
>> like the region-highlight code can register itself there to throw away
>> its overlays before a new window-state is installed.
> Why is this cleaner than maintaining a list of "persistent"
> parameters?

Notice there are two notions of "persistent" here.

Let's say we use `window-stat-save` in window A and then
`window-state-put` in window B:

- `window-persistent-parameters` lets you control which parameters of
  window A are "persisted/copied" to B.  `internal-region-overlay`
  doesn't want to be among those copied parameters.

- I'm suggesting we add some way to control what happens to parameters
  that were in window B.  Clearly, for those parameters in
  `window-persistent-parameters` they'll have to be overwritten.
  But currently they are all wiped out unconditionally just before
  putting the new state, which is a problem in the case of
  `internal-region-overlay` where we don't necessarily need to preserve
  its value (tho that would work as well), but we'd need to remove it
  a bit more carefully at least.

I see `window-state-put` as something similar to calling a major-mode:
it starts by "killing all local variables" (i.e. removing all window
parameters) and then sets up its own state.

I see 3 options:

- Change `window-state-put` so it doesn't touch those parameters not
  mentioned in `window-persistent-parameters`.  This is arguably the
  simplest change and IMO it would make it behave closer to what its
  doc suggests.

- Add a `before-clearing-window-parameters-hook`, just like
  `kill-all-local-variables` runs the `change-major-mode-hook` (tho, if
  so, we should design it such that it's a bit easier for that hook
  to make some parameters survive unscathed).

- Add a new variable (or some new special value for
  `window-persistent-parameters`) listing those window parameters that
  should not be touched by `window-state-put` (i.e. the equivalent of
  "persistent variables").


        Stefan