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: Sat, 6 Nov 2021 11:50:48 +0000 Message-ID: References: <86bl31xfl9.fsf@mail.linkov.net> <83h7ctgk93.fsf@gnu.org> <86pmrf3l9m.fsf_-_@mail.linkov.net> <835yt7g3my.fsf@gnu.org> <8335o9dazn.fsf@gnu.org> 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="38072"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51590@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 06 12:52:13 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 1mjKF3-0009hF-3m for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Nov 2021 12:52:13 +0100 Original-Received: from localhost ([::1]:44590 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjKF0-0004DD-Tl for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Nov 2021 07:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjKEs-0004Cp-EK for bug-gnu-emacs@gnu.org; Sat, 06 Nov 2021 07:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mjKEs-0003dI-5m for bug-gnu-emacs@gnu.org; Sat, 06 Nov 2021 07:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mjKEs-00027a-20 for bug-gnu-emacs@gnu.org; Sat, 06 Nov 2021 07:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Nov 2021 11:52:02 +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.16361994628077 (code B ref 51590); Sat, 06 Nov 2021 11:52:02 +0000 Original-Received: (at 51590) by debbugs.gnu.org; 6 Nov 2021 11:51:02 +0000 Original-Received: from localhost ([127.0.0.1]:48632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjKDt-000260-Kw for submit@debbugs.gnu.org; Sat, 06 Nov 2021 07:51:02 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:26916 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mjKDq-00025g-3M for 51590@debbugs.gnu.org; Sat, 06 Nov 2021 07:51:00 -0400 Original-Received: (qmail 46340 invoked by uid 3782); 6 Nov 2021 11:50:51 -0000 Original-Received: from acm.muc.de (p2e5d54e0.dip0.t-ipconnect.de [46.93.84.224]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 06 Nov 2021 12:50:51 +0100 Original-Received: (qmail 12834 invoked by uid 1000); 6 Nov 2021 11:50:48 -0000 Content-Disposition: inline In-Reply-To: <8335o9dazn.fsf@gnu.org> 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:219099 Archived-At: Hello, Eli. On Sat, Nov 06, 2021 at 09:00:44 +0200, Eli Zaretskii wrote: > > Date: Fri, 5 Nov 2021 21:45:32 +0000 > > Cc: Juri Linkov , 51590@debbugs.gnu.org > > From: Alan Mackenzie > > Yes. There's a bug in posn-at-x-y, in that either the function or the > > documentation is wrong. > It isn't a bug, it is a deliberately implemented behavior. See also > bug#15783. > > The doc says, rather unhelpfully, "By default, X and Y are relative to > > [the] text area of the selected window.". What does "[the] text area" > > mean? > In the ELisp manual, type "i text area of a window RET" and read there. > I've now made changes there to make clear that the header-line and the > tab-line _are_ included in the text area. I'm just confused at the moment, after having spent several hours trying to sort things out in my head. I think "window body" and "window text area" mean the same thing, but I'm not sure. The picture in elisp page "Basic Windows" seems to show "window body height" as NOT including the header line or tab line. That picture seems to show the header line as being ABOVE the text area, not part of it. The current implementation of posn-at-x-y includes the header line in its Y coordinate, BUT NOT THE TAB LINE. I think this is a bug. window-inside-pixel-edges, aka (window-edges &optional WINDOW BODY ABSOLUTE PIXELWISE) with BODY and PIXELWISE non-nil, returns (according to the elisp page) "the edges of WINDOW's body". This "body" DOES NOT include the tab line or the header line. When I run the function on an info page with tab-bar-mode enabled in my tty I get: (0 2 240 65) ^ .. This would appear to contradict the above notion of "body" as including the header and tab lines. It seems to me that we really need two distinct terms here, one for the text area of the buffer including the header and tab lines, and another for the "pure" text area without those lines. Maybe something like "extended body" vs. "text area", or something like that. > > In posn-at-x-y, "the text area" _INCLUDES_ THE HEADER LINE. > Yes. As it should. OK. > > It would appear this behaviour of posn-at-x-y is also in Emacs 27.2. It > > would probably be catastrophic to fix posn-at-x-y, since so many > > programs will have compensated for this bug. So, we should probably fix > > the doc of the function. > Done on the emacs-28 branch. Thanks! > > But we can fix follow-calc-win-end, by replacing the form at 2 with: > > (last-line-pos (posn-point (+ (posn-at-x-y 0 (1- ht) win) > > (window-header-line-height win)))) Actually, that's not right. It should be (last-line-pos (posn-point (posn-at-x-y 0 (+ (1- ht) (window-header-line-height win))))) , but that's a mere detail. It appears to solve much of Juri's bug. > What about the tab-line (which AFAIU was the trigger for this bug)? Yes, that needs to be incorporated, too. The other hunk of Juri's patch, in follow-scroll-down, is needed, but I don't think it's quite right when combined with my suggestion for follow-calc-win-end above. > > And I think we (probably me ;-) should go through the elisp manual and > > doc strings replacing vague phrases like "the text area of the window" > > with explicit descriptions involving "the header line", etc. > That'd be going overboard. We could place a cross-reference in some > of those places to the "Frame Layout" node, though. Suggestions for > such places are welcome. OK. But I think there's confusion in the manual and doc strings, and even the code, and that it's not just me. -- Alan Mackenzie (Nuremberg, Germany).