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 19:47:49 +0100 Message-ID: <5464FCD5.6070201@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> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> 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 1415904568 1817 80.91.229.3 (13 Nov 2014 18:49:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 18:49: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 19:49: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 1XozSL-0002Ar-16 for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 19:49:21 +0100 Original-Received: from localhost ([::1]:33463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XozSK-0005W1-M1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 13:49:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XozSA-0005Te-LM for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 13:49:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XozS3-0007UF-5K for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 13:49:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XozS3-0007Tz-11 for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 13:49:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XozS2-0007ZF-EU for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 13:49: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 18:49:02 +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.141590448429018 (code B ref 19012); Thu, 13 Nov 2014 18:49:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 18:48:04 +0000 Original-Received: from localhost ([127.0.0.1]:59695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozR5-0007Xy-Lx for submit@debbugs.gnu.org; Thu, 13 Nov 2014 13:48:04 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:63801) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozR2-0007XX-Kc for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 13:48:01 -0500 Original-Received: from [91.113.3.148] ([91.113.3.148]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M8ehf-1YBamm023H-00wGN0; Thu, 13 Nov 2014 19:47:55 +0100 In-Reply-To: X-Provags-ID: V03:K0:M0qC/dryJILH26gFp4zFy7Nu8HGL35NJ2tNoJWkfIrZY8JH5W6t jZ2k9yJw+25cNXsoH7Xf6yVfMJWtpD4+ImLL640iPcB059dauen7Wwl4n9RsdME8U7cRvYs RtxYjUWRMVz5C/Rvxr5QdXwz/S3U+q0Jfhvxk2gpS6unS7m7fpdYEtMqvOe/L6vjnXSCi5I z4+9EBnL69MrAxviWvM0A== 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:95943 >> So you want `raise-frame' to not select the frame and `with-help- >> window' select the frame? Any preferences who should win that game? > > There is no game. > > 1. `raise-frame' should not focus the frame (or unfocus it), unless > `w32-grab-focus-on-raise' is non-nil (or unless there is also some > other, similar option that makes `raise-frame' grab the focus). > And as far as I can tell, that is the case: it does not. IIUC the default behavior on Windows is that when you raise a frame, that frame gets focus as well. So if you set `w32-grab-focus-on-raise' to nil, Emacs has to explicitly tell Windows to unfocus the frame. > But even if it did, that should be irrelevant to what > `help-select-window' does (*this* bug). What is "*this* bug"? You attribute a behavior you observe to a variable that does not and cannot control that behavior. > `raise-frame' is punctual. I have no idea what you mean here. > The scope and effect of `help-select-window' are controlled by > `with-help-window' (according to you, whom I believe; I'm no expert > on that, and that is not documented, AFAICT). Scope and effect of `help-window-select' end where `with-help-window' exits. > 2. `help-window-select' = `t' (within `with-help-window', at least) > should select the help window. (Likewise, for a value of `other', > unless the selected window is alone on the help-window's frame.) > > This is all specified by the doc (except the connection between > `help-window-select' and `with-help-window'). And there is no > contradiction between #1 and #2. `help-window-select' has nothing > to do with `w32-grab-focus-on-raise' and nothing to do with > `raise-frame' (at least according to its spec/doc). And it *should* > have nothing to do with them. If `help-window-select' is t, `with-help-window' selects the frame unconditionally. > Whether `raise-frame' focuses the frame or not should be irrelevant > to the behavior imposed by `help-window-select'. It is (according > to you) `with-help-window' that controls the scope of the effect > of `help-window-select'. It is `with-help-window' that should > ensure that `help-window-select' has the effect it claims to have > when `with-help-window' is finished. Doesn't it? >> > It is you who stated what I should expect from the behavior >> > of `help-select-window', provided the context is >> > `with-help-window'. *You* stated that it is a bug if the >> > window is not selected. >> >> So far you did not provide any evidence that the window is not >> selected. > > Sure I did. You didn't even care to go through this with a debugger. What kind of evidence is that? > I said that it does not have the input focus. Type > text and it goes to the window where you hit `C-h v'. What's more, > the frame border highlighting shows that the frame is not focused. This does not contradict that `with-help-window' selected the window. > You seem to be in denial, for some reason. Believe me, the > *Help*-selecting effect of non-nil `help-select-window' disappears > if `w32-grab-focus-on-raise' is nil. I never doubted that. But it seems to me that you don't want to care how a nil value for `w32-grab-focus-on-raise' gets processed. There is absolutely nothing `with-help-window' or any Elisp code can do there. > It should not disappear. `w32-grab-focus-on-raise' should affect > only `raise-frame'. And `help-window-select' & `with-help-window' > should not be affected by whether there is a call to `raise-frame' > or what such a call might do wrt frame focus. You can't have both - select the frame and unfocus it. martin