window-at / window-edges inconsistency

window-at / window-edges inconsistency

[Jesse Byler]

Background: I've been trying to debug several problems with the
windmove package in current CVS emacs.  One particular problem I've
traced to a change in the way the window-at function behaves.  The
change occurred on May 24, 2003, when a significant overhaul was done
to the way window and frame coordinates are handled.  The new system
is cleaner and more powerful but I suspect there may be some bugs.

The window-edges function returns a list of the edge coordinates of a
window in frame-relative character coordinates.  If multiple windows
exist in a frame, the bounding boxes described by window-edges for the
various windows are adjacent, even when scroll bars and fringes are
present, because window-edges includes scroll bars and fringes as part
of the window.  This is expected and has not changed.

The window-at function also takes frame-relative character
coordinates, and returns the window those coordinates are in.  Prior
to May 24, the behavior of window-at was [mostly] consistent with that
of window-edges, but after May 24, the behavior became inconsistent.

The details before May 24: If window-edges for a window returns (x0 y0
x1 y1), then calling (window-at x0 y0) returns the window, (window-at
(- x1 1) (- y1 1)) returns the same window, and (window-at x1 (- y1
1)) returns the adjacent window to the right.  This seems to be the
expected behavior given the documentation.

After May 24, (window-at x0 y0) returns nil in most cases, which seems
non-intuitive to me, as well as being inconsistent with previous
behavior.  In addition, although the window-edges bounding boxes of
two adjacent windows are adjacent (i.e. there is no gap between the
windows), testing with window-at shows that several columns exist
between the two windows where window-at returns nil.  Prior to May 24,
the function coordinates-in-window-p would return 'left-fringe for
these coordinates, indicating that they are not in the text portion of
the window but are nevertheless in the fringe of the window.  After
may 24, coordinates-in-window-p returns nil for these "gap"
coordinates.

Side note on the "[mostly]" from above: Even before May 24 there may
have been some bugs.  I observe that (window-at x0 y1) hits the
window, even though those coordinates should be off the bottom of the
window.  This creates an overlapping window situation, where the
coordinates x0 y1 are in both the window in question and the adjacent
window downward.

Thanks,
Jesse Byler