Re: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]

[martin rudalics <rudalics@gmx.at>]

Hi Simon, thanks for testing this.

 > - A value of nil for mouse-autoselect-window doesn't seem to stop it
 > selecting!  I think the xterm.c check should be for
 > !NILP(mouse_autoselect_window) now.

Correct.  It should have been done as in w32term.

 > In fact, setting mouse-autoselect-window to a number, doing ESC C-x on the
 > defun of mouse-autoselect-window-cancel or mouse-autoselect-window-start,
 > and moving the mouse is enough to trigger this abort even with one window.

I don't get an abort but I'm 100% busy when edebugging this.  Hardly an
improvement.

 > - I think the uncertainty over the actual delay is more than a little odd.
 > It is more than frustrating to have to wait perhaps twice the amount of time
 > (in fact the doc string says the amount of time is any multiple of
 > mouse-autoselect-window).  Perhaps the problem is that
 > mouse_autoselect_window_function is run even if the window has not changed?
 > (Currently it is run if mouse_autoselect_window is a number, regardless of
 > whether the window has changed or not.)  If it were only to run if the
 > window has changed, perhaps mouse-autoselect-window-start can set
 > mouse-autoselect-window-position to (mouse-position)?

That was my initial approach and it worked pretty well.  But (re-)read
my previous observation with respect to this:

 >> 1. Suppose I have two windows - SW is the selected one and UW the
 >> unselected one.  I move the mouse to the menubar as described in Simon's
 >> original scenario.  UW should not be selected here.  However, I then
 >> change my mind and move the mouse to UW.  I suppose that UW should be
 >> selected now - agreed?  (It's important to clear this since the current
 >> autoselect mechanism triggers iff the mouse moves from the selected
 >> window to an unselected one.)

With other words, once I leave a window with the mouse and move to the
menubar, I won't autselect another window before I cross a window border
again.  I was afraid that some people would find this counterintuitive.

 > Unfortunately, it's a little difficult for me to play around with the lisp
 > code - I can only avoid an abort by make/make recompile/make each time.
 >
 > If you can work out how to make it stable I can help test etc.  Simon.

Probably, doing this in `handle-select-window' is more practical indeed.
(In case of doubt, Stefan's always right.)  Anyway, I'll try to find a
more practicable solution.  Thanks again for the report.  martin.