windmove and the minibuffer

windmove and the minibuffer

[Alex Schroeder]

Did anybody note that using windmove (windmove-default-keybindings) no
longer allows you to reach the minibuffer window (using S-down) --
eventhough you can leave the minibuffer window (using S-up)?  I think
this should be possible.

I often need to move back to the minibuffer because I have some
aborted M-x command or similar "hanging" there, and hitting C-g in
other windows will not abort it.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: windmove and the minibuffer

[Juanma Barranquero]

On Mon, 26 May 2003 19:52:38 +0200
Alex Schroeder <alex@gnu.org> wrote:

> Did anybody note that using windmove (windmove-default-keybindings) no
> longer allows you to reach the minibuffer window (using S-down) --
> eventhough you can leave the minibuffer window (using S-up)?

Unless I'm misunderstanding something, I *can* go to the minibuffer and
back with S-down / S-up (H-down / H-up, in fact, that's what I use).


                                                                Juanma

Re: windmove and the minibuffer

[Alex Schroeder]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

> Unless I'm misunderstanding something, I *can* go to the minibuffer and
> back with S-down / S-up (H-down / H-up, in fact, that's what I use).

Weird.  Let me give you an exact script, to see whether your system
really is different:

Run emacs -q
M-x windmove-default-keybindings
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*, eventhough I want to be in the minibuffer)

Alex
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: windmove and the minibuffer

[Juanma Barranquero]

On Tue, 27 May 2003 19:25:08 +0200, Alex Schroeder <alex@gnu.org> wrote:

> Weird.  Let me give you an exact script, to see whether your system
> really is different:
> 
> Run emacs -q
> M-x windmove-default-keybindings
> 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*, eventhough I want to be in the minibuffer)

Yes, I go back to the minibuffer after the S-down.

"This is GNU Emacs 21.3.50.1 (i386-msvc-nt5.1.2600)
of 2003-05-27 on CASA"

(i.e., Emacs from yesterday's CVS HEAD, compiled on Windows XP with
Visual Studio .NET).


                                                           /L/e/k/t/u

Re: windmove and the minibuffer

[Luc Teirlinck]

Juanma Barrranquero wrote:

   On Tue, 27 May 2003 19:25:08 +0200, Alex Schroeder <alex@gnu.org> wrote:

   > Weird.  Let me give you an exact script, to see whether your system
   > really is different:
   > 
   > Run emacs -q
   > M-x windmove-default-keybindings
   > 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*, eventhough I want to be in the minibuffer)

   Yes, I go back to the minibuffer after the S-down.

   "This is GNU Emacs 21.3.50.1 (i386-msvc-nt5.1.2600)
   of 2003-05-27 on CASA"

   (i.e., Emacs from yesterday's CVS HEAD, compiled on Windows XP with
   Visual Studio .NET).

That *is* weird because I can reproduce he bug, in CVS downloaded just
moments ago.  In fact, the following line is from the *Messages*
buffer immediately after the exercise:

windmove-do-window-select: No window at down

It is hard to see why this should be operating system dependent.

(emacs-version)

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

This is RedHat 7.2.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Luc Teirlinck]

Alex Schroeder wrote:

   Did anybody note that using windmove (windmove-default-keybindings) no
   longer allows you to reach the minibuffer window (using S-down) --
   eventhough you can leave the minibuffer window (using S-up)?

The bug does not seem to be extremely recent.  It already occurs in
Emacs21.3.  (The released one, not 21.3.50.)  Whether the bug occurs
or not and in which form seems to depend on the frame geometry, which
probably explains why you and me are seeing the bug and Juanma is not.
I am personally not sufficiently familiar with windmove.el to debug
it.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Juanma Barranquero]

On Tue, 27 May 2003 21:16:27 -0500 (CDT)
Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> Whether the bug occurs
> or not and in which form seems to depend on the frame geometry, which
> probably explains why you and me are seeing the bug and Juanma is not.

I've tried also with an Emacs built (and running) on W2K and it works
right too.

I tried deleting the HKLM\Software\GNU\Emacs registry branch so emacs -q
--no-site-file starts with the cleanest posible environment. It still
works.

                                                                Juanma

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.

Re: windmove and the minibuffer

[Luc Teirlinck]

I am now convinced that the bug is not in windmove, but in `window-at'
and `coordinates-in-window-p'.

