Re: mouse-autoselect-window

[martin rudalics]

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