bug#51590: follow-mode is broken with header-line and tab-line

[Alan Mackenzie <acm@muc.de>]

Hello, Juri and Eli.

On Thu, Nov 04, 2021 at 19:29:28 +0200, Juri Linkov wrote:
> retitle 51590 follow-mode is broken with header-line and tab-line
> quit

> >> The most low-level function of follow-mode is follow-calc-win-end.
> >> When global-tab-line-mode is enabled, follow-calc-win-end
> >> returns the same values as when global-tab-line-mode is disabled.

> > Can you step through that function and see which part is misbehaving
> > there?

> >> I don't understand what more low-level function doesn't take
> >> into account the height of the tab-line.  Maybe the problem is
> >> in pos-visible-in-window-p?  Or maybe different values returned
> >> by window-inside-pixel-edges and window-end?

> > I don't know the answer, but I see that header-line-format is
> > mentioned in one place in follow.el, and that is not a good sign...

> Indeed, I tested with the header-line, and it has the same problem,
> so retitled this bug report.

> After trial and error, I arrived to the following patch that completely
> fixes these problems.  However, I can't explain how it works.

I've spent some time on this patch, and I've transformed it into a
similar patch that I can explain, and I believe is nearly correct[*].
Could you possibly try it out in your system.  Thanks!


diff --git a/lisp/follow.el b/lisp/follow.el
index b64f4cb734..2ca2c1f17b 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -667,7 +667,8 @@ follow-scroll-down
 	 (scroll-down-command arg))
 	(arg (follow-scroll-down-arg arg))
         (t
-	 (let* ((windows (follow-all-followers))
+	 (let* ((orig-point (point))
+                (windows (follow-all-followers))
 		(win (car (reverse windows)))
 		(start (window-start (car windows))))
 	   (if (eq start (point-min))
@@ -678,11 +679,14 @@ follow-scroll-down
 	     (select-window win)
 	     (goto-char start)
 	     (vertical-motion (- (- (window-height win)
-				    (if header-line-format 2 1)
-				    next-screen-context-lines)))
+				    (if header-line-format 2 1) ; always mode-line
+				    (if tab-line-format 1 0)
+                                    next-screen-context-lines)))
 	     (set-window-start win (point))
-	     (goto-char start)
-	     (vertical-motion (- next-screen-context-lines 1))
+             (if (< orig-point (window-end win t))
+                 (goto-char orig-point)
+               (goto-char start)
+	       (vertical-motion (- next-screen-context-lines 1)))
 	     (setq follow-internal-force-redisplay t))))))
 (put 'follow-scroll-down 'scroll-command t)
 
@@ -947,7 +951,11 @@ follow-calc-win-end
   (let* ((win (or win (selected-window)))
 	 (edges (window-inside-pixel-edges win))
 	 (ht (- (nth 3 edges) (nth 1 edges)))
-	 (last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win))))
+	 (last-line-pos (posn-point
+                         (posn-at-x-y 0 (+ (window-header-line-height win)
+                                           (window-tab-line-height win)
+                                           (1- ht))
+                                      win))))
     (if (pos-visible-in-window-p last-line-pos win)
 	(let ((end (window-end win t)))
 	  (list end (pos-visible-in-window-p (point-max) win)))


[*] There is a situation which is not new, where if the buffer is too
short to fill all the windows, and it is already scrolled up far,
follow-scroll-down will scroll a correct amount, but leave point in a
random position.


-- 
Alan Mackenzie (Nuremberg, Germany).