Re: mouse-autoselect-window

[martin rudalics <rudalics@gmx.at>]

 > The reason is that I had mouse-autoselect-window set to t, and
 > handle-select-window contains this code:

The incorrect behavior you reported (a window getting its modeline
highlighted but not the focus) was with `mouse-autoselect-window' t
then?

 > So (numberp mouse-autoselect-window) => (numberp t) => nil and
 > mouse-autoselect-window-start is skipped over.  When I set
 > mouse-autoselect-window to a number, I can use edebug to step through
 > mouse-autoselect-window-select.  The results I have gotten so far are
 > puzzling.  Sometimes (mouse-position) evaluates to e.g. (#<frame
 > *scratch* 0x8656d88> 42 . 9) and then the variable `window' gets
 > let-bound to #<frame *scratch* 0x8656d88>.  But sometimes
 > (mouse-position) evaluates to e.g. (#<frame *scratch* 0x8656d88> nil)
 > and then `window' evaluates to nil.  I haven't been able to see when
 > or why this happens, but when it does, your code gets skipped over.

As long as `window' is nil autoselection should continue looping, hence
this should not cause any harm.  Autoselection should also continue
looping when the frame of `window' is not that of the selected window.

 > But even when `window' has a valid window value, I find that in edebug
 > (selected-window) evaluated to the same window, so again your code
 > gets skipped over.  But when I don't use edebug and move the mouse
 > over another frame, then (selected-window) is still the window in the
 > frame I moved off of.  I don't understand this discrepancy, and I
 > don't understand how (selected window) could change.

It's hardly possible to avoid a Heisenbug here, I soon gave up using
edebug for this.