bug#35161: 26.1; follow-mode spurious motion

[Stefan Kangas]

tags 35161 + notabug
close 35161
thanks

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Devon Sean McCullough <Emacs-Hacker2018@jovi.net>
>> Date: Fri, 5 Apr 2019 11:58:23 -0400
>>
>> bash$ /Applications/Emacs.app/Contents/MacOS/Emacs -Q -eval '(progn 
>> (insert-file-contents-literally "/dev/stdin") (eval-buffer))' <<.
>> (xref-find-definitions 'set-frame-font)
>> (toggle-frame-maximized)
>> (follow-mode)
>> (delete-other-windows)
>> (mark-defun)
>> (split-window-right)
>> (setq s1 0
>>       t1 (run-at-time 1 1 (lambda (&rest args)
>>                          (other-window 1)
>>                          (sit-for 0)
>>                          (when (> (setq s1 (1+ s1)) 3)
>>                            (cancel-timer t1)
>>                            (message "Now when you type C-x o the unselected 
>> cursor will spuriously move to the bottom line.")))))
>> .
>> bash$ ## Both windows' cursors should stay put, but instead one of them 
>> moves.
>>
>>              Peace
>>                      --Devon
>>
>> P.S. I'm curious why programmatic (other-window 1) (sit-for 0)
>> doesn't exhibit this bug.
>> Perhaps ELisp manual chapter 28.21 Windows and Point
>> should mention relevant pitfalls?
>
> It's not a bug, not in redisplay anyway.  The last line of the left
> window is not fully visible, at least on my system, and that causes
> the effects you see (if I understand correctly the issue you find
> unexpected).
>
> Btw, calling sit-for from a timer function is not a good idea, but
> this is a tangent.

Eli explains here that this is not a bug and there has been no further
replies within a year.  I'm going to assume this answer is satisfactory
and close this bug now.

If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.

Best regards,
Stefan Kangas