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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Sep 29, 2018 at 18:06:20 +0300, Eli Zaretskii wrote:
> > 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?

Yes.  But point in the non-selected windows of a follow set is in any
case of no consequence.  Try setting up follow mode, do a few things in
it, then do C-x o.  Often, when I do this, point is at the mid point of
the window moved to.  Of no consequence.

What I, as a typical user (hah!), sees, is that point moves from the LH
window to the RH window.  If I were using the GUI version, I would soon
learn not to see the hollowed out representation of point left in the
"old" window.  Maybe we could enhance Emacs to be able not to display
this hollow point in the non selected windows of a follow set.  I've not
looked into it, but it shouldn't be too difficult.

If we had real support for a multiple window in the display engine (I
started trying to write this a couple of years ago, but didn't get very
far), there would be just one point shared by all the "sub"windows, and a
single full width mode line rather than a truncated mode line for each
"sub"window.  Maybe somebody will someday construct this.

> > > 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.

Oh, OK, then!  I can accept this.

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

> Right.

I will make this change to follow-mode for Emacs-26, and commit it with a
"don't merge to master" instruction to our infrastructure.  Probably
tomorrow.

> > > 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.

OK, let's do it!  What arguments will such a function get?  I think a
single argument, a window, would be appropriate.  The function would then
return either nil (for most windows) or non-nil (for a "right most"
window).

> > 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.

You may be right.  But I think I'll extend the docu anyway.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).