Re: windmove and the minibuffer

[Luc Teirlinck <teirllm@dms.auburn.edu>]

>From my previous message:

   This seems strange.  What does it return for you?

Never mind, in the case of Alex I can pretty much guess: (1 . 1), of
course.

>From frame.h:

/* Convert pixel-value X to canonical units.  F is the frame whose
   canonical character width is to be used.  X is a C integer.  Result
   is a Lisp float if X is not a multiple of the canon width,
   otherwise it's a Lisp integer.  */

#define FRAME_CANON_X_FROM_PIXEL_X(F, X)			\
     ((X) % FRAME_COLUMN_WIDTH (F) != 0
     \
      ? make_float ((double) (X) / FRAME_COLUMN_WIDTH (F))	\
      : make_number ((X) / FRAME_COLUMN_WIDTH (F)))

/* Convert pixel-value Y to canonical units.  F is the frame whose
   canonical character height is to be used.  Y is a C integer.
   Result is a Lisp float if Y is not a multiple of the canon width,
   otherwise it's a Lisp integer.  */

#define FRAME_CANON_Y_FROM_PIXEL_Y(F, Y)			\
     ((Y) % FRAME_LINE_HEIGHT (F)
     \
      ? make_float ((double) (Y) / FRAME_LINE_HEIGHT (F))	\
      : make_number ((Y) / FRAME_LINE_HEIGHT (F)))


coordinates-in-window-p uses this.

A logical explanation for the variation in behavior for
coordinates-in-window-p might be that if we wind up working with Lisp
integers everything is OK and otherwise, we get bugs.

Since Alex sees no bug in coordinates-in-window-p, but sees one in
window-at, the two bugs are not necessarily related.  Somebody who
knows the involved C code better than I do should take a look at this.

Sincerely,

Luc.