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

[Eli Zaretskii <eliz@gnu.org>]

> From: Markus Triska <triska@metalevel.at>
> Cc: martin rudalics <rudalics@gmx.at>,  acm@muc.de,  34038@debbugs.gnu.org
> Date: Sun, 24 Mar 2019 11:35:07 +0100
> 
> I have found another case of this issue (i.e., set-window-start fails to
> set window-start). In emacs -Q, please evaluate the following form in
> the *scratch* buffer:
> 
>     (progn
>       (delete-region (point) (point-max))
>       (insert "\n")
>       (set-window-start nil 1)
>       (goto-char (point-max))
>       (while t
>         (insert "test\n")
>         (unless (pos-visible-in-window-p (point))
>           (redisplay)
>           (let ((start (window-start)))
>             (if (= start 1)
>                 (error "window-start is now 1 (as expected), please try a different text-scale-amount")
>               (error "window-start is now unexpectedly %s (instead of 1)" start))))))
> 
> This sets, and sometimes fails to set, window-start to 1, apparently
> depending on the amount of text-scale:
> 
> When I evaluate this with text-scale-mode-amount set to 0, window-start
> is correctly set to 1. However, when I change the amount of text-scale
> with either C-x C-= or C-x C--, then, after the form stops evaluating,
> window-start is at other positions. In that case, even when I then
> manually try to set the window-start to 1 with:
> 
>     M-: (set-window-start nil 1) RET
> 
> then the window-start is not set to 1, but remains at the same position.
> Is this due to the same issue, or should I rather file this separately?

Most probably it is the same issue.  However, I'm not really sure what
surprised you in this behavior, so how about describing what you
thought should have happened here, step by step, in contrast with what
did happen?  I believe I then will be able to provide a more accurate
answer to your question.