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: Fri, 27 Nov 2020 20:05:44 +0000 Message-ID: References: <20201123133613.GA4635@ACM> <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19178"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Alan Mackenzie , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 21:07:17 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 1kik1V-0004uZ-L1 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 21:07:17 +0100 Original-Received: from localhost ([::1]:34862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kik1U-0003QX-G8 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 15:07:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kik0H-0002yB-6P for emacs-devel@gnu.org; Fri, 27 Nov 2020 15:06:01 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:52443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kik0B-0005vq-T1; Fri, 27 Nov 2020 15:06:00 -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 0ARK5lTg007357 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 20:05:47 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ARK6KpV022234; Fri, 27 Nov 2020 20:06:20 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:259921 Archived-At: >>> - Optionally, tie the frame where a minibuffer interaction was >>> initiated to that minibuffer and when the ensuing action is performed, >>> make that frame the selected one. >> >> Isn't this what minibuffer-follows-selected-frame t is supposed to do? >> (Except that the frame is not automatically selected.) > > With 'minibuffer-follows-selected-frame' non-nil, the remainder of > 'switch-to-buffer' simply runs on the frame where the prompt is answered > which is not necessarily the frame where C-x b was issued initially. > Yes, and this is not what it is supposed to do. The NEWS item says "the effect of what you type in the minibuffer happens in the frame where the minibuffer was first activated, even if it moved to another frame."