[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-poi
From: |
Stefan Kangas |
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: |
Fri, 22 Oct 2021 19:27:38 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
tags 15783 + patch
thanks
Eli Zaretskii <eliz@gnu.org> 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:
>
> ‘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)
> => (#<window 3 on *scratch*> 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?
0001-Fix-documentation-of-posn-at-x-y.patch
Description: Text Data
- bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area.,
Stefan Kangas <=