[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: windmove and the minibuffer

From: Luc Teirlinck
Subject: Re: windmove and the minibuffer
Date: Sat, 31 May 2003 18:16:49 -0500 (CDT)

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

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.


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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]