Re: windmove and the minibuffer

[Luc Teirlinck]

The reason for the bug is that `windmove-find-other-window' passes
coordinates to `window-at' that are both one to small.  (Or is the bug
in `window-at'?  In that case there probably also is a related bug in
`coordinates-in-window-p'.)

Could you (or somebody with access to a Microsoft Windows machine)
repeat the following exercise:

Start emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
 
(The eval is not necessary for people whose neurological system does
not get affected by blinking cursors.)

M-x scroll-bar-mode
M-x fringe-mode
M-x tool-bar-mode
M-x menu-bar-mode

Just to simplify the picture and make sure all that stuff has nothing
to do with the problem.

(window-at 0 15)

Result: nil

(window-at 1 (window-height)) 

Result: #<window 3 on *scratch*>

(window-at 0 (window-height))

Result: nil. 

Unfortunately, with point at the beginning of the scratch buffer,
these are the coordinates that `windmove-find-other-window' passes to
window-at.  Replacing 0 by 1 would get rid of the error message, but
would still leave point in scratch.  Actually, that is what happens
if you move point away from the beginning of the line.

(window-at 1 (1+ (window-height)))

#<window 4 on  *Minibuf-0*>

Obviously, these are the coordinates it should pass.
(or is it `window-at' that gets it wrong?  Its documentation looks
ambiguous to me.)

If any of these results are different on a Microsoft Windows machine,
then that explains the difference in behavior.

Sincerely,

Luc.