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: Sat, 31 Oct 2020 09:25:00 +0200 Message-ID: <83v9eq97sj.fsf@gnu.org> References: <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> <20201021200438.GF19276@ACM> <83h7qmkzla.fsf@gnu.org> <20201030220917.GA17594@ACM> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7699"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 31 08:25:57 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 1kYlGu-0001v6-W4 for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Oct 2020 08:25:56 +0100 Original-Received: from localhost ([::1]:40618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYlGu-0007tU-1p for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Oct 2020 03:25:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYlGH-0007Nh-Ll for emacs-devel@gnu.org; Sat, 31 Oct 2020 03:25:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34852) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYlGG-0008SA-O4; Sat, 31 Oct 2020 03:25:16 -0400 Original-Received: from [176.228.60.248] (port=3882 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYlGF-0000qN-VZ; Sat, 31 Oct 2020 03:25:16 -0400 In-Reply-To: <20201030220917.GA17594@ACM> (message from Alan Mackenzie on Fri, 30 Oct 2020 22:09:17 +0000) 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:258572 Archived-At: > Date: Fri, 30 Oct 2020 22:09:17 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > DEFUN ("minibufferp", Fminibufferp, > - Sminibufferp, 0, 1, 0, > + Sminibufferp, 0, 2, 0, > doc: /* Return t if BUFFER is a minibuffer. > No argument or nil as argument means use current buffer as BUFFER. > -BUFFER can be a buffer or a buffer name. */) > - (Lisp_Object buffer) > +BUFFER can be a buffer or a buffer name. If LIVE is non-nil, then > +t will be returned only if BUFFER is an active minibuffer. */) > + (Lisp_Object buffer, Lisp_Object live) > { This uses passive tense in the last sentence. > + /* tem = Fmemq (buffer, Vminibuffer_list); */ > + /* return (!NILP (tem) && !EQ (tem, Vminibuffer_list)) ? Qt : Qnil; */ This seems to be a leftover from developing the new code > + if (!NILP (live)) > + return !NILP (Fmemq (buffer, Vminibuffer_list)) ? Qt : Qnil; > + if (EQ (buffer, Fcar (Vminibuffer_list))) > + /* *Minibuf-0* is never active. */ > + return Qnil; > + tem = Fcdr (Vminibuffer_list); > + for (i = 1; i <= minibuf_level; i++) > + { > + if (NILP (tem)) > + return Qnil; Why is this test inside the loop? > @@ -416,11 +471,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > { > Lisp_Object str > = build_string ("Command attempted to use minibuffer while in minibuffer"); > - if (EQ (selected_window, minibuf_window)) > - Fsignal (Quser_error, (list1 (str))); > + if (!minibuf_follows_frame () > + || EQ (selected_window, minibuf_window)) > + Fsignal (Quser_error, (list1 (str))); I don't think I understand this change: what does minibuffer-follows-selected-frame have to do with recursive minibuffer usage? They are two independent features. > - /* Empty out the minibuffers of all frames other than the one > - where we are going to display one now. > - Set them to point to ` *Minibuf-0*', which is always empty. */ > - empty_minibuf = get_minibuffer (0); > - > - FOR_EACH_FRAME (dummy, frame) > - { > - Lisp_Object root_window = Fframe_root_window (frame); > - Lisp_Object mini_window = XWINDOW (root_window)->next; > - > - if (! NILP (mini_window) && ! EQ (mini_window, minibuf_window) > - && !NILP (Fwindow_minibuffer_p (mini_window))) > - /* Use set_window_buffer instead of Fset_window_buffer (see > - discussion of bug#11984, bug#12025, bug#12026). */ > - set_window_buffer (mini_window, empty_minibuf, 0, 0); > - } Does this mean the minibuffers on other frames will now not be emptied? > +/* Returns whether a Lisp_Object is a particular existing minibuffer. */ Our style of comments in these cases is like this: "Return non-zero if BUF is a particular existing minibuffer." > + DEFVAR_BOOL ("minibuffer-follows-selected-frame", minibuffer_follows_selected_frame, > + doc: /* Non-nil means an open minibuffer will move to a newly selected frame. Talking about "moving" and "newly selected" here might come as a surprise, because the context was not described. How about Non-nil means active minibuffer always displays on the selected frame. Thanks.