From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: mouse-autoselect-window Date: Tue, 18 Sep 2007 09:10:12 -0700 Message-ID: References: <46EFEFE9.1030001@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190131973 10384 80.91.229.12 (18 Sep 2007 16:12:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2007 16:12:53 +0000 (UTC) Cc: Stephen Berman , emacs-devel@gnu.org To: "martin rudalics" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 18:12:46 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IXfg5-0004Fw-Rn for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2007 18:11:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXfg4-0000nN-6p for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2007 12:11:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IXffN-0000Ui-U0 for emacs-devel@gnu.org; Tue, 18 Sep 2007 12:11:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IXffM-0000Tj-K0 for emacs-devel@gnu.org; Tue, 18 Sep 2007 12:11:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXffM-0000Td-6w for emacs-devel@gnu.org; Tue, 18 Sep 2007 12:11:12 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IXffL-0001Ml-PX for emacs-devel@gnu.org; Tue, 18 Sep 2007 12:11:12 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8IGB72P012258; Tue, 18 Sep 2007 11:11:07 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8IBWwD4005545; Tue, 18 Sep 2007 10:11:06 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-85.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3223044501190131810; Tue, 18 Sep 2007 09:10:10 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <46EFEFE9.1030001@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:79209 Archived-At: > > It raises the frame, but it does not give it the input focus. > > I had already said (on 2007-09-05) that giving focus to the > > frame at the cost of raising it was a possibility: > > > > > >>BTW, `mouse-autoselect-window' _could_ select the mouse window in MS > >>Windows, even on another frame, at the cost of also raising > >>that frame - just add `select-frame-set-input-focus' to its code. > >>However, I'm not sure that is a good idea. I assume that on > >>GNU/Linux etc. the focus moves but the window is not raised - > >>that's the behavior I would prefer, anyway. > > > > I mentioned `select-frame-set-input-focus', whereas you used > > `raise-frame'. The effect wrt raising is the same, but your > > fix does not change the input focus (for me, on Windows). > > You're right. But I can't use `select-frame-set-input-focus' because it > might move the mouse pointer as well. (I don't remember what the problem with that is.) > Could you try with the following substitute? > > (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 and selected when autoselecting > ;; window and we assume that the window manager does not > ;; autoraise the frame of window. > (select-frame frame) > (raise-frame frame) > ;; Ensure, if possible, that frame gets input focus. > (cond ((memq window-system '(x mac)) > (x-focus-frame frame)) > ((eq window-system 'w32) > (w32-focus-frame frame))))) `frame' is unbound here. Let-bind it to (window-frame window), and it works: (defun handle-select-window (event) "Handle select-window events." (interactive "e") (let ((window (posn-window (event-start event)))) (when (and (window-live-p window) ;; Don't switch if we're currently in the minibuffer. ;; This tries to work around problems where the minibuffer gets ;; unselected unexpectedly, and where you then have to move ;; your mouse all the way down to the minibuffer to select it. (not (window-minibuffer-p (selected-window))) ;; Don't switch to a minibuffer window unless it's active. (or (not (window-minibuffer-p window)) (minibuffer-window-active-p window))) (unless (and (numberp mouse-autoselect-window) (not (zerop mouse-autoselect-window)) (not (eq mouse-autoselect-window-state 'select)) (progn ;; Cancel any delayed autoselection. (mouse-autoselect-window-cancel t) ;; Start delayed autoselection from current mouse position ;; and window. (mouse-autoselect-window-start (mouse-position) window) ;; Executing a command cancels delayed autoselection. (add-hook 'pre-command-hook 'mouse-autoselect-window-cancel))) ;; Reset state of delayed autoselection. (setq mouse-autoselect-window-state nil) (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. (let ((frame (window-frame window))) (select-frame frame) (raise-frame frame) ;; Ensure, if possible, that frame gets input focus. (cond ((memq window-system '(x mac)) (x-focus-frame frame)) ((eq window-system 'w32) (w32-focus-frame frame)))))) (select-window window))))) This is an improvement, for me, but, as I said, it would be better if the focus could be changed without necessarily raising the frame also. Those should be two separate choices: focus & raise. > > I personally think that it would be OK to raise the frame too, if focus > > cannot be given to it otherwise, but what would really be > > desirable is to give focus to the frame (and window) without raising > > it. I don't know if that is always possible (e.g. on MS Windows), but > > when it is possible, it is, I think, the appropriate behavior. > > We could make raising optional, BTW. You could check whether you like > it better by removing the `raise-frame' line above. That seems to have no effect - the frame is raised even without the call to `raise-frame'. I presume that is because `w32-focus-frame', as its doc string says, gives "FRAME input focus, raising to foreground if necessary". Perhaps there is no way around this raising on Windows? Does someone know? Again, to me, this is an improvement, even if the frame does get raised, but if we could prevent raising (unless the user asks for that), that would be better. > > Ideally, with customizable options, users would be able to control, > > separately, autofocus and autoraise. > > Agreed. > > > I also see another problem with your fix (it might not be due > > to the fix itself, however). It doesn't always seem to raise > > the right frame. I don't know why. I don't know if others will > > see the same problem. > > With `mouse-autoselect-window' t or a number? With `t'. Anyway, the code above does not seem to have this problem.