Indeed, the documentation of `window-at' is rather ambiguous but doing
C-h f coordinates-in-window-p, we see:

(0 .  0) denotes the character in the upper left corner of the
frame. 

This seems to clearly imply that after:

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.  What
happens on MS Windows?

Sincerely,

Luc.

Re: windmove and the minibuffer

[Juanma Barranquero]

On Wed, 28 May 2003 15:11:39 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> 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

I suppose the idea is deactivating scroll-bar, fringe, tool-bar and menu,
right?

> (coordinates-in-window-p '(0 . 0) (selected-window))
> 
> should not return nil.  But it does, at least on GNU/Linux.  What
> happens on MS Windows?

(0 . 0)

                                                           /L/e/k/t/u

Re: windmove and the minibuffer

[Luc Teirlinck]

I forgot the CC to emacs-devel in an earlier reply (Sorry.):

Juanma Barranquero wrote:

   I suppose the idea is deactivating scroll-bar, fringe, tool-bar and
   menu,
   right?

Yes, just to make sure they have nothing to do with the problem.

   > (coordinates-in-window-p '(0 . 0) (selected-window))
   >
   > should not return nil.  But it does, at least on GNU/Linux.  What
   > happens on MS Windows?

   (0 . 0)

That is clearly what it should return.  So the bug in
`coordinates-in-window-p' is operating system dependent and does not
occur under MS Windows.

Did you evaluate the window-at forms I mentioned in my earlier
message? (Because that would be interesting.)

Sincerely,

Luc.

Re: windmove and the minibuffer

[Richard Stallman]

    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.

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.

Re: windmove and the minibuffer

[Robert J. Chassell]

Luc Teirlinck <teirllm@dms.auburn.edu> asked about a bug concerning
windmove and the minibuffer.

I see the bug.  I invoked Emacs like this:

  /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

Then:
          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.

RMS writes:

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

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   Still returns nil for me in freshly updated CVS Emacs. 

And I got nil, too, in freshly updated CVS Emacs.

Today's CVS snapshot, Sun, 2003 May 31 20:36 UTC
GNU Emacs 21.3.50.68 (i686-pc-linux-gnu, X toolkit)
with a Linux kernel
started with:

  /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'


Luc Teirlinck <teirllm@dms.auburn.edu> asks:

   Can you reproduce Alex's original bug:

   Run emacs -q

(require 'windmove)

   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)

Yes, I just reproduced that exactly.

   ... which return values do you get ....

Here they are:

   (window-at 0 15)nil
   (window-at 1 (window-height))#<window 3 on *scratch*>
   (window-at 0 (window-height))nil
   (window-at 1 (1+ (window-height)))#<window 4 on  *Minibuf-1*>

   (emacs-version)"GNU Emacs 21.3.50.68 (i686-pc-linux-gnu, X toolkit)
 of 2003-05-31 on benthic.rattlesnake.com"

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: windmove and the minibuffer

[Luc Teirlinck]

Robert Chassell wrote:

   Here they are:

      (window-at 0 15)nil
      (window-at 1 (window-height))#<window 3 on *scratch*>
      (window-at 0 (window-height))nil
      (window-at 1 (1+ (window-height)))#<window 4 on  *Minibuf-1*>

Same values I got.  And I also use GNU/Linux.  I believe that these
values are wrong and explain the bug in windmove.  People using MS
Windows get the correct values (also for coordinates-in-window-p) and
do not see the bug in windmove.  The same could conceivably hold for
people using the GNU kernel.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Alex Schroeder]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

>        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.
>
> Alex, what return value do you get for the above form, in the above
> situation?

Using the above instructions, I get:

(0 . 0)

Then I do
M-x windmove-default-keybindings
C-x C-f
S-up

So currently the minibuffer is active, but I am in *scratch*.
The above sexp still returns (0 . 0).
S-down still does not go back to the minibuffer.
Hm.

> Also which return values do you get, in that same
> situation, for:
>
> (window-at 0 15)

#<window 3 on *scratch*>

> (window-at 1 (window-height))

#<window 3 on *scratch*>

> (window-at 0 (window-height))

#<window 3 on *scratch*>

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

#<window 4 on  *Minibuf-0*>

The result are just the same when I have an active minibuffer.

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

I use Debian testing/unstable

(emacs-version)  

"GNU Emacs 21.3.50.5 (i686-pc-linux-gnu, X toolkit)
 of 2003-05-24 on confusibombus"

system-configuration           "i686-pc-linux-gnu"
system-configuration-options   ""


Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: windmove and the minibuffer

[Robert J. Chassell]

Some people who use GNU with a Linux kernel see the
windmove/minibuffer bug; others do not.  So kernel type on its own
cannot be the critical factor.

For example, Alex Schroeder <alex@gnu.org> gets:

(0 . 0)

with

    (emacs-version) 
    "GNU Emacs 21.3.50.5 (i686-pc-linux-gnu, X toolkit)
     of 2003-05-24 on confusibombus"

    system-configuration           "i686-pc-linux-gnu"
    system-configuration-options   ""

On the other hand, I get nil with the same emacs-version and
system-configuration, but with this     system-configuration-options

    "'--with-type1' '--prefix=/usr/local' '--with-sound=yes'"

Hope this helps!

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: windmove and the minibuffer

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Some people who use GNU with a Linux kernel see the
> windmove/minibuffer bug; others do not.  So kernel type on its own
> cannot be the critical factor.
> 
> For example, Alex Schroeder <alex@gnu.org> gets:
> 
> (0 . 0)
> 
> with
> 
>     (emacs-version) 
>     "GNU Emacs 21.3.50.5 (i686-pc-linux-gnu, X toolkit)
>      of 2003-05-24 on confusibombus"
> 
>     system-configuration           "i686-pc-linux-gnu"
>     system-configuration-options   ""
> 
> On the other hand, I get nil with the same emacs-version and
> system-configuration, but with this     system-configuration-options
> 
>     "'--with-type1' '--prefix=/usr/local' '--with-sound=yes'"
> 
> Hope this helps!

My first bet would be on the window manager, with runner-up fonts or
other X resources.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: { SPAM 2 }::Re: windmove and the minibuffer

[Luc Teirlinck]

David Kastrup wrote:

   My first bet would be on the window manager, with runner-up fonts or
   other X resources.

Changing window-managers from my usual Starfish to the KDE window
manager did not make any difference, nor did getting rid of all my
.Xdefaults customizations.  The C code seems to indeed point at fonts
as the culprit, but I do not really understand it well enough to be
positive about that.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Luc Teirlinck]

So depending on "something" we actually can get not two, but three
different window-at behaviors.  It might be difficult to figure out
what the "something" is without studying the C code.  I know C, but,
at present, I am not really familiar at all with Emacs' C code, just
with its Elisp code.

   S-down still does not go back to the minibuffer.
   Hm.

I do understand that, given:

   > (window-at 0 (window-height))

   #<window 3 on *scratch*>

With point at the beginning of the scratch buffer, these are the
coordinates that `windmove-find-other-window' passes to window-at.
Hence, you stay in *scratch* (without error message).  On my system,
the expression returns nil, so I get an error message (and also stay
in scratch).

For Juanma the expression returns:

 #<window 4 on  *Minibuf-0*>

So he goes to the minibiuffer.

If one could fix the window-at problem, the windmove problem would
automatically disappear.  This is not a bug in windmove.el.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Luc Teirlinck]

In the same situation as before

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

returns:

(0.8571428571428571 . 0.9230769230769231)

This seems strange.  What does it return for you?

Sincerely,

Luc.

Re: windmove and the minibuffer

[Luc Teirlinck]

On my system, coordinates-in-window-p just gets the top left corner
of the frame wrong.  Everything is off by the same amount.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Luc Teirlinck]

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

Re: windmove and the minibuffer

[Luc Teirlinck]

>From my previous message:

   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.

This might not necessarily make sense.  I quite simply do not know the
involved C code well enough to be formulating conjectures.

Sincerely,

Luc.

Re: windmove and the minibuffer

[Alex Schroeder]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

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

Indeed.  :)

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: windmove and the minibuffer

[Richard Stallman]

    Did you use the Linux or GNU kernel?

I'm using a GNU/Linux system.  Anyway, the original bug happens for
me when using X, so I will try to debug it.

[Later] I debugged it and fixed it.  The problem was because
window-edges gives edges that include columns in the scroll bar,
fringes, etc., but window-at does not accept such positions.  I added
a new function window-inside-edges and made windmove use that to
produce its reference positions.

However, I am thinking that window-at ought to recognize positions
in the scroll bar, margins, etc. of a window.

Re: windmove and the minibuffer

[Juanma Barranquero]

On Wed, 28 May 2003 14:27:35 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> (window-at 0 15)
> 
> Result: nil

   => #<window 3 on *scratch*>

> (window-at 1 (window-height)) 
> 
> Result: #<window 3 on *scratch*>

   => #<window 4 on  *Minibuf-0*>

> (window-at 0 (window-height))
> 
> Result: nil. 

   => #<window 4 on  *Minibuf-0*>


                                                           /L/e/k/t/u

Re: windmove and the minibuffer

[Luc Teirlinck]

The values returned by `window-at' under MS Windows are, in my
opinion, exactly the ones that should be returned.  So the bugs in
both `coordinates-in-window-p' and `window-at' are operating-system
specific and do not occur under MS Windows.  I do not know the
involved C code well enough to debug this myself.

In my opinion, there are no bugs in windmove.el.

Sincerely,

Luc.