Re: mouse-autoselect-window

[Stephen Berman]

On Fri, 07 Sep 2007 08:51:59 +0200 martin rudalics <address@hidden> wrote:

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

When I first confirmed Drew Adams's report of this behavior, I had
mouse-autoselect-window set to t.  But I also see the same thing when
it is set to a numerical value.

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

I don't understand what you mean by "autoselection should continue
looping", nor what harm it doesn't cause.

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

Too bad, I often find edebug really helpful.  Oh well, guess I just
have to dirty my hands more with the code :-)

Steve Berman