GNU bug report logs - #214
Bugs in window-at and coordinates-in-window-p built-in functions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 214 in the body.
You can then email your comments to 214 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Hill, Gregory" <ghill <at> mc.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: Bugs in window-at and coordinates-in-window-p built-in functions
Date: Fri, 9 May 2008 13:32:40 -0400

GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on RELEASE
 
Use split-window-vertically once and split-window-horizontally twice to
create a frame that is split into 4 approximately equal sections (2 x
2).
 
Display a different buffer in each of the 4 windows.
 
Move the cursor to anywhere in the lower-right window.
 
Use eval-expression to execute the following expression:

 (let* ((edges (window-edges))
       (x (first edges))
       (y (1- (second edges))))
  (window-at x y))

Logically, this should return the upper-right window, but it actually
returns the upper-left window.

Possibly related to this bug, execute the following expression with the
cursor in any window:

(let* ((edges (window-edges))
       (x (first edges))
       (y (second edges))
       (window (selected-window)))
  (coordinates-in-window-p (cons x y) window))

Logically this should return (0 . 0) but it actually returns
'left-fringe.

Execute the following expression with the cursor in the lower-right
window:

(let* ((edges (window-edges))
       (x (first edges))
       (y (1- (second edges)))
       (window (window-at x y))) 
  (coordinates-in-window-p (cons x y) window))

It returns 'vertical-line when it should really return 'mode-line.  The
same expression evaluated with the cursor in the lower-left window
returns 'mode-line as it should.

Message #10 received at 214 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 214 <at> debbugs.gnu.org
Cc: ghill <at> mc.com
Subject: Re: Bugs in window-at and coordinates-in-window-p built-in functions
Date: Sat, 02 Aug 2008 21:07:52 +0200

Thank you for your report.  Sorry for the late response.

> Use split-window-vertically once and split-window-horizontally twice to
> create a frame that is split into 4 approximately equal sections (2 x
> 2).
>
> Display a different buffer in each of the 4 windows.
>
> Move the cursor to anywhere in the lower-right window.
>
> Use eval-expression to execute the following expression:
>
>  (let* ((edges (window-edges))
>        (x (first edges))
>        (y (1- (second edges))))
>   (window-at x y))
>
> Logically, this should return the upper-right window, but it actually
> returns the upper-left window.

The position is exactly at the border between two windows and the fact
that you "are" in the lower-right window is irrelevant when `window-at'
is evaluated.  Maybe `window-at' should refuse to return _any_ window in
this case, but expecting a correct result from `window-at' at a border
between two windows is not quite fair in the first place.

> Possibly related to this bug, execute the following expression with the
> cursor in any window:
>
> (let* ((edges (window-edges))
>        (x (first edges))
>        (y (second edges))
>        (window (selected-window)))
>   (coordinates-in-window-p (cons x y) window))
>
> Logically this should return (0 . 0) but it actually returns
> 'left-fringe.

Because your window is probably displaying a fringe.  Remove the fringe
and it will return (0 . 0).  Anyway, this is not related to the above
behavior.

> Execute the following expression with the cursor in the lower-right
> window:
>
> (let* ((edges (window-edges))
>        (x (first edges))
>        (y (1- (second edges)))
>        (window (window-at x y)))
>   (coordinates-in-window-p (cons x y) window))
>
> It returns 'vertical-line when it should really return 'mode-line.  The
> same expression evaluated with the cursor in the lower-left window
> returns 'mode-line as it should.

Indirectly, this is the cause of the behavior you observed.

The "vertical-line" is that small vertical line between the mode lines
of two adjacent windows (you can use it to resize windows horizontally
with the mouse).  Hence, the return value is correct, but the doc-string
of `coordinates-in-window-p' could be improved - most people hardly know
what a "sibling" is in this context and 'vertical-line is returned in a
few other cases as well.

martin

Previous Next

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