x-autoselect-window

x-autoselect-window

[Eli Zaretskii]

A few comments on the new x-autoselect-window feature:

  - Does anyone else see that sometimes, especially when the mouse is
    moved very quickly from one window to another, the cursor shape and
    mode line don't show the other window was selected until you
    actually type something, or move the cursor?  Tracing through the
    code, I see that Fselect_window is being called, but the display
    doesn't refresh until I press some key.

    I think that a call to Fselect_window is not enough to cause the
    relevant parts of redisplay to run, since nothing really changes
    on the screen.

    Gerd, what would be the way to force Emacs to display the
    selected window in this case?  I tried several possible ways, but
    nothing seemed to work.

  - I don't understand why does the test for calling Fselect_window
    insist on comparing the window, where the mouse pointer is, with
    the last window where we saw the mouse pointer.  Why isn't it
    enough to compare only with the selected window?

  - Finally, the name x-autoselect-window seems unnecessarily
    X-specific.  Since the goal is to support this not only on X, I
    wonder whether we should have a more neutral name, like
    mouse-autoselect-window or something.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>     I think that a call to Fselect_window is not enough to cause the
>     relevant parts of redisplay to run, since nothing really changes
>     on the screen.
> 
>     Gerd, what would be the way to force Emacs to display the
>     selected window in this case?  I tried several possible ways, but
>     nothing seemed to work.

If I'm guessing right that this is done in C, then a
++windows_or_buffers_changed should suffice.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Eli Zaretskii]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 16 Feb 2002 18:36:32 +0100
> > 
> >     Gerd, what would be the way to force Emacs to display the
> >     selected window in this case?  I tried several possible ways, but
> >     nothing seemed to work.
> 
> If I'm guessing right that this is done in C, then a
> ++windows_or_buffers_changed should suffice.

Yes, it's in C.  But Fselect_window already sets
windows_or_buffers_changed to a non-zero value, so that doesn't quite
cut it.  Is it possible that the frame-based redisplay needs something
else?  Or should I look for a bug?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Pavel Janík]

   From: "Eli Zaretskii" <eliz@is.elta.co.il>
   Date: Sat, 16 Feb 2002 17:54:33 +0200

   >   - Does anyone else see that sometimes, especially when the mouse is
   >     moved very quickly from one window to another, the cursor shape and
   >     mode line don't show the other window was selected until you
   >     actually type something, or move the cursor?  Tracing through the
   >     code, I see that Fselect_window is being called, but the display
   >     doesn't refresh until I press some key.

I do not see this, because I use blink-cursor-mode, but when I set it to
default values, I see that problem too. I will see if Gerd's advice help
here (thank you Gerd).

   >   - I don't understand why does the test for calling Fselect_window
   >     insist on comparing the window, where the mouse pointer is, with
   >     the last window where we saw the mouse pointer.  Why isn't it
   >     enough to compare only with the selected window?

Example: you have two windows. You will move mouse to the other one, it
will be autoselected. Then you will do C-x o but the mouse pointer will
stay in the autoselected window. You will tap to the keyboard, mouse will
be moved slightly, the window will be autoselected again, but you are
writing to the other window (you used C-x o to switch to it,
remember?). This tries to prevent this.

   >   - Finally, the name x-autoselect-window seems unnecessarily
   >     X-specific.  Since the goal is to support this not only on X, I
   >     wonder whether we should have a more neutral name, like
   >     mouse-autoselect-window or something.

I have nothing to say here. Maybe only autoselect-window or something like
that, because you can you tablet or even keyboard to move the
pointer. I wanted to name it to better reflect focus-follows-mouse (because
it is used in window managers terminology), but could not find the right
name.
-- 
Pavel Janík

panic("Attempted to kill the idle task!");
                  -- 2.2.16 kernel/exit.c

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Yes, it's in C.  But Fselect_window already sets
> windows_or_buffers_changed to a non-zero value, so that doesn't quite
> cut it. 

Hm.

> Is it possible that the frame-based redisplay needs something else?

I don't think so.  The frame- vs. window-based thing should play a
role only in the display update phase, i.e., after glyph matrices
for windows have been built.  This case sounds more as if matrices for
some windows haven't been built.

> Or should I look for a bug?

Perhaps windows_or_buffers_changed gets reset to 0 somewhere before
redisplay sees it?  It might also be interesting to look at the trace
output that Emacs prints when built with -DGLYPH_DEBUG and turned on
with M-x trace-redisplay.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Eli Zaretskii]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 16 Feb 2002 19:25:10 +0100
> 
> > Is it possible that the frame-based redisplay needs something else?
> 
> I don't think so.  The frame- vs. window-based thing should play a
> role only in the display update phase, i.e., after glyph matrices
> for windows have been built.  This case sounds more as if matrices for
> some windows haven't been built.

More digging reveals that redisplay isn't called.  Once it _is_ called
(e.g., by just waiting for about 2 minutes, to let the sit-for in the
command loop to do its thing), the selected window is correctly
updated.

What drives me crazy is that "C-x o", which basically just calls
Fselect_window, does cause redisplay to be called.  The only
difference between "C-x o" and the code I'm debugging is that "C-x o"
produces an input event, while the code I'm looking into does not.
Does that ring a bell perhaps?

> It might also be interesting to look at the trace
> output that Emacs prints when built with -DGLYPH_DEBUG and turned on
> with M-x trace-redisplay.

I didn't try that, but I bet it will show redisplay isn't called.  I
put a breakpoint in redisplay_internal, and it wasn't hit until 2
minutes or so later.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

Pavel@janik.cz (Pavel Janík) writes:

> I do not see this, because I use blink-cursor-mode, but when I set it to
> default values, I see that problem too. I will see if Gerd's advice help
> here (thank you Gerd).

Please don't bother to check.  I just looked at the code, and I know
what's wrong: Fselect_window is called asynchonously from
note_mouse_movement via XTread_socket, which is not safe.  (Actually
I wonder why this hasn't lead to an abort somewhere, or a crash).

One way to implement this feature is to generate an input_event which
is handled in keyboard.c by selecting the window.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Eli Zaretskii]

> From: Pavel@Janik.cz (Pavel =?iso-8859-2?q?Jan=EDk?=)
> Date: Sat, 16 Feb 2002 19:14:26 +0100
> 
>    >   - Does anyone else see that sometimes, especially when the mouse is
>    >     moved very quickly from one window to another, the cursor shape and
>    >     mode line don't show the other window was selected until you
>    >     actually type something, or move the cursor?  Tracing through the
>    >     code, I see that Fselect_window is being called, but the display
>    >     doesn't refresh until I press some key.
> 
> I do not see this, because I use blink-cursor-mode, but when I set it to
> default values, I see that problem too.

It figures: I think blink-cursor-mode causes more frequent redisplays.

>    >   - I don't understand why does the test for calling Fselect_window
>    >     insist on comparing the window, where the mouse pointer is, with
>    >     the last window where we saw the mouse pointer.  Why isn't it
>    >     enough to compare only with the selected window?
> 
> Example: you have two windows. You will move mouse to the other one, it
> will be autoselected. Then you will do C-x o but the mouse pointer will
> stay in the autoselected window. You will tap to the keyboard, mouse will
> be moved slightly, the window will be autoselected again, but you are
> writing to the other window (you used C-x o to switch to it,
> remember?). This tries to prevent this.

Ah, okay.  Thanks for explaining.

>    >   - Finally, the name x-autoselect-window seems unnecessarily
>    >     X-specific.  Since the goal is to support this not only on X, I
>    >     wonder whether we should have a more neutral name, like
>    >     mouse-autoselect-window or something.
> 
> I have nothing to say here. Maybe only autoselect-window or something like
> that, because you can you tablet or even keyboard to move the
> pointer. I wanted to name it to better reflect focus-follows-mouse (because
> it is used in window managers terminology), but could not find the right
> name.

How about window-selection-follows-mouse?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> What drives me crazy is that "C-x o", which basically just calls
> Fselect_window, does cause redisplay to be called. 

I guess my other mail explains that.  The select-window happens
in code that interrupts the ``main thread'' at an arbitrary point.
I wished Emacs would crash when something like that is tried ):-).

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Eli Zaretskii]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 16 Feb 2002 20:16:33 +0100
> 
> One way to implement this feature is to generate an input_event which
> is handled in keyboard.c by selecting the window.

How about a new kind of input event, window-switch event?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> How about a new kind of input event, window-switch event?

Yes, or maybe a variation of FOCUS_IN_EVENT.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Richard Stallman]

	I think that a call to Fselect_window is not enough to cause the
	relevant parts of redisplay to run, since nothing really changes
	on the screen.

I suspect that nothing calls redisplay.  It doesn't matter whether
anything has changed in the text if redisplay is not called.

This makes me worry: is Fselect_window being called from handling of
the X event, in or called from XTread_socket?  That is probably not
safe.  Calling redisplay there is certainly not safe, since redisplay
can run Lisp code.

The correct way to handle this is to generate a special input event
analogous to the switch-frame event, as a list which contains the
window.  Then that event can be bound to a command that calls
select-window.

This will also have the effect of making redisplay happen
when that command returns to the main loop.

      - I don't understand why does the test for calling Fselect_window
	insist on comparing the window, where the mouse pointer is, with
	the last window where we saw the mouse pointer.

So that jiggling the mouse will not switch windows.

      - Finally, the name x-autoselect-window seems unnecessarily
	X-specific.  Since the goal is to support this not only on X, I
	wonder whether we should have a more neutral name, like
	mouse-autoselect-window or something.

Yes, that is right.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Richard Stallman]

    I guess my other mail explains that.  The select-window happens
    in code that interrupts the ``main thread'' at an arbitrary point.
    I wished Emacs would crash when something like that is tried ):-).

We could set that up easily enough.  Fselect_window and some other
places can check interrupt_input_blocked and abort if that is nonzero.
We could make a macro to do that.

Gerd, I see you created a variable handling_signal and made Feval
abort if that is nonzero.  Was there a reason you used handling_signal
rather than interrupt_input_blocked?  interrupt_input_blocked can be
nonzero outside of signal handling in code where reading events should
be deferred, but I think it is just as wrong to call eval or switch
windows in those places.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> Gerd, I see you created a variable handling_signal and made Feval
> abort if that is nonzero.  Was there a reason you used handling_signal
> rather than interrupt_input_blocked?  interrupt_input_blocked can be
> nonzero outside of signal handling in code where reading events should
> be deferred, but I think it is just as wrong to call eval or switch
> windows in those places.

ISTR, when I added that check to Feval initially, I found that it is
(was?) sometimes called with input blocked, although only from places
where code in BLOCK/UNBLOCK_INPUT is kind of a ``critical section''
that must not be interrupted by event handling.  It felt like a good
idea to make real event handling and these critical sections
distinguishable.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: x-autoselect-window

[Richard Stallman]

    ISTR, when I added that check to Feval initially, I found that it is
    (was?) sometimes called with input blocked, although only from places
    where code in BLOCK/UNBLOCK_INPUT is kind of a ``critical section''
    that must not be interrupted by event handling.

Would anyone like to find out where this happens?
It should be easy to find out by changing Feval to call a
no-op subroutine if interrupt_input_blocked is nonzero,
and putting a breakpoint at that subroutine.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel