From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#51590: follow-mode is broken with header-line and tab-line Date: Tue, 9 Nov 2021 11:14:07 +0100 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> <83bl2xbhz1.fsf@gnu.org> <83o86x9lg6.fsf@gnu.org> <834k8m7adu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20152"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 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 Tue Nov 09 11:15:32 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 1mkOA8-00050o-Fy for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Nov 2021 11:15:32 +0100 Original-Received: from localhost ([::1]:50058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkOA6-0002of-9x for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Nov 2021 05:15:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkO9g-0002l3-A1 for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:15:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49378) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkO9e-0003pB-AV for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mkO9e-0000gx-5o for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Nov 2021 10:15: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.16364528612580 (code B ref 51590); Tue, 09 Nov 2021 10:15:02 +0000 Original-Received: (at 51590) by debbugs.gnu.org; 9 Nov 2021 10:14:21 +0000 Original-Received: from localhost ([127.0.0.1]:60924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkO8z-0000fY-8K for submit@debbugs.gnu.org; Tue, 09 Nov 2021 05:14:21 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:42087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkO8u-0000f4-Iu for 51590@debbugs.gnu.org; Tue, 09 Nov 2021 05:14:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1636452849; bh=TULfDWUuDvgJiUhH1jZEUQwmDXSeaUqkeISibFlfTkk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Bjv2d8JFRW5pKS7gZabhPEtsmXGLYDJezI1RyGLLipP4LSEpam8mLqE5tpxGKBEyc FFcbLOozmDlyudjgjbnISBZrdoWBYyNy/V9bL8uIwtR8oKIR5ZoNfOYF5ABjYXKUd0 +FaeOSQQdHfmxW4VOiWCgHBpatJ62SxDCDgzm2k4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.59]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgvrL-1mEujs11dl-00hOEM; Tue, 09 Nov 2021 11:14:09 +0100 In-Reply-To: <834k8m7adu.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:o8ZH9qtDewI/+OpKzk0MAmhCTJ4OzuKEQWnsD+ESJg7sd7DGI5g BXrAadJt+t+cwqZhl2PXZsv70947umyFl1r1qJOexruR6fKdYKZarlNCDC0ILDpgjej36lb utYontU8zZdiKMyRq4b1VBijU7thOCZFDBsz8ObIbNbtiG5MbqVywrrlprC6FAooVoOjoBT mFSbtQ2SjWd6idQN9TSgg== X-UI-Out-Filterresults: notjunk:1;V03:K0:wAkcaXuflBQ=:El5CHghU2Cs4hGIdhggQ3z IEQsuPXvw9Yw9a4SEbvjBp7vZ+pSMz/1N4ntR0W92CXrzwb46ybyT9+hnE9IdMJ3GSyjrKYGW Jwtnyu81V2kWSmT/w5b8jvXJXmtwFduEtQFUk0TBTRLWP4dyBd43wmz+or/PBET2cMjY5wcgC dhDRVRW9TE5Uelk8hZn1GxdVbRtVnZtbrbDXQ/XYxslYG6MAioFidgo2Sx6mPVyd+sLXGafPX UFwbW5oiA6aESohjRxQk8E6mXZUI5G0ajwfcc66ZTa/3PIg3KSvi/RG/lQ4+2MB01WD/OUNcW c9Yz8YVSPDmzB8LaXcK+ZFmbM6E/EkF1v3kPumAvceqo08Z7ZLkgq9Ly+05Oep0t+9uYXrnj+ PvRfl+/G2i1ThDNqDKgoncRYsA9GMPI29oInx4jnt4SZ5kZ1vlh+fR1OfaK7fxMKlxRqevlTP 8R/Gk2/2Otld6Z0EiXW7d6rOqYgZ9RwB0IFuOU9+wML+wb2oDb/lT24fmp5UJDbs8lUSkEH/y biEbT/pItaDHiGEIjUw6sHqUqAYUAvYA1vlk+wz/5UgnCZHwz2wj52jRTNxsWepQtXUSLMPJe MbBtz4W8wVTJUS8/REkv9ud8Kp92OP8g33GOm84vCugpHHUMJ5tUyHsilBm9zhCSIBaCtQvQA lC8rZYcnGl2mefXjbV47UoCQ7uh+zkInbGxZchulJDLigx0CSO6XbP0A2/A3xh6DFVBTgdLl3 VoJUZPeIxL/bhq1fXSbmJ2yjry8sboGrEFTo5OvjlUPICEys2ELVShzLblCskcJgu2v9a7Q8 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:219434 Archived-At: >> But >> >> (posn-area (posn-at-x-y 0 (window-body-height nil t))) >> >> gives me 'mode-line' here which is wrong since, according to your new >> definition, the mode line is _not_ part of the text area. > > "Wrong" why, because the doc string of window-body-height mentions the > text area? Or for some other reason? If you had answered my question How would your book describe the text area? A T-shaped area comprising the window's body, its header and tab line? What would be the width of that area? Why would it exclude the mode line? I would be able to tell. A definition like The @dfn{text area} of the window includes the header line and the tab line, if they are present in the window. does _not_ define what the text area is. > And, btw, why do you use (window-body-height nil t) instead of > (1- (window-body-height nil t)) ? The last pixel of the window's body > has Y coordinate (1- (window-body-height nil t)), no? Right. I wanted to be below the body. >> And with a bottom divider >> >> (posn-area (posn-at-x-y 0 (1- (window-pixel-height)))) >> >> gets me 'bottom-divider'. > > And that is wrong why? See above. >> So I'd suggest to revert your changes wrt the text area. > > I wrote in another message what I'd like to do with "text area" in doc > strings. Given that they will disappear from the doc strings, what > other problems do you see? That the manual still defines the "text area" and now even in a form that lets me only guess what it is. >> (posn-area (posn-at-x-y (1- (window-pixel-width)) 0)) >> >> currently gives 'nil' regardless of whether it's done with a header or >> tab line > > Isn't that because window-pixel-width includes the fringes? The header line doesn't have any fringes. >> and >> >> (posn-area (posn-at-x-y >> (1- (window-pixel-width)) >> (1- (window-pixel-height)))) >> >> gives 'nil' on the mode line. Only when I remove _both_ fringes and the >> vertical scroll bar I get the expected results. This _is_ a bug and we >> should fix it. > > I don't think it's a bug, because window-pixel-height includes the > fringes, according to its doc string. Try > > (posn-area (posn-at-x-y > (- (window-pixel-width) 9) > (1- (window-pixel-height)))) The mode line doesn't have any fringes either. martin