bug#15783: 24.3; posn-at-x-y is relative to the buffer area, posn-at-point is relative to the text area.

[Alex]

Eli Zaretskii <eliz@gnu.org> 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?