emacs-devel
[Top][All Lists]

## Re: windmove and the minibuffer

 From: Luc Teirlinck Subject: Re: windmove and the minibuffer Date: Sun, 1 Jun 2003 10:46:28 -0500 (CDT)

```>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.

```