From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Mon, 23 Nov 2020 20:22:43 +0000 Message-ID: References: <20201121102751.GA11643@ACM> <18a901b8-3250-b461-eb2a-c13988616e93@gmx.at> <20201121124550.GB11643@ACM> <535bd6d4-3997-2e64-ea43-5de6f0892062@gmx.at> <20201122105947.GA5912@ACM> <59f8d2fa-3db9-078b-56e2-c793f6e69edd@gmx.at> <20201122183826.GG5912@ACM> <20201123133613.GA4635@ACM> <69ba00e6-b182-77e1-911b-d70f9fffa762@gmx.at> <20201123160703.GB4635@ACM> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6370"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Alan Mackenzie , enometh@meer.net, emacs-devel@gnu.org, Eli Zaretskii , Andrii Kolomoiets , Stefan Monnier To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 23 21:30:33 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khITp-0001Zi-BE for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Nov 2020 21:30:33 +0100 Original-Received: from localhost ([::1]:60118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khITo-00051G-Ah for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Nov 2020 15:30:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khIMn-0005bS-6N for emacs-devel@gnu.org; Mon, 23 Nov 2020 15:23:17 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:58998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khIMk-000246-4S; Mon, 23 Nov 2020 15:23:16 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0ANKMkMu011018 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 23 Nov 2020 20:22:46 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ANKNIYv020586; Mon, 23 Nov 2020 20:23:18 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259696 Archived-At: > > Thanks. To elaborate on an earlier problem I mentioned which, as I > found out, happens already with Emacs 27 at the least. I'd be just > interested if you can reproduce it on your system. Start with > > emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" > > Now in the minibuffer window type C-h f and at the prompt type setq RET. > This pops up a help window on the normal frame explaining 'setq' and > 'Type "q" in help window to delete it.' appears in the minibuffer > window. Here, sometimes the normal frame is selected, sometimes the > minibuffer frame remains selected. It might be a timing issue since > sometimes I see the cursor flicker at the end of the 'Type "q" ...' text > before it moves to the normal frame, provided it moves there. > > The strange thing that happens is when I now type "q" in the help > window. Here the minibuffer window gets selected and ready to receive > input but no cursor is shown in it. Do you see that? Anyone else? > I can confirm this behavior. It does not happen with Emacs 23 to 25, and happens with Emacs 26 to 28. Except that: "Now in the minibuffer window type C-h f and..." is (in my case at least) "Select the miniwindow frame, type C-h f, and..." I did not see the "sometimes the normal frame is selected, sometimes the minibuffer frame remains selected", in my case at least the miniwindow frame remains selected in all cases. Which means that I need to click in the *Help* buffer before typing "q". "Here the minibuffer window gets selected and ready to receive input but no cursor is shown in it." is (in my case at least) "The minibuffer gets selected and ready to receive input but no cursor is shown in it AND the miniwindow frame is not raised (put above the main frame by the window manager)". Another strange thing is that at that point a number of keys are bound to something, as if something like "C-x 5" was always pressed: "b" says "Switch to buffer in other frame" "f" says "Find file in other frame:" "m" opens "mail" "i" opens "info" "n" creates a new frame But it is not the "C-x 5" keymap, because "d" or "r" for example are not bound, and "n" is not bound in "C-x 5".