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

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 29, 2018 at 13:26:12 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 08:35:51 +0000
> > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Follow-mode is special in this regard, because with it, showing a
> > > partial line is not a flaw, as that same line will be fully visible in
> > > the next window, and follow-mode actually switches to that next
> > > window.  So we need to tell the display engine to behave specially in
> > > this case.  I suggested 2 ways of doing that, the simple one actually
> > > does what you expected, i.e. the force_start flag will win.

> > This feels a bit like a workaround

> That's because it _is_ a workaround.  But it's a safe one, so it can
> easily go into emacs-26, and solve most of this old bug.  More complex
> solutions will have to go to master and wait till Emacs 27.  WDYT
> about that?

I think my proposal from my last post is also safe and simple, it being
a mere 5 lines (not counting comments) in one place in follow.el, and
which is self contained.  It ranks in complexity between your two
proposals.

> > Also, the user can change make-cursor-line-fully-visible at any
> > time, unlikely though this is.

> Users can shoot themselves in the foot in many ways, but that's their
> funerals.  We can always tell them "don't do that".

Yes.  This thing is a customisable option, however.

> > I propose the following solution: at the critical piece of code in
> > follow mode's post-command-hook, follow mode should check
> > make-cursor-...-p, and if non-nil, determine, using
> > pos-visible-in-window-p whether the cursor is in the last partial line.
> > If so, move it one line higher.  In follow-mode, the positions of point
> > in the non-selected windows are fairly random anyway.

> Why is this better than what I proposed?

It is simpler than allowing m-c-l-f-v be a function (which would involve
amendments in xdisp.c, I think) yet still observes the intent of that
variable, particularly on the last follow-mode window.

> I proposed to allow make-cursor-line-fully-visible to have a value
> that is a function, and let follow-mode define that function
> accordingly, to make Emacs behave as if the last window in the group
> had make-cursor-line-fully-visible set to the default or what the user
> set it, and nil in all other windows under follow-mode.  I think that
> every solution that lets the display engine do the job is cleaner than
> trying to force the display engine do that same job.

Maybe.  But follow mode is already a big fight with the display engine.
(I can't see how it could be otherwise, except by enhancing the display
engine to support multiple windows natively.)

> Besides, your proposal has the annoying effect of causing a
> micro-scroll near the end of the window.

I don't see this (on GNU/Linux/X with GTK+ 3.22.30).

> > As an aside, make-cursor-...-p doesn't appear in either the Emacs manual
> > or the Elisp manual, and the documentation for set-window-position
> > doesn't mention it.  I can feel a documentation writing urge coming on.

> We don't document every variable, and this one is unlikely to be
> modified from the default.  So I see no reason for the urge.

I was also thinking of amending the doc for set-window-start, to alert
users to the possibility of a nil NOFORCE argument failing to prevent
scrolling.  If make-cursor-line-fully-visible were to become,
optionally, a function there would be more reason to document it in the
manual.

-- 
Alan Mackenzie (Nuremberg, Germany).