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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: shiino.yuki <at> gmail.com, 15783 <at> debbugs.gnu.org
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, 17 Nov 2017 11:32:45 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: 椎野 裕樹 <shiino.yuki <at> gmail.com>,
>   15783 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.