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

[Alan Mackenzie]

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