From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Wed, 21 Oct 2020 19:38:15 +0000 Message-ID: <20201021193815.GE19276@ACM> References: <20201014163534.GB7651@ACM> <838sc8zqjj.fsf@gnu.org> <20201014184523.GC7651@ACM> <83y2k8y6qs.fsf@gnu.org> <20201014194904.GD7651@ACM> <83sgafy56d.fsf@gnu.org> <20201015180143.GA10229@ACM> <83wnzrwdy5.fsf@gnu.org> <20201021151945.GA19276@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2910"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 21 21:39:26 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 1kVJxG-0000e7-Av for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Oct 2020 21:39:26 +0200 Original-Received: from localhost ([::1]:59178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kVJxF-0007qE-Dx for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Oct 2020 15:39:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kVJwC-0007Lp-BN for emacs-devel@gnu.org; Wed, 21 Oct 2020 15:38:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:25805 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kVJw9-0005LP-Th for emacs-devel@gnu.org; Wed, 21 Oct 2020 15:38:19 -0400 Original-Received: (qmail 2418 invoked by uid 3782); 21 Oct 2020 19:38:15 -0000 Original-Received: from acm.muc.de (p4fe159f6.dip0.t-ipconnect.de [79.225.89.246]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 21 Oct 2020 21:38:14 +0200 Original-Received: (qmail 21873 invoked by uid 1000); 21 Oct 2020 19:38:15 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/21 15:13:02 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] 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_NONE=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:258249 Archived-At: Hello, Stefan, thanks for the review. In detail: On Wed, Oct 21, 2020 at 14:32:21 -0400, Stefan Monnier wrote: > Thanks Alan, > This looks pretty good to me (haven't tried it yet). > Some comments/questions below, > Stefan > > @@ -86,6 +86,19 @@ useful on systems such as FreeBSD which ships only with "etc/termcap". > > * Changes in Emacs 28.1 > > > > +++ > > +** Switching frames when a minibuffer is active has been rationalized. > > +By default, the minibuffer is moved to the newly selected frame. When > > +the current command is continued (by completing the minibuffer > > +action), it takes effect in the frame the minibuffer was first opened > > +in. An alternative behavior is available by customizing > > +'minibuffer-follows-frame' to nil; here, the minibuffer stays on the > > +frame it was first opened on, and you must switch back to this frame > > +to continue or abort the current command. The old (pre 28.1), > > +somewhat chaotic behavior is no longer available. > > + > > ++++ > > +*** A new system for displaying documentation for groups of function is added. > > + > > ** New system for displaying documentation for groups of function. > > This can either be used by saying 'M-x shortdoc-display-group' and > > choosing a group, or clicking a button in the *Help* buffers when > Looks like a chunk of Lars's shortdoc got brought along. Yes, sorry. I made a mess of hand editing the result of the merge. Now fixed. > > +static bool > > +minibuf_follows_frame (void) > > +{ > > + return !NILP (Fdefault_toplevel_value (Qminibuffer_follows_frame)); > > +} > I can't think of any reason why we'd need to bother with > `Fdefault_toplevel_value` here. I think the only justification would be > if using some other value could result in a crash or in garbled display, > but AFAICT it could only result (in the worst case) in a vaguely > unexpected behavior where the mininbuffer follows the frame when it > shouldn't or vice versa. Maybe I'm being a bit too careful, but I've got bad feelings about what might happen if a buffer local value was different from the canonical value. I simply can't picture what might happen, but like you say, it could well end up with a mini-window being displayed on two frames, and there being no way to fix that situation. > > + FOR_EACH_FRAME (tail, frame) > > + { > > + if (EQ (XWINDOW (XFRAME (frame)->minibuffer_window)->contents, > > + buffer)) > > + { > > + minibuf_window = XFRAME (frame)->minibuffer_window; > > + goto after_set; > > + } > > + minibuf_window = sf->minibuffer_window; > > + after_set: ; > > + } > I don't understand the: > minibuf_window = sf->minibuffer_window > Won't this undo the > minibuf_window = XFRAME (frame)->minibuffer_window; > executed in a previous iteration? > Should this be moved to just before the loop maybe? Yes, you're right. I put the "catch-all" setting of minibuf_window wrongly inside the FOR_EACH_FRAME loop. Like you say, a neater way of expressing this is to put the "catch-all" setting before the loop, and allow it to get overwritten by anything found in the loop. > > + /* OLD STOUGH, 2020-10-21 */ > Not sure how useful this is. I'd either remove this comment or replace > it with an actual explanation of what's going on and/or how the code > used to work. It's my own personal comment for restoring changes, and it should not have found it's way into the patch. Sorry. I'll repost the patch, with your and Drew's corrections separately. > Stefan -- Alan Mackenzie (Nuremberg, Germany).