bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> All we need to know for why this happens would be the exact sequence
> of (window) point and window start settting operations performed by
> that application.

The actual application performs actions that are quite involved, so I
try to break it down to simpler cases that need fewer operations.

For example, please try the following snippet:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (dotimes (x (window-height))
        (insert (format "%s\n" x)))
      (let ((b (buffer-string))
            (p (point)))
        (redisplay)
        (set-window-start nil p)
        (let ((wp (window-point)))
          (read-key "Step 1. Please press a key to continue.")
          (dotimes (x (round (/ (window-height) 2)))
            (insert (format "more lines ... %s\n" x)))
          (read-key "Step 2. Please press a key to continue.")    
          (erase-buffer)
          (insert b)
          (set-window-point nil wp)
          (set-window-start nil p))))

In this snippet, I try to restore the exact same configuration that you
see when "Step 1 ..." is displayed, i.e., window-start is set so that
point is on the very first line, which is blank. When you press a key at
this point, then a few more lines of text are inserted. Then, please
press another key when "Step 2 ..." is displayed.

What I observe after these forms is that point is unexpectedly placed
vertically centered in the window instead of at the topmost line.

Please note that I am now using set-window-point, and also
set-window-start with third argument (implicitly) nil. I get the exact
same result when I use t for the third argument of set-window-start.

Can you reproduce this? Is there a way to reliably restore this?

Thank you and all the best!
Markus