bug#35860: Delayed window positioning after buffer display

[Juri Linkov]

>> What do you think about a more appropriate name
>> next-display-window-point?  This name says that its effect
>> will occur at the next display of the buffer in the window.
>
> Generalizing 'help-window-point-marker' is problematic.  "at the next
> display of the buffer in the window" says it already: What is the
> "next display" (should it be "redisplay"?) which "buffer" and which
> "window" are meant?

Generalized version does exactly what 'help-window-point-marker'
used to do, i.e.:

  ;; `help-window-point-marker' is a marker you can move to a valid
  ;; position of the buffer shown in the help window in order to override
  ;; the standard positioning mechanism (`point-min') chosen by
  ;; `with-output-to-temp-buffer' and `with-temp-buffer-window'.
  ;; `with-help-window' has this point nowhere before exiting.  Currently
  ;; used by `view-lossage' to assert that the last keystrokes are always
  ;; visible.
  (defvar help-window-point-marker (make-marker)
    "Marker to override default `window-point' in help windows.")

but for all windows instead of only help windows, i.e.:

    "Marker to override default `window-point' in all windows."

So do you think about just removing the prefix `help-' from the name:
`window-point-marker'?