bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer

[martin rudalics <rudalics@gmx.at>]

 >> In practice this is a problem because the position stored in the
 >> `window-prev-buffers' data is a marker (or at least that is the case
 >> in the scenario I am dealing with), and the buffer in question is
 >> periodically erased and regenerated.  Erasing the buffer causes all
 >> its markers to be moved to position 1, so the end result is that the
 >> user loses their place.  (The buffer contents are rebuilt, but the
 >> new content is typically similar if not identical to the old content,
 >> and so maintaining the original position is desirable).
 >
 > This sounds like quite a unique use case to justify a global behavior
 > change of 2 commands.  Can't you achieve what you need by other means?
 > Stashing the value of point or window-point somewhere and then
 > restoring it doesn't sound too complicated to me.
 >
 > Adding martin, in case he has comments and suggestions.

The only idea I have is to handle the "erased and regenerated" case by
invalidating the point markers.  IIUC this means that we have to first
identify the "erased and regenerated" case in 'after-change-functions'
and then use 'window-prev-buffers' to update the POS field of all
entries for that buffer in every window it has shown it.  We will miss
occurrences in saved window configurations if the associated window is
not live.

martin