From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#19012: 25.0.50; `help-window-select' Date: Thu, 13 Nov 2014 08:44:50 +0100 Message-ID: <54646172.7020801@gmx.at> References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1415864788 18380 80.91.229.3 (13 Nov 2014 07:46:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 07:46:28 +0000 (UTC) To: Drew Adams , 19012@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 13 08:46:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xop6i-00027o-Kg for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 08:46:20 +0100 Original-Received: from localhost ([::1]:58157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xop6h-0007wK-Ty for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 02:46:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xop6Y-0007w4-6m for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 02:46:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xop6Q-0006r5-Jd for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 02:46:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xop6Q-0006r1-Go for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 02:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xop6Q-0007jm-2e for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 02:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Nov 2014 07:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19012 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19012-submit@debbugs.gnu.org id=B19012.141586470529656 (code B ref 19012); Thu, 13 Nov 2014 07:46:01 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 07:45:05 +0000 Original-Received: from localhost ([127.0.0.1]:59045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xop5U-0007iF-Sq for submit@debbugs.gnu.org; Thu, 13 Nov 2014 02:45:05 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:63271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xop5R-0007hY-To for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 02:45:03 -0500 Original-Received: from [88.117.59.125] ([88.117.59.125]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LyA2L-1Y1Fgj1SR3-015Xgm; Thu, 13 Nov 2014 08:44:56 +0100 In-Reply-To: <561951d1-fee4-44ea-bc22-d354b007601d@default> X-Provags-ID: V03:K0:QtIThMnVhUDibtJljDC9PfU7RGpcZrFwRl0C0eoPTEHUZFxHvih MB2tGV0Rbc/i4iEjqeg/xN24WWBWoE4hJ2ChMgkThty5s9EhoQPiJwn7S4c/j2GiOmXXLQx mFbtc3ubPmWhKym0IrZP2wF77ad/38Li0+EC5a/koy2BUgQOns4aOFdl/CVYHEKYYmQ8h0d reF7fDhmcOGQIYy0OOgNQ== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95915 > The bug is apparently caused by `w32-grab-focus-on-raise' = nil. > That should only have the effect of not causing `raise-frame' to > focus the frame. It should not prevent `help-window-select' (or > anything else) from selecting the window. What makes you sure that it does prevent `help-window-select' from selecting the window? > The effect should, because of `help-window-select' = t, be that > the *Help* window is selected. Selection should not depend on > whether `raise-frame' happens to also select/focus. Then you know more than me. `w32-grab-focus-on-raise', if nil, triggers a DeferWindowPos type chain of events, see http://msdn.microsoft.com/en-us/library/windows/desktop/ms632681%28v=vs.85%29.aspx which is beyond my comprehension. > ;; This somehow causes the window/frame NOT to be selected. > ;; If non-nil then there is no problem. > (setq w32-grab-focus-on-raise nil) Then leave it non-nil. > Note that the doc string of `w32-grab-focus-on-raise' > specifically does not say that a value of nil means that > `raise-frame' takes the focus away (unfocuses). It says > only that a value of t means that `raise-frame' focuses > the frame. > > Since nothing is said for nil, the presumption should be > that a nil value has no particular effect on focus, i.e., > that it neither "grabs input focus", as does t, nor > removes focus. If you understand what it does, provide a suitable doc-string. > And all of this code is anyway inside `with-help-window' > because of `C-h v'. So even if the bug were that > `raise-frame' removed the focus (unlike what the > `w-g-f-o-r' doc string says), `help-window-select' > should anyway ensure that *Help* is focused in the end. If you told us how `with-help-window' should deal with asynchronous frame raise/focus events, we could try to find a solution. > ----------------- What I said before --------------- >> Found it, I guess. >> >> In addition to non-nil pop-up-frames and the other code sent >> previously, do this: (setq w32-grab-focus-on-raise nil) >> >> Then, as I described, when the *Help* frame already exists it is not >> selected by C-h v etc. >> >> Now IIUC, that variable, `w32-grab-focus-on-raise', should only >> stop Windows from having `raise-frame' always focus the frame. >> That really is (should be) something different from this >> (`help-window-select'). >> >> IOW, I do not want `raise-frame' to automatically focus the >> frame for input each time. But I might want `help-window-select' >> to select the *Help* frame. Make sense? I can only repeat myself: I don't understand what is at work here and how this is supposed to work. `help-window-select' simply selects the window if certain conditions are met. How selection is implemented and what consequences it has is platform dependent and beyond its control. martin