From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area. Date: Sat, 18 Nov 2017 10:40:00 +0200 Message-ID: <837euogeu7.fsf@gnu.org> References: <83fvrgaxrp.fsf@gnu.org> <87k1yp4aar.fsf@gmail.com> <83zi7lgshu.fsf@gnu.org> <87mv3kqekw.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1510994472 18777 195.159.176.226 (18 Nov 2017 08:41:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Nov 2017 08:41:12 +0000 (UTC) Cc: shiino.yuki@gmail.com, 15783@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 18 09:41:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFygT-0004SP-4X for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Nov 2017 09:41:05 +0100 Original-Received: from localhost ([::1]:49176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFyga-0006Fb-Bf for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Nov 2017 03:41:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFygT-0006FT-AE for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 03:41:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFygQ-0003Ss-4M for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 03:41:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36851) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eFygQ-0003Sg-1C for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 03:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eFygP-0006hP-Qr for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 03:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2017 08:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15783-submit@debbugs.gnu.org id=B15783.151099442625702 (code B ref 15783); Sat, 18 Nov 2017 08:41:01 +0000 Original-Received: (at 15783) by debbugs.gnu.org; 18 Nov 2017 08:40:26 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: <87mv3kqekw.fsf@gmail.com> (message from Alex on Sat, 18 Nov 2017 00:35:27 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:140042 Archived-At: > 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.