Re: windmove and the minibuffer

[Luc Teirlinck]

Richard Stallman wrote:

       emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
       M-x scroll-bar-mode
       M-x fringe-mode
       M-x tool-bar-mode
       M-x menu-bar-mode

       (coordinates-in-window-p '(0 . 0) (selected-window))

       should not return nil.  But it does, at least on GNU/Linux.

   It returned (0 . 0) when I tried it.

Still returns nil for me in freshly updated CVS Emacs. (I forgot to
mention that one has to simply do RETURN in response to the question
asked by M-x fringe-mode, but that seemed obvious.)

Did you use the Linux or GNU kernel?  (I do not know whether that
should make any difference, but we already know that the problem is
operating system specific.)

Can you reproduce Alex's original bug:

Run emacs -q
M-x windmove-default-keybindings  (After loading windmove, of course.)
C-x C-f (you should be in the minibuffer, now)
S-up (you should be in *scratch*, now)
S-down (I am still in *scratch*, even though I want to be in the
minibuffer)

Alex, what return value do you get for the above form, in the above
situation?  Also which return values do you get, in that same
situation, for:

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

It are mainly the window-at values that are relevant to Alex's
problem, but the coordinates-in-window-p problem is closely related.

I use RedHat7.2.

(emacs-version)

"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2003-05-31 on
swt40.swt.com"

I used:

./configure --without-toolkit-scroll-bars

but one of the purposes of M-x scroll-bar-mode, in the above, was to
make that irrelevant.

Sincerely,

Luc.