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

Message #28 received at 15783 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: shiino.yuki <at> gmail.com, 15783 <at> debbugs.gnu.org, agrambot <at> gmail.com
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.
Date: Sat, 23 Oct 2021 09:49:13 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Fri, 22 Oct 2021 19:27:38 -0400
> Cc: Alex <agrambot <at> gmail.com>, shiino.yuki <at> gmail.com, 15783 <at> 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.

Previous Next

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