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

Previous Next

Full log

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.