From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#37840: Missing in the Emacs manuals: Date: Thu, 31 Oct 2019 08:59:06 +0100 Message-ID: References: <5440997d-8f3f-12f9-ae9e-c0caadde4a01@gmx.at> <81790531-20E9-4919-A485-0D8FE6F60CE1@univie.ac.at> <38fdbe2c-5f1a-3b37-da5f-e2fa6411d8e1@gmx.at> <4ee75419-6f22-4928-3ddb-1add957fb9e4@gmx.at> <568AD058-07B1-4C58-81C5-32E2492C1EC5@univie.ac.at> <554177EF-4600-4F68-89F1-3AF67A551F65@univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="146737"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37840@debbugs.gnu.org To: Konrad Podczeck Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 31 09:01:03 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iQ5OB-000c1G-Fe for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Oct 2019 09:01:03 +0100 Original-Received: from localhost ([::1]:47328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQ5O9-0003it-D8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Oct 2019 04:01:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53740) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQ5NE-0003hY-MR for bug-gnu-emacs@gnu.org; Thu, 31 Oct 2019 04:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQ5ND-0000jL-FR for bug-gnu-emacs@gnu.org; Thu, 31 Oct 2019 04:00:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43265) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQ5ND-0000h6-6k for bug-gnu-emacs@gnu.org; Thu, 31 Oct 2019 04:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iQ5ND-0006iP-2L for bug-gnu-emacs@gnu.org; Thu, 31 Oct 2019 04:00:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2019 08:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37840 X-GNU-PR-Package: emacs Original-Received: via spool by 37840-submit@debbugs.gnu.org id=B37840.157250875925730 (code B ref 37840); Thu, 31 Oct 2019 08:00:02 +0000 Original-Received: (at 37840) by debbugs.gnu.org; 31 Oct 2019 07:59:19 +0000 Original-Received: from localhost ([127.0.0.1]:52086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQ5MU-0006gw-Nf for submit@debbugs.gnu.org; Thu, 31 Oct 2019 03:59:18 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:33405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQ5MS-0006gg-IT for 37840@debbugs.gnu.org; Thu, 31 Oct 2019 03:59:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572508746; bh=cntSeGHS5FO1tVFZU0rvbSAVzwbwtNnj11frQGgcYE8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=R5aeJdgA+0M0JUW6eBoECAYcqmfJScx0TC3sNjj2Zeo4mMJeu7NNplH6LqqmhnQKU hqRnOpRUUq46Y0yZv8UK4nXSjY22vDqPlIsOpZoVfZNpWadnXMfAddZoodrAW0AuNg TgZDpHnOvRhuKfmaMBwDfdiyJB38x2V/V7Bd+oHI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.131]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mf078-1hjawC0dnW-00gbRo; Thu, 31 Oct 2019 08:59:06 +0100 In-Reply-To: <554177EF-4600-4F68-89F1-3AF67A551F65@univie.ac.at> Content-Language: de-AT X-Provags-ID: V03:K1:2/9qPNd1TbYyWXMtDjchhu6AH2fdWNIBUsoqxJ8+AGBtoHmwpsW mOgdxM8sxEI4/Q7f3zBZg/VcUqTwyRUAfKv75rZBy866GJ3YMJqEnVkGYLBkkdwquHvn3LO EyR4tVdPK74lfMrp1PQguwzUQv/ytaMwV0BH7o65D2hQ6ONkEFf3bi9v1RpG3ubcyAC7ZgO 1hXSmtGe1RXcXC3EEmNzw== X-UI-Out-Filterresults: notjunk:1;V03:K0:lICpJxvvaPg=:J6Kt92lOjDOVs3vKVEu9R+ x1jHzttO6Pkp4DhhMR2ALpHcG5DrrlrNzu2qU9xRJFlvgM9hWMcMEhaIYb1pAsvfaGIBn7g1n UOaple3qsqE//3j/dQeUCyoqAWiG6DUYBsc3tWTOU5yMOULAq3oCytaPnsnteE06tcqOTAmCv y/ozIH/pf0Vwj9hGWBtkIdBxmn8pQ5oA2rp/0y50vpfSHafQ2EnW5Jmyp81ASTuOxlMmZPCy6 phhwy+t3huNz9PN0+5R/x1STXRZ5IfEGuWS9B+VKDPo/s9gR63qTXJH/QQdXDdbgveqIPnfXv WTV+zF+qUbS6eVt0uxH7c2LAdBEr68wJ075HKY2BWKd+L2e9YCCuEIhnUzUzV9YIZ6cBcDO41 8DLoOmKrDgDqPL5ZBQs2Cbsi1VkaFFoZJS/Xrl6S7VVnUvix+54e0hpqL7X72VNsBaNy0vy8q YkGmZkrpZ1xPqpHAGAMO53hbBdMUbfbYlu+vTYgqdwkqmqJke7lmKu6SAYvVtYZ6obsP5tF17 g2oc2YjV/q/jx51dhxEzyNeH3R3n9gvFI1hC9wAnmB55Zc6eNaB6YbZaXYtn6QJhEu3nzO2oR mdORZ4/M7sbZt/1ZIZPyfaLAnAeCbOCcZiTSiFmg0oUNELWtJdOe45fSfqo11peimOJBq6GuN gaCEMjBlIq+oE8v+wGCT/q1LZziFRLSrScFjioDZiG6T1aabVE2ZXs68tbOuMHxprPb5VrQtf UcbCAZMHhuQAqh4MjUWtMpbfcV0wfZFmvNAnULJ+e7cR+7ONOR7Uc+SED+1jbcDjdwv8UCVx X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:170501 Archived-At: > Suppose I have buffer A open in frame A. Issuing occur->some word, > the occur buffer pops up in its own frame, say frame B, as intended > with the above customization. Moreover, frame B has input > focus. Returning to frame A, without closing frame B, and issuing > another time occur-> some word, frame B now shows the new occur > buffer, as intended, but this time frame B lacks input focus. What > goes wrong the second time? Nothing, I suppose. 'occur' (I suppose that's the function you invoke) calls 'occur-1' and that one simply does (display-buffer occur-buf) which according to its doc-string does Display BUFFER-OR-NAME in some window, without selecting it. IIUC the philosophy of 'occur' is given in its doc-string as The lines are shown in a buffer named `*Occur*'. It serves as a menu to find any of the occurrences in this buffer. and programs usually don't preselect menus either. The user has to reach for the mouse or type some key to go there first ... So the question is rather "what goes wrong the first time?". The answer to that is that, when 'display-buffer' creates a new frame, the window manager usually also gives that new frame input focus. Some window managers allow to change that for all applications. If you add a non-nil 'no-focus-on-map' entry to your 'pop-up-frame-parameters', Emacs will ask the window manager to not focus the new frame and channces are that your window manager complies. > Let me mention that if, in window.el, I add > > (x-focus-frame (window-frame window)) > > at the very end of the defun "display-buffer-reuse-window", the > problem goes away, i.e., in the above example, frame B gets input > focus after every invocation of occur in frame A. How can I get this > with a suitable customization on the "display-buffer-alist" level? You can't. I think the most simple way to achieve what you want is to add a function to 'occur-hook' that does search for a window that shows the current buffer and, if it finds such a window, invokes 'select-frame-set-input-focus' for that window's frame. martin