emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mouse-autoselect-window


From: martin rudalics
Subject: Re: mouse-autoselect-window
Date: Tue, 18 Sep 2007 16:07:01 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> Now when I make mouse-autoselect-window t and focus-follows-mouse nil,
> then moving the mouse from one frame to another raises the latter
> without putting it in focus.

What happens if you additionally select the frame in
`handle-select-window'?  Like

        (when mouse-autoselect-window
          ;; Run `mouse-leave-buffer-hook' when autoselecting window.
          (run-hooks 'mouse-leave-buffer-hook)
          (unless focus-follows-mouse
            ;; Make sure frame is raised when autoselecting window and
            ;; we assume that the window manager does not autoraise the
            ;; frame of window.
            (select-frame (window-frame window))
            (raise-frame (window-frame window))))

> But in the newly raised frame the mode
> line of the window the mouse is over still becomes active and the tool
> bar still changes appropriately.  Do you consider this correct
> behavior?

No.

> Moreover, when I make mouse-autoselect-window a number, the behavior
> is strange and rather complicated: if the unfocussed frame does not
> have split windows, then it does not get raised when the mouse is
> moved over it; if it does have split windows, then moving the mouse
> over it always raises it after the delay, but only if I alternate
> between which of the split windows I first move the mouse over -- if I
> try moving over the same window first as I did the previous time, it
> mostly does not get raised, but sometimes does, suggesting a timing
> issue.  And moving the mouse back from the unfocussed to the focussed
> frame shows the same behavior with respect to raising (i.e., only if
> it is split and with the same alternation and timing issues).  And as
> above, the active mode line and the tool bar change regardless of
> focus or raised-ness.

Before `handle-select-window' gets executed the event reader schedules a
`handle-switch-frame' event which selects that frame and the previously
selected window of that frame.  I'm not yet sure how to "handle" that :-(





reply via email to

[Prev in Thread] Current Thread [Next in Thread]