From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Wed, 11 Nov 2020 17:38:40 +0200 Message-ID: <83eekz29a7.fsf@gnu.org> References: <20201031194419.GC5887@ACM> <834kmago8m.fsf@gnu.org> <20201031203914.GD5887@ACM> <835z6ogc1h.fsf@gnu.org> <20201101195313.GA6190@ACM> <83sg9rd6cp.fsf@gnu.org> <20201102185147.GC7297@ACM> <83mtzzd0s3.fsf@gnu.org> <20201103210853.GA21923@ACM> <83ft5pax2p.fsf@gnu.org> <20201104173954.GA14535@ACM> <83v9ed3nbw.fsf@gnu.org> <83pn4l1327.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30900"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Andrii Kolomoiets Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 16:39:37 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 1kcsDh-0007ty-Og for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 16:39:37 +0100 Original-Received: from localhost ([::1]:58728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcsDg-0003It-Lw for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 10:39:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55014) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcsCn-0002bA-1R for emacs-devel@gnu.org; Wed, 11 Nov 2020 10:38:41 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58773) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcsCm-0002FF-3U; Wed, 11 Nov 2020 10:38:40 -0500 Original-Received: from [176.228.60.248] (port=1853 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kcsCa-00045K-S7; Wed, 11 Nov 2020 10:38:30 -0500 In-Reply-To: (message from Andrii Kolomoiets on Wed, 11 Nov 2020 00:43:13 +0200) 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:259013 Archived-At: > From: Andrii Kolomoiets > Cc: monnier@iro.umontreal.ca, enometh@meer.net, emacs-devel@gnu.org > Date: Wed, 11 Nov 2020 00:43:13 +0200 > > Don't you the think new behavior may be confusing? The old behavior was > like "Oh, I left the minibuffer in that frame; OK, I need to switch to > that frame and complete the task". Actually, the old behavior was more like "Oh, I left the minibuffer in that frame, but sometimes -- whoops! -- it jumps to the new frame, and sometimes it doesn't." > And the new one is like "Oh, the minibuffer is on active frame, > cool! But wait, where is the results of my eval?" because in 'emacs > -Q': > > C-x 5 b foo RET bar M-: (buffer-string) C-x 5 o C-x o RET > > Seems like the 'buffer-string' is evaluated in the *scratch* buffer, but > it is not. Exactly as documented, btw. But if we think this is a bug, we should fix it regardless of the default value of the new option. Once again, let's distinguish between what we think are bugs and what we think is valid behavior that someone might not like as the default.