From unknown Thu Aug 14 12:24:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#15783 <15783@debbugs.gnu.org> To: bug#15783 <15783@debbugs.gnu.org> Subject: Status: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. Reply-To: bug#15783 <15783@debbugs.gnu.org> Date: Thu, 14 Aug 2025 19:24:39 +0000 retitle 15783 24.3; posn-at-x-y is relative to the buffer area, posn-at-poi= nt is relative to the text area. reassign 15783 emacs submitter 15783 =E6=A4=8E=E9=87=8E =E8=A3=95=E6=A8=B9 severity 15783 minor tag 15783 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 01 11:57:56 2013 Received: (at submit) by debbugs.gnu.org; 1 Nov 2013 15:57:56 +0000 Received: from localhost ([127.0.0.1]:57681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VcH6i-0002ls-5y for submit@debbugs.gnu.org; Fri, 01 Nov 2013 11:57:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VcG2n-000137-CV for submit@debbugs.gnu.org; Fri, 01 Nov 2013 10:49:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VcG2h-0003Zy-7J for submit@debbugs.gnu.org; Fri, 01 Nov 2013 10:49:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcG2h-0003Zu-3c for submit@debbugs.gnu.org; Fri, 01 Nov 2013 10:49:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcG2g-0003Iq-8J for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2013 10:49:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VcG2f-0003Zb-Cz for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2013 10:49:42 -0400 Received: from mail-qa0-x236.google.com ([2607:f8b0:400d:c00::236]:40754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcG2f-0003ZW-96 for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2013 10:49:41 -0400 Received: by mail-qa0-f54.google.com with SMTP id j15so656772qaq.13 for ; Fri, 01 Nov 2013 07:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=sS46RXiGeTPeHuuMuuFIhEiFXKZEKF6f7i4i8fwJSNo=; b=UwEbRVVwAZgXkyQ2Yr6urL8Cycs/FMn6NJWS5k0ruPCReRDt0DlOoKZfiAh2ZQBI6W rMAYJqMi90xKIZiRv/vdNO3M9EAEIXPZVPoPHt5gve5vai57jgeCN2jBCa36YdOfj1Hm GikvlZVWbr/88AvZz3ApTponqYfw7jU9N54puINczlcjlNTJARXr2JHpjyvCPzf4nStY 4G6uiKGHPu1bSovwGAxCvU8KZIxTXh0JmNO0bFVcwBfZrHxMf9eeB21j/bNiZlgHyG8l x2DNrVaZwt4UHt53m4dMthUV1p5tBYdFHI881SiJbHO/jGjltAfPk0UD/FmG2ANKWf1W BFrA== X-Received: by 10.224.138.4 with SMTP id y4mr4477483qat.65.1383317380271; Fri, 01 Nov 2013 07:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.211.233 with HTTP; Fri, 1 Nov 2013 07:49:00 -0700 (PDT) From: =?UTF-8?B?5qSO6YeOIOijleaouQ==?= Date: Fri, 1 Nov 2013 23:49:00 +0900 Message-ID: Subject: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 01 Nov 2013 11:57:55 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) On Emacs 24 with non-nil header-line-format, y offset returned by `posn-at-point' is relative to the text area *not including the header line*. However, `posn-at-x-y' takes y offset relative to the buffer area *including the header line*. Is this by design? When I get the position by `posn-at-point', and then convert the position to the point by `posn-at-x-y', the resulting point does not match the point given to `posn-at-point'. This seems to me a serious inconsistency. On Emacs 22 and 23, both functions are relative to the buffer area including the header line. It's fine. Cheers, Yuki Shiino From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 01 12:32:35 2013 Received: (at 15783) by debbugs.gnu.org; 1 Nov 2013 16:32:35 +0000 Received: from localhost ([127.0.0.1]:57786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VcHeD-0004sr-SY for submit@debbugs.gnu.org; Fri, 01 Nov 2013 12:32:35 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50276) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VcHe9-0004sb-Pw for 15783@debbugs.gnu.org; Fri, 01 Nov 2013 12:32:30 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MVL00100F67BF00@a-mtaout21.012.net.il> for 15783@debbugs.gnu.org; Fri, 01 Nov 2013 18:32:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MVL001WQF9Y5V70@a-mtaout21.012.net.il>; Fri, 01 Nov 2013 18:32:23 +0200 (IST) Date: Fri, 01 Nov 2013 18:32:10 +0200 From: Eli Zaretskii Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. In-reply-to: X-012-Sender: halo1@inter.net.il To: =?utf-8?B?5qSO6YeOIOijleaouQ==?= Message-id: <83fvrgaxrp.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15783 Cc: 15783@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: 椎野 裕樹 > > Date: Fri, 1 Nov 2013 23:49:00 +0900 > > On Emacs 24 with non-nil header-line-format, y offset returned by > `posn-at-point' is relative to the text area *not including the header > line*. However, `posn-at-x-y' takes y offset relative to the buffer > area *including the header line*. > > Is this by design? Yes. > When I get the position by `posn-at-point', and then convert the > position to the point by `posn-at-x-y', the resulting point does not > match the point given to `posn-at-point'. You should test for non-nil header-line-format, and adjust the value accordingly. > On Emacs 22 and 23, both functions are relative to the buffer area > including the header line. It's fine. That caused much more grave bugs. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 17 02:46:47 2017 Received: (at 15783) by debbugs.gnu.org; 17 Nov 2017 07:46:47 +0000 Received: from localhost ([127.0.0.1]:44150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFbMM-0005lv-Qt for submit@debbugs.gnu.org; Fri, 17 Nov 2017 02:46:47 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:44736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFbML-0005li-B8 for 15783@debbugs.gnu.org; Fri, 17 Nov 2017 02:46:45 -0500 Received: by mail-io0-f174.google.com with SMTP id w127so7887870iow.11 for <15783@debbugs.gnu.org>; Thu, 16 Nov 2017 23:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=ACUE6g83VlrwGQ6CiFAty6eBHnWZNHlplFrNVEQl6PA=; b=Q3zefBDxAWbdwFb2f73XZ7iblgmWsEGT3CuRDMP0PITQqP/6tOOEnf8mJqk5RPxQ4E fhuT6Hzc1ojpmKcKb0cW29FdGRCF7VHVDUphUos589Cm+xANRMpvmbYPheVPioy7SHRj Q6LWbeYwDqqFkTD+eCjPTrcQvqzfZaLKRTX+UO1gO1TQw0okVHR3/HbgjcH96Rv6Jt+4 89OCx4IEKm0iOASB2PHPTpE7QFCuT1p45Yb/0gta9sUDxFVhyZoV5JgQLx/PbqjudVMn Ynt+hAbeXAiwmQUqnQ5p/dL+r3HwlFlNv/M7mzBqp1MUNMOOglComcChAzWhU9aDy1// 0afA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=ACUE6g83VlrwGQ6CiFAty6eBHnWZNHlplFrNVEQl6PA=; b=oVRdxE3pE5HDeusLT1XnTtOSpSZR3E9GwqtzuYdJco5UCiDdO9H2tOLfHTuekFyBG4 7/aIMv7Bv52PoDWBcx9hkFQxF8w4uwiut6nYqvp00LVtUBIFKgfNBpYMaJK+ol0gtwvR YyE8CeNpv5httBGnlZW1NWql0b9hFI86iCD0u+ygRHx6uUrdoFrShxbMa+mdh2piFtzF wATkKOn7P1jONMRew4QTTXLMjgrd4QmUIjnAA9QaUL0mW8OU3+Jydhx+GF8XEo+KB4CZ wp+r9OgTYIecfU74BvaszNNpqy/YGDjuW7wKcB28+SIRvREO9facoRQtqBM2QZz3LfdG UMbQ== X-Gm-Message-State: AJaThX7A76T3ah6N7zJZPSUK5TzRi+HPpr8tu7AGW7V4SxnBxSVMLixW kA5Z+w++z+75DGj8gj3EWYmN4Q== X-Google-Smtp-Source: AGs4zMZTGSQFYqpRiQYR5rmK6MZPfU2KFINUUh8orUBOUghZBLpeqfnGLE7HxJ3VODfFNv4CtkitgQ== X-Received: by 10.107.23.4 with SMTP id 4mr1772206iox.129.1510904799443; Thu, 16 Nov 2017 23:46:39 -0800 (PST) Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id m67sm1756925itm.16.2017.11.16.23.46.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 16 Nov 2017 23:46:38 -0800 (PST) From: Alex To: Eli Zaretskii Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. References: <83fvrgaxrp.fsf@gnu.org> Date: Fri, 17 Nov 2017 01:46:36 -0600 In-Reply-To: <83fvrgaxrp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 01 Nov 2013 18:32:10 +0200") Message-ID: <87k1yp4aar.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 15783 Cc: =?utf-8?B?5qSO6YeOIOijleaouQ==?= , 15783@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Eli Zaretskii writes: >> From: =E6=A4=8E=E9=87=8E =E8=A3=95=E6=A8=B9 >> >> Date: Fri, 1 Nov 2013 23:49:00 +0900 >>=20 >> On Emacs 24 with non-nil header-line-format, y offset returned by >> `posn-at-point' is relative to the text area *not including the header >> line*. However, `posn-at-x-y' takes y offset relative to the buffer >> area *including the header line*. >>=20 >> Is this by design? > > Yes. > >> When I get the position by `posn-at-point', and then convert the >> position to the point by `posn-at-x-y', the resulting point does not >> match the point given to `posn-at-point'. > > You should test for non-nil header-line-format, and adjust the value > accordingly. > >> On Emacs 22 and 23, both functions are relative to the buffer area >> including the header line. It's fine. > > That caused much more grave bugs. What kind of bugs did it cause? It's pretty jarring to have the following return nil when a header-line is present: (let ((x-y (posn-x-y (posn-at-point)))) (equal x-y (posn-x-y (posn-at-x-y (car x-y) (cdr x-y))))) I noticed this since an Emacs package uses posn-x-y and posn-at-x-y to try to preserve the point's screen coordinates before and after a scroll. With a header-line, this puts the point one row too high. It should probably just let-bind `scroll-preserve-screen-position', right? Still, the above is pretty counterintuitive. If nothing else, I think this incompatibility should be highlighted. P.S. I noticed that the manual for `posn-at-x-y' states that the WHOLE argument affects both X and Y, but the docstring only states that X is affected. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 17 04:33:11 2017 Received: (at 15783) by debbugs.gnu.org; 17 Nov 2017 09:33:11 +0000 Received: from localhost ([127.0.0.1]:44241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFd1L-0008IH-GB for submit@debbugs.gnu.org; Fri, 17 Nov 2017 04:33:11 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFd1K-0008I4-I1 for 15783@debbugs.gnu.org; Fri, 17 Nov 2017 04:33:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFd1C-0000e1-7x for 15783@debbugs.gnu.org; Fri, 17 Nov 2017 04:33:05 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFd1C-0000dT-4C; Fri, 17 Nov 2017 04:33:02 -0500 Received: from [176.228.60.248] (port=2815 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFd1B-0004u4-H4; Fri, 17 Nov 2017 04:33:01 -0500 Date: Fri, 17 Nov 2017 11:32:45 +0200 Message-Id: <83zi7lgshu.fsf@gnu.org> From: Eli Zaretskii To: Alex In-reply-to: <87k1yp4aar.fsf@gmail.com> (message from Alex on Fri, 17 Nov 2017 01:46:36 -0600) Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Alex > Cc: 椎野 裕樹 , > 15783@debbugs.gnu.org > Date: Fri, 17 Nov 2017 01:46:36 -0600 > > >> On Emacs 22 and 23, both functions are relative to the buffer area > >> including the header line. It's fine. > > > > That caused much more grave bugs. > > What kind of bugs did it cause? See bug#7390, for example. > It's pretty jarring to have the following return nil when a > header-line is present: > > (let ((x-y (posn-x-y (posn-at-point)))) > (equal x-y (posn-x-y (posn-at-x-y (car x-y) > (cdr x-y))))) It's less than ideal, but the alternatives are worse. > I noticed this since an Emacs package uses posn-x-y and posn-at-x-y to > try to preserve the point's screen coordinates before and after a > scroll. With a header-line, this puts the point one row too high. > > It should probably just let-bind `scroll-preserve-screen-position', > right? Probably. > Still, the above is pretty counterintuitive. If nothing else, I > think this incompatibility should be highlighted. Not sure what "highlighted" means in this context. What are you suggesting in practice? > P.S. I noticed that the manual for `posn-at-x-y' states that the WHOLE > argument affects both X and Y, but the docstring only states that X is > affected. Feel free to fix such discrepancies without any discussion, and thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 18 01:35:41 2017 Received: (at 15783) by debbugs.gnu.org; 18 Nov 2017 06:35:41 +0000 Received: from localhost ([127.0.0.1]:45506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFwj7-0002xE-7W for submit@debbugs.gnu.org; Sat, 18 Nov 2017 01:35:41 -0500 Received: from mail-it0-f44.google.com ([209.85.214.44]:46975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFwj6-0002x0-2O for 15783@debbugs.gnu.org; Sat, 18 Nov 2017 01:35:40 -0500 Received: by mail-it0-f44.google.com with SMTP id r127so6589469itb.5 for <15783@debbugs.gnu.org>; Fri, 17 Nov 2017 22:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=By3BD57VV5+R+2GJ67UXc96z8+Vvt8bLLZccrw+DJFY=; b=Hn5NBZgWoFGIYPakN+v2ixt5urMO4ur+pDdTq/4BM4HSquY02QuX62fX6Ji3jJ/kRj l8tFEbu/pyLfO5HfdD618UIs/9OV4GSta12ZQ9m2kpyoG9fpiIOXBhXBz72bNU3Xr0kr QTZsHC5Ka9c0enJHeLLg8mU3zMis7jGtm6Q8Q/w+/EW+K9Mjx3/Sw+g/GF9aCNvlnRYZ scNg/6QxRLj0VPR+apexn4trQfhIZ9EKWf5zDUIwk6ofn+tA10yVTX/jvLBDtYK38nMz p9RpiXtGATeHu6juqv/TRH7KhqBQOu8PfyezMKH9iReGLQJ/4veZmc4ydTy3/IaLK9EY hvgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=By3BD57VV5+R+2GJ67UXc96z8+Vvt8bLLZccrw+DJFY=; b=LZGdyvs0p03TumyVzcR8HOS8v4ekL0cn2kNQNtHNf/aKnba10BlZGKKjmsSrejQ7bw caFVmZZEVJpmuUhg32REJoNZtvO0c3j7DXwQps6Fh3bV+v6q0RaCG3EAMrD8tTuhsFsK DnZp5cmHs5Irmtz/qM+O8Il9KLkx/bp95vFVz2jFXDb90g5WQyXyT44xHDVFQzKZXJZj 99peRpSKyk9bn1YyzU/0WQtK1lY3HKg7YYF2uabYoGNSsrmSMkJiRJlKUFhfIfyY4Ly/ VTOKB1aPWVwMTeEOQQWJ3Oi602PZGA4fSc9eqtPf83Mh5zAImwzuqsbQuTLsBFaCqMec EXfg== X-Gm-Message-State: AJaThX4WfSPmKRoLob+TR4zpUhUBgAbSIBlHI0STQWzeP8aNAPXa0fGW dtWkJdEfZUFQ4uiRoZ5EHJnGYA== X-Google-Smtp-Source: AGs4zMY2JPxVJxxrJb1h4mBBg6xP/TnaJyt8Kcm9On1AiAvQsRWjqrlR2k7dIKqqaspYhmSShhdCxQ== X-Received: by 10.36.176.9 with SMTP id d9mr4553374itf.125.1510986934007; Fri, 17 Nov 2017 22:35:34 -0800 (PST) Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id y132sm2546677ioy.69.2017.11.17.22.35.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Nov 2017 22:35:32 -0800 (PST) From: Alex To: Eli Zaretskii Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> Date: Sat, 18 Nov 2017 00:35:27 -0600 In-Reply-To: <83zi7lgshu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 Nov 2017 11:32:45 +0200") Message-ID: <87mv3kqekw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> What kind of bugs did it cause? > > See bug#7390, for example. > >> It's pretty jarring to have the following return nil when a >> header-line is present: >> >> (let ((x-y (posn-x-y (posn-at-point)))) >> (equal x-y (posn-x-y (posn-at-x-y (car x-y) >> (cdr x-y))))) > > It's less than ideal, but the alternatives are worse. I don't understand. The bug above seems to be about posn-col-row rather than posn(-at)-x-y. What alternatives were considered, and how were they worse? >> Still, the above is pretty counterintuitive. If nothing else, I >> think this incompatibility should be highlighted. > > Not sure what "highlighted" means in this context. What are you > suggesting in practice? I was thinking about mentioning that you can't expect Elisp code such as the above to always be true. >> P.S. I noticed that the manual for `posn-at-x-y' states that the WHOLE >> argument affects both X and Y, but the docstring only states that X is >> affected. > > Feel free to fix such discrepancies without any discussion, and > thanks. Hmm, it appears that they're both wrong. I believe this is the breakdown: 1. Manual: WHOLE is nil: X and Y are relative to the text area WHOLE is non-nil: X and Y are relative to the window area 2. Docstring: WHOLE is nil: X and Y are relative to the text area WHOLE is non-nil: X is relative to window area; Y to text area 3. Actual: WHOLE is nil: X is relative to text area; Y to window area WHOLE is non-nil: X and Y are relative to the window area The behaviour in #1 makes the most sense to me, and I believe that was the behaviour before Emacs 24. Any change of reverting to the behaviour to #1, or should the documentation just be updated to #3? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 18 03:40:25 2017 Received: (at 15783) by debbugs.gnu.org; 18 Nov 2017 08:40:26 +0000 Received: from localhost ([127.0.0.1]:45532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFyfp-0006gU-G6 for submit@debbugs.gnu.org; Sat, 18 Nov 2017 03:40:25 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFyfn-0006gH-2m for 15783@debbugs.gnu.org; Sat, 18 Nov 2017 03:40:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFyfe-0002w1-JP for 15783@debbugs.gnu.org; Sat, 18 Nov 2017 03:40:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFyfe-0002vt-AT; Sat, 18 Nov 2017 03:40:14 -0500 Received: from [176.228.60.248] (port=4223 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFyfd-0000Dd-J7; Sat, 18 Nov 2017 03:40:14 -0500 Date: Sat, 18 Nov 2017 10:40:00 +0200 Message-Id: <837euogeu7.fsf@gnu.org> From: Eli Zaretskii To: Alex In-reply-to: <87mv3kqekw.fsf@gmail.com> (message from Alex on Sat, 18 Nov 2017 00:35:27 -0600) Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> <87mv3kqekw.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Alex > Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org > Date: Sat, 18 Nov 2017 00:35:27 -0600 > > >> It's pretty jarring to have the following return nil when a > >> header-line is present: > >> > >> (let ((x-y (posn-x-y (posn-at-point)))) > >> (equal x-y (posn-x-y (posn-at-x-y (car x-y) > >> (cdr x-y))))) > > > > It's less than ideal, but the alternatives are worse. > > I don't understand. The bug above seems to be about posn-col-row rather > than posn(-at)-x-y. What alternatives were considered, and how were > they worse? I think you didn't read all of the discussion that followed. The original bug report was about posn-col-row, but the underlying basic issue is deeper. The basic issue is the origin from which posn-at-x-y and posn-at-point count their values. There are two classes of callers for these functions: those which start with mouse clicks, and those which start with buffer positions. They have basically different needs, but both classes don't want to have special application-level code that accounts for the header line, if it is present. So we changed the primitives to cater to each class in the respective function: posn-at-x-y caters to those which deal with mouse clicks, and posn-at-point caters to the other kind. For the details, see commit 9173a8f. > >> Still, the above is pretty counterintuitive. If nothing else, I > >> think this incompatibility should be highlighted. > > > > Not sure what "highlighted" means in this context. What are you > > suggesting in practice? > > I was thinking about mentioning that you can't expect Elisp code such as > the above to always be true. Fine with me, but can you propose a patch for the documentation to do that? > Hmm, it appears that they're both wrong. I believe this is the > breakdown: > > 1. Manual: > WHOLE is nil: X and Y are relative to the text area > WHOLE is non-nil: X and Y are relative to the window area > > 2. Docstring: > WHOLE is nil: X and Y are relative to the text area > WHOLE is non-nil: X is relative to window area; Y to text area > > 3. Actual: > WHOLE is nil: X is relative to text area; Y to window area > WHOLE is non-nil: X and Y are relative to the window area This is the same confusion about what "text area" means that is present in many of our conversations. The manual says: ‘Text Area’ The “text area” of a frame is a somewhat fictitious area that can be embedded in the native frame. Its position is unspecified. Its width can be obtained by removing from that of the native width the widths of the internal border, one vertical scroll bar, and one left and one right fringe if they are specified for this frame, see *note Layout Parameters::. Its height can be obtained by removing from that of the native height the widths of the internal border and the heights of the frame’s internal menu and tool bars and one horizontal scroll bar if specified for this frame. This means the "text area" _includes_ the header line. So when you get this result in "emacs -Q": M-: (setq header-line-format "Hi There") RET M-: (posn-at-x-y 0 0) => (# header-line (8 . 0) 0 ("Hi There" . 1) nil (1 . -1) nil (0 . 0) (8 . 16)) it tells you that the origin is the left corner of the text area, because the X coordinate is 8, not zero, and the position in the header-line string is 1, not zero. If, OTOH, you invoke posn-at-x-y with last argument non-nil, you will get zero for X, which means the origin is the left corner of the window, which is at the left edge of the left fringe. Therefore, the doc string is accurately describing the actual behavior. Do you agree now? > The behaviour in #1 makes the most sense to me, and I believe that was > the behaviour before Emacs 24. That behavior required features that used mouse clicks as input and then looked for the corresponding buffer positions to account for the header line in application code, which caused the bugs discussed in the thread I pointed to. > Any change of reverting to the behaviour to #1, or should the > documentation just be updated to #3? We are not going back. The current behavior, while less than ideal, caused zero bugs since it was introduced, AFAIK. The documentation should be updated, of course (I see that the above-mentioned commit didn't do that, which is probably why the old description survived to this day). Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 22 19:27:49 2021 Received: (at 15783) by debbugs.gnu.org; 22 Oct 2021 23:27:49 +0000 Received: from localhost ([127.0.0.1]:33932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1me3wz-0004aY-1t for submit@debbugs.gnu.org; Fri, 22 Oct 2021 19:27:49 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:36834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1me3wv-0004aE-9B for 15783@debbugs.gnu.org; Fri, 22 Oct 2021 19:27:47 -0400 Received: by mail-pl1-f179.google.com with SMTP id f4so1054021plt.3 for <15783@debbugs.gnu.org>; Fri, 22 Oct 2021 16:27:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=2GNDGPCgS2N8iwlXNbAKwaisYI+opPFCpoD76QyaoU4=; b=BStK4uoV4b+bNWPJWRmB+23mnZzWD8u7sZP0OEW7zONqtAJfPaa/XIeNJENh06uYcE 2K5ni9I+cqMlr/N4eMNUbt6iRf3F66O75AreMQVoxxZuq7Xw2jYpXcMZbozlr8n0X6N/ gj5pGlcbS3su3pWK6mnkP/MvyGoHChcJoQB5dUgkargPcsjGZkuqScg+uxmcGCw/KKq7 TET8WbJHXI9Z2Do4f8fsjGvrbO/xkTZVFolUYSdUIBwj0WeS/3hx7/feR74buKl6wixe 7QC/yKuzYtEFE4qOnm/yafB3OBMVOjnYSilsKyrRHCopzV9x6JHJ6nJwj4mZyLjRgPdH E86A== X-Gm-Message-State: AOAM532ISMQwykUaOxepMU3kw9Txvs1ayD0O9cz75gFpDEGlEqwcr8pU /U/8gQu838XDdPPXb0YVVCoVSHrp4fddqcBtCZk= X-Google-Smtp-Source: ABdhPJyeo13BFeaLAdEcA148L6q6qfhOcFGLGwKkxdRKwPKqBfELdb+usucKMISw5Gwnn7W/ZCK954dXdOb7pMcWE7E= X-Received: by 2002:a17:90a:245:: with SMTP id t5mr3078162pje.133.1634945259553; Fri, 22 Oct 2021 16:27:39 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Oct 2021 19:27:38 -0400 From: Stefan Kangas In-Reply-To: <837euogeu7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Nov 2017 10:40:00 +0200") References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> <87mv3kqekw.fsf@gmail.com> <837euogeu7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Date: Fri, 22 Oct 2021 19:27:38 -0400 Message-ID: Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000006c696e05cef95b04" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org, Alex X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --0000000000006c696e05cef95b04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable tags 15783 + patch thanks Eli Zaretskii writes: >> 3. Actual: >> WHOLE is nil: X is relative to text area; Y to window area >> WHOLE is non-nil: X and Y are relative to the window area > > This is the same confusion about what "text area" means that is > present in many of our conversations. The manual says: > > =E2=80=98Text Area=E2=80=99 > The =E2=80=9Ctext area=E2=80=9D of a frame is a somewhat fictitiou= s area that can > be embedded in the native frame. Its position is unspecified. It= s > width can be obtained by removing from that of the native width th= e > widths of the internal border, one vertical scroll bar, and one > left and one right fringe if they are specified for this frame, se= e > *note Layout Parameters::. Its height can be obtained by removing > from that of the native height the widths of the internal border > and the heights of the frame=E2=80=99s internal menu and tool bars= and one > horizontal scroll bar if specified for this frame. > > This means the "text area" _includes_ the header line. So when you > get this result in "emacs -Q": > > M-: (setq header-line-format "Hi There") RET > M-: (posn-at-x-y 0 0) > =3D> (# header-line (8 . 0) 0 ("Hi There" . 1) = nil (1 . -1) nil (0 . 0) (8 . 16)) > > it tells you that the origin is the left corner of the text area, > because the X coordinate is 8, not zero, and the position in the > header-line string is 1, not zero. If, OTOH, you invoke posn-at-x-y > with last argument non-nil, you will get zero for X, which means the > origin is the left corner of the window, which is at the left edge of > the left fringe. > > Therefore, the doc string is accurately describing the actual behavior. > Do you agree now? I looked into this for a bit, and as far as I understand, Eli is correct. > We are not going back. The current behavior, while less than ideal, > caused zero bugs since it was introduced, AFAIK. The documentation > should be updated, of course (I see that the above-mentioned commit > didn't do that, which is probably why the old description survived to > this day). How does the attached patch look? --0000000000006c696e05cef95b04 Content-Type: text/x-diff; charset="US-ASCII"; name="0001-Fix-documentation-of-posn-at-x-y.patch" Content-Disposition: attachment; filename="0001-Fix-documentation-of-posn-at-x-y.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: be8e76c7583f70c1_0.1 RnJvbSAyMGQ1NTViZmY3OGRlOThhNGNkZTdjMDRmYTI0YjY4OGIyYTFkNWNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVmYW4gS2FuZ2FzIDxzdGVmYW5AbWFyeGlzdC5zZT4KRGF0 ZTogU2F0LCAyMyBPY3QgMjAyMSAwMToxOTo0OCArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBk b2N1bWVudGF0aW9uIG9mIHBvc24tYXQteC15CgoqIGRvYy9saXNwcmVmL2NvbW1hbmRzLnRleGkg KEFjY2Vzc2luZyBNb3VzZSk6IEZpeCBkb2N1bWVudGF0aW9uIG9mCidwb3NuLWF0LXgteScgdG8g bWF0Y2ggZG9jc3RyaW5nLiAgKEJ1ZyMxNTc4MykKLS0tCiBkb2MvbGlzcHJlZi9jb21tYW5kcy50 ZXhpIHwgOSArKysrKy0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDQgZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZG9jL2xpc3ByZWYvY29tbWFuZHMudGV4aSBiL2RvYy9s aXNwcmVmL2NvbW1hbmRzLnRleGkKaW5kZXggMzQyNTg4MGZlYy4uNmM4NTNhM2QyMyAxMDA2NDQK LS0tIGEvZG9jL2xpc3ByZWYvY29tbWFuZHMudGV4aQorKysgYi9kb2MvbGlzcHJlZi9jb21tYW5k cy50ZXhpCkBAIC0yMzU0LDEwICsyMzU0LDExIEBAIEFjY2Vzc2luZyBNb3VzZQogY29vcmRpbmF0 ZXMgQHZhcnt4fSBhbmQgQHZhcnt5fSBpbiBhIHNwZWNpZmllZCBmcmFtZSBvciB3aW5kb3csCiBA dmFye2ZyYW1lLW9yLXdpbmRvd30sIHdoaWNoIGRlZmF1bHRzIHRvIHRoZSBzZWxlY3RlZCB3aW5k b3cuCiBUaGUgY29vcmRpbmF0ZXMgQHZhcnt4fSBhbmQgQHZhcnt5fSBhcmUgcmVsYXRpdmUgdG8g dGhlCi1mcmFtZSBvciB3aW5kb3cgdXNlZC4KLUlmIEB2YXJ7d2hvbGV9IGlzIEBjb2Rle25pbH0s IHRoZSBjb29yZGluYXRlcyBhcmUgcmVsYXRpdmUKLXRvIHRoZSB3aW5kb3cgdGV4dCBhcmVhLCBv dGhlcndpc2UgdGhleSBhcmUgcmVsYXRpdmUgdG8KLXRoZSBlbnRpcmUgd2luZG93IGFyZWEgaW5j bHVkaW5nIHNjcm9sbCBiYXJzLCBtYXJnaW5zIGFuZCBmcmluZ2VzLgordGV4dCBhcmVhIG9mIHRo ZSBzZWxlY3RlZCB3aW5kb3cuCitJZiBAdmFye3dob2xlfSBpcyBAY29kZXtuaWx9LCB0aGUgQHZh cnt4fSBjb29yZGluYXRlIGlzIHJlbGF0aXZlIHRvCit0aGUgZW50aXJlIHdpbmRvdyBhcmVhIGlu Y2x1ZGluZyBzY3JvbGwgYmFycywgbWFyZ2lucyBhbmQgZnJpbmdlcywKK3doaWxlIHRoZSBAdmFy e3l9IGNvb3JkaW5hdGUgcmVtYWlucyB1bmNoYW5nZWQgYW5kIHJlbGF0aXZlIHRvIHRoZQordGV4 dCBhcmVhLgogQGVuZCBkZWZ1bgogCiBAbm9kZSBBY2Nlc3NpbmcgU2Nyb2xsCi0tIAoyLjMwLjIK Cg== --0000000000006c696e05cef95b04-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 02:49:49 2021 Received: (at 15783) by debbugs.gnu.org; 23 Oct 2021 06:49:49 +0000 Received: from localhost ([127.0.0.1]:34218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meAqh-0001Qt-V7 for submit@debbugs.gnu.org; Sat, 23 Oct 2021 02:49:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meAqT-0001QS-IV for 15783@debbugs.gnu.org; Sat, 23 Oct 2021 02:49:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52960) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meAqO-0001MA-0f; Sat, 23 Oct 2021 02:49:28 -0400 Received: from [87.69.77.57] (port=3430 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meAqN-0000lS-Dx; Sat, 23 Oct 2021 02:49:27 -0400 Date: Sat, 23 Oct 2021 09:49:13 +0300 Message-Id: <83wnm45j86.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Fri, 22 Oct 2021 19:27:38 -0400) Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> <87mv3kqekw.fsf@gmail.com> <837euogeu7.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org, agrambot@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Fri, 22 Oct 2021 19:27:38 -0400 > Cc: Alex , shiino.yuki@gmail.com, 15783@debbugs.gnu.org > > > Therefore, the doc string is accurately describing the actual behavior. > > Do you agree now? > > I looked into this for a bit, and as far as I understand, Eli is > correct. > > > We are not going back. The current behavior, while less than ideal, > > caused zero bugs since it was introduced, AFAIK. The documentation > > should be updated, of course (I see that the above-mentioned commit > > didn't do that, which is probably why the old description survived to > > this day). > > How does the attached patch look? Yes, but with one correction: > --- a/doc/lispref/commands.texi > +++ b/doc/lispref/commands.texi > @@ -2354,10 +2354,11 @@ Accessing Mouse > coordinates @var{x} and @var{y} in a specified frame or window, > @var{frame-or-window}, which defaults to the selected window. > The coordinates @var{x} and @var{y} are relative to the > -frame or window used. > -If @var{whole} is @code{nil}, the coordinates are relative > -to the window text area, otherwise they are relative to > -the entire window area including scroll bars, margins and fringes. > +text area of the selected window. > +If @var{whole} is @code{nil}, the @var{x} coordinate is relative to ^^^^^^^^^^^^^^^^^^^^^^^^^ You mean, non-nil, right? > +the entire window area including scroll bars, margins and fringes, > +while the @var{y} coordinate remains unchanged and relative to the > +text area. And I wouldn't mention what WHOLE does to Y, because it just confuses things. Y remains unchanged simply because there are no window decorations that affect Y coordinates, but there's no need to tell that in a doc string; if we say nothing about Y, it still tells that Y is unchanged. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 03:47:49 2021 Received: (at 15783) by debbugs.gnu.org; 23 Oct 2021 07:47:50 +0000 Received: from localhost ([127.0.0.1]:34275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meBkr-00052N-GZ for submit@debbugs.gnu.org; Sat, 23 Oct 2021 03:47:49 -0400 Received: from mail-pg1-f174.google.com ([209.85.215.174]:38792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meBkp-00051Y-Ak for 15783@debbugs.gnu.org; Sat, 23 Oct 2021 03:47:47 -0400 Received: by mail-pg1-f174.google.com with SMTP id e65so5491558pgc.5 for <15783@debbugs.gnu.org>; Sat, 23 Oct 2021 00:47:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=kvNn6i6MEP/DdgeNfEmeCVd9WGnJgDoGQGvfxoZTgg4=; b=gt4W5YzTSAO6R9ei3308RjWFBfNA+LyNqbMM1ZZvTf71DXDIeFUK4gzSx+QmNQkJgD hc/w4quBKy0Rba3jK9+RrKWWy5MAsonf4/jJhSpTvPdkf5KeRNIQeZ5lW/6Hkn+smG17 hlww1G2pn1J/z58AkXh1rtfyhSIS0SdSDmh+zHE0uc/99ldLkjp+MHvS0JBRI+BNsDBD PAOh8jGLk/YZfdBVnZcCAEarg8U9RqiJLAhA9ikOsTkFPn9ehdx/z1QyfJJN062+62tB Jx3hMXZbzrWZYDyL+H26XE2mIw+l7gVXM6AbhJvUcYvjWnKn/sbeiE8i78VjIs9cW8c7 tDgw== X-Gm-Message-State: AOAM530U5bsdXOUJI+KymNDhn7RniXWHrEBlnwoVXt/q4gWO0OtZ3gKP 5/8X13gROOrZd11tQco8rqfCk0DNwfbHHo0afZI= X-Google-Smtp-Source: ABdhPJyyLZJSRleEpKg85Y0S9/23E3lC+nb1WSAZiBAZM2IG48r3SCJquRHd8Ihl5CJE0TmMwxdmHhaRlXwr99KfIDw= X-Received: by 2002:a05:6a00:1950:b0:44d:9402:3396 with SMTP id s16-20020a056a00195000b0044d94023396mr4965345pfk.70.1634975260430; Sat, 23 Oct 2021 00:47:40 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 23 Oct 2021 00:47:39 -0700 From: Stefan Kangas In-Reply-To: <83wnm45j86.fsf@gnu.org> References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> <87mv3kqekw.fsf@gmail.com> <837euogeu7.fsf@gnu.org> <83wnm45j86.fsf@gnu.org> MIME-Version: 1.0 Date: Sat, 23 Oct 2021 00:47:39 -0700 Message-ID: Subject: Re: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 15783 Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org, agrambot@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) close 15783 28.1 thanks Eli Zaretskii writes: >> How does the attached patch look? > > Yes, but with one correction: > >> --- a/doc/lispref/commands.texi >> +++ b/doc/lispref/commands.texi >> @@ -2354,10 +2354,11 @@ Accessing Mouse >> coordinates @var{x} and @var{y} in a specified frame or window, >> @var{frame-or-window}, which defaults to the selected window. >> The coordinates @var{x} and @var{y} are relative to the >> -frame or window used. >> -If @var{whole} is @code{nil}, the coordinates are relative >> -to the window text area, otherwise they are relative to >> -the entire window area including scroll bars, margins and fringes. >> +text area of the selected window. >> +If @var{whole} is @code{nil}, the @var{x} coordinate is relative to > ^^^^^^^^^^^^^^^^^^^^^^^^^ > You mean, non-nil, right? Yes, good spot. >> +the entire window area including scroll bars, margins and fringes, >> +while the @var{y} coordinate remains unchanged and relative to the >> +text area. > > And I wouldn't mention what WHOLE does to Y, because it just confuses > things. Y remains unchanged simply because there are no window > decorations that affect Y coordinates, but there's no need to tell > that in a doc string; if we say nothing about Y, it still tells that Y > is unchanged. Thanks, I removed that and pushed it to emacs-28 as commit cdbd03345d. I'm therefore closing this bug report. From unknown Thu Aug 14 12:24:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 20 Nov 2021 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator