From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#51590: follow-mode is broken with header-line and tab-line Date: Sun, 7 Nov 2021 12:48:22 +0000 Message-ID: References: <86bl31xfl9.fsf@mail.linkov.net> <83h7ctgk93.fsf@gnu.org> <86pmrf3l9m.fsf_-_@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7270"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51590@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 07 13:49:29 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mjhc0-0001jP-Py for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Nov 2021 13:49:28 +0100 Original-Received: from localhost ([::1]:41862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjhbz-0003Gf-TF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Nov 2021 07:49:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjhba-0003Dn-6O for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 07:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40467) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mjhbZ-00029Y-SY for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 07:49:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mjhbZ-00008h-OS for bug-gnu-emacs@gnu.org; Sun, 07 Nov 2021 07:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Nov 2021 12:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51590 X-GNU-PR-Package: emacs Original-Received: via spool by 51590-submit@debbugs.gnu.org id=B51590.1636289311492 (code B ref 51590); Sun, 07 Nov 2021 12:49:01 +0000 Original-Received: (at 51590) by debbugs.gnu.org; 7 Nov 2021 12:48:31 +0000 Original-Received: from localhost ([127.0.0.1]:52013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjhb4-00007s-QQ for submit@debbugs.gnu.org; Sun, 07 Nov 2021 07:48:31 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10909 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mjhb3-00007g-15 for 51590@debbugs.gnu.org; Sun, 07 Nov 2021 07:48:29 -0500 Original-Received: (qmail 34502 invoked by uid 3782); 7 Nov 2021 12:48:23 -0000 Original-Received: from acm.muc.de (p2e5d5a37.dip0.t-ipconnect.de [46.93.90.55]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Nov 2021 13:48:22 +0100 Original-Received: (qmail 9417 invoked by uid 1000); 7 Nov 2021 12:48:22 -0000 Content-Disposition: inline In-Reply-To: <86pmrf3l9m.fsf_-_@mail.linkov.net> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:219233 Archived-At: 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).