From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Konrad Podczeck Newsgroups: gmane.emacs.bugs Subject: bug#37840: Missing in the Emacs manuals: Date: Sat, 2 Nov 2019 22:47:40 +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 (Mac OS X Mail 13.0 \(3601.0.10\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="256454"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37840@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 02 22:48:24 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 1iR1Fv-0014ZO-Cj for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Nov 2019 22:48:23 +0100 Original-Received: from localhost ([::1]:50804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iR1Fs-0003hd-VT for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Nov 2019 17:48:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52048) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iR1Fd-0003gt-D0 for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 17:48:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iR1Fb-0006Cl-5r for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 17:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52594) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iR1Fa-00068t-OZ for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 17:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iR1FZ-0000b1-K9 for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 17:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Konrad Podczeck Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Nov 2019 21:48:01 +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.15727312732247 (code B ref 37840); Sat, 02 Nov 2019 21:48:01 +0000 Original-Received: (at 37840) by debbugs.gnu.org; 2 Nov 2019 21:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:33182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iR1FQ-0000aB-DF for submit@debbugs.gnu.org; Sat, 02 Nov 2019 17:47:52 -0400 Original-Received: from grace.univie.ac.at ([131.130.3.115]:55022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iR1FM-0000Zq-Oq for 37840@debbugs.gnu.org; Sat, 02 Nov 2019 17:47:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=univie.ac.at; s=rev2; h=To:References:Message-Id:Content-Transfer-Encoding: Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TF7eraOEr7LwaRpMXsAQGa63qqyMc2mEj+2EUMNB2jA=; b=SpyoA02dnSECWUm4JSyTqrtVk8 t2+5X4trnS4GQ1wBRTwQBylRmq1/xSTRhFrUWskM+aDT3ko0tYvzMM1IRkxHR6objQrFG1fF6LuHn 0hpvVFxtHRlNLZr3pgWRXx8RVQw9sxfRLK+Zjh+AkyBzNwx2PzIQUjF4d3s1VkKvnjDM=; Original-Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iR1FK-0000Kh-OH; Sat, 02 Nov 2019 22:47:46 +0100 Original-Received: from 217-149-171-151.nat.highway.telekom.at ([217.149.171.151] helo=[10.0.0.13]) by justin.univie.ac.at with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iR1FK-0002Fe-J7; Sat, 02 Nov 2019 22:47:46 +0100 In-Reply-To: X-Mailer: Apple Mail (2.3601.0.10) X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at 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:170849 Archived-At: I don't find anything in the manual related to the following: Suppose, without any display-buffer-alist customization, I have just (setq display-buffer-base-action (quote ( (display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . x) ))) in my init file, where x can be any of 0,1, nil, visible, all these = choices don=E2=80=99t matter for this: If I open Emacs, the initial = frame shows up, and any file loaded via recent-files, or by dragging on = the Emacs icon, or by clicking on the file icon, shows up in the initial = frame, contrary to what is advertised in the manual. However, once a = file is loaded, then re-selecting it via Menu->Buffers, pops it up in a = new frame (with properties as specified in defaults-frame-alist). So, = what is the relation between "display-buffer-base-action=E2=80=9D and = =E2=80=9Cdefault-frame-alist=E2=80=9D? Thanks, Konrad > Am 31.10.2019 um 08:59 schrieb martin rudalics : >=20 > > 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? >=20 > Nothing, I suppose. 'occur' (I suppose that's the function you > invoke) calls 'occur-1' and that one simply does >=20 > (display-buffer occur-buf) >=20 > which according to its doc-string does >=20 > Display BUFFER-OR-NAME in some window, without selecting it. >=20 > IIUC the philosophy of 'occur' is given in its doc-string as >=20 > The lines are shown in a buffer named `*Occur*'. > It serves as a menu to find any of the occurrences in this buffer. >=20 > and programs usually don't preselect menus either. The user has to > reach for the mouse or type some key to go there first ... >=20 > 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. >=20 > > 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? >=20 > 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. >=20 > martin