RE: mouse-autoselect-window

[Drew Adams]

>  > Of course I did. However, I have not "tweaked the registry".
>  > As you didn't mention the registry, I expected it to change
>  > the behavior for Emacs - and only Emacs, with no registry hacking.
>
> The patch was intended for the untweaked behavior.  It should simply
> restrict autoselection to remain within one and the same frame when you
> set `focus-follows-mouse' to nil (if this is the desired behavior).

Well, it doesn't - at least not in my Windows XP.

At least if "autoselection" includes the behavior I described originally:
activate the mode line and update the tool bar. IOW, if I move the mouse to
a window in another frame, the mode line of that window is activated, and
the toolbar reflects that window's mode. These are normally (but in this
case are faulty) indications that the window is selected.

I'm not sure where those mode-line and tool-bar changes occur. If I
debug-on-entry handle-select-window, then I never see those changes take
effect (even just hitting `c' upon debugger entry). But without debugging,
those changes (mode line, tool bar) always take effect, regardless of the
frame of the destination window.

As I mentioned originally, if the destination window is on a different
frame, then the mode line and tool bar indicate that the window is selected
(active), but it is not in fact selected, as evidenced, for example, by
(current-buffer). So, the window is not truly selected, but there are visual
indications that it is. That is what I described in my original report.

Also, if I move to a window that is one-window-p, then handle-select-window
never gets called. Otherwise it gets called. In both cases, the mode line
and the tool bar are updated. Only when the window is not one-window-p is it
actually selected (so that its buffer is the current buffer).

I am using mouse-autoselect-window = t.