bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 29 Sep 2018 14:48:46 +0000
> Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > It isn't anywhere near safe in my book, sorry.  Futzing with
> > window-start and other related variables is a minefield we better not
> > go into on the release branch.
> 
> My patch doesn't do anything like that.  It merely has a test, and if
> that test signals t, moves point by one line, away from the danger area.
> The messing around with window-start has been in follow mode for ever.
> I think it's time to post that patch:
> 
> 
> diff --git a/lisp/follow.el b/lisp/follow.el
> index fd397c077b..7d6204b08e 100644
> --- a/lisp/follow.el
> +++ b/lisp/follow.el
> @@ -1385,7 +1385,15 @@ follow-adjust-window
>  	  (unless (eq win (selected-window))
>  	    (let ((p (window-point win)))
>  	      (set-window-start win (window-start win) nil)
> -	      (set-window-point win p))))
> +	      (set-window-point win p)
> +              (if (and frame-resize-pixelwise
> +                       make-cursor-line-fully-visible
> +                       ;; Check for cursor being in partially displayed line.
> +                       (nth 2 (pos-visible-in-window-p p win t)))
> +                  ;; If so, move point away from this disaster line,
> +                  ;; preventing scrolling.
> +                  (with-selected-window win
> +                    (forward-line -1))))))

But this means the user will have its command to move point down
"ignored" in the window where she did that, right?  IOW, I press C-n,
and yet cursor stays in the line where I was before, right?

> > So if you don't think turning off make-cursor-line-fully-visible in
> > follow-mode buffers is an okay solution, the solution will have to
> > wait till Emacs 27, sorry.
> 
> Turning off m-c-l-f-v I can live with, and if you definitely reject my
> approach above, I'm willing to implement it.

I think it will have a smaller effect than what you propose, yes.

> It can't be difficult, just
> creating a buffer local variable and setting it to nil.  ;-)

Right.

> > The changes in xdisp.c are a no-brainer, we already call several Lisp
> > functions in several places, and there's infrastructure ready for
> > that.
> 
> OK.  But it will be more complex than my 5-line patch above.

I volunteer to do the xdisp.c part if you will agree to write the
follow.el function to serve as the value for
make-cursor-line-fully-visible.

> The current docs imply NOFORCE being nil always works.  If the docs had
> mentioned the exception, it's possible we wouldn't now be dealing with
> this bug.

I'm just saying that telling users it will sometimes not work,
depending on factors that are really hard to describe, is not
necessarily better.  But I don't object.