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 13:43:27 +0000 Message-ID: References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <835z5roud4.fsf@gnu.org> 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="13155"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: martin rudalics , andreyk.mad@gmail.com, emacs-devel@gnu.org, enometh@meer.net, monnier@iro.umontreal.ca, acm@muc.de To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 14:44:58 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 1kie3W-0003JL-Jb for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 14:44:58 +0100 Original-Received: from localhost ([::1]:58224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kie3V-0006aR-K2 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 08:44:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kie2K-0005Ja-2B for emacs-devel@gnu.org; Fri, 27 Nov 2020 08:43:44 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:63967) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kie2H-0005ks-Cy; Fri, 27 Nov 2020 08:43:43 -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 0ARDhUxO009376 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 13:43:31 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ARDhT77004506; Fri, 27 Nov 2020 13:43:29 GMT In-Reply-To: <835z5roud4.fsf@gnu.org> 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:259886 Archived-At: >> Having a customizable variable like 'minibuffer-follows-selected-frame' >> whose purpose is to get back the old behavior, should also provide that >> old behavior as faithfully as possible IMHO. > > The NEWS entry clearly says that the old behavior is no longer > available, so getting back the old behavior is not the purpose of that > variable. > I hope that does not mean "end of discussion". I sent two recipes to Martin a few hours ago, which demonstrate that the behavior with that variable set to nil is broken. Again it is surprising that such a radical change was accepted without testing these cases, which are obvious cases to test. The NEWS entry says "Nevertheless, 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." This is not correct. Three recipes: emacs -Q C-x 5 2 C-x C-f C-x 5 o C-x o .emacs RET The file is opened in the frame in which you are, not in the frame in which C-x C-f was entered. Another recipe: emacs -Q C-x 5 2 C-h f setq C-x 5 o C-x o RET The *Help* buffer is displayed in the frame in which you are, not in the frame in which C-h f setq was entered. Yet another recipe, similar to the one with which this discussion started: emacs -Q C-x 5 2 C-x b C-x 5 o C-x o RET The buffer is displayed in the frame in which you are, not in the frame in which C-x b was entered.