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: Sun, 21 Mar 2021 14:49:56 +0000 Message-ID: References: <83mtuze31r.fsf@gnu.org> <838s6jdthq.fsf@gnu.org> <83im5mcd7i.fsf@gnu.org> <87h7l6t2gg.fsf@miha-pc> <83mtuwbxlh.fsf@gnu.org> 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="36449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 21 15:51:18 2021 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 1lNzQE-0009MY-7T for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 15:51:18 +0100 Original-Received: from localhost ([::1]:51192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNzQD-0001kb-6u for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 10:51:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNzP1-00015n-5N for emacs-devel@gnu.org; Sun, 21 Mar 2021 10:50:03 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35539 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lNzOx-0001AC-UO for emacs-devel@gnu.org; Sun, 21 Mar 2021 10:50:02 -0400 Original-Received: (qmail 11386 invoked by uid 3782); 21 Mar 2021 14:49:57 -0000 Original-Received: from acm.muc.de (p4fe154c6.dip0.t-ipconnect.de [79.225.84.198]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 21 Mar 2021 15:49:56 +0100 Original-Received: (qmail 7153 invoked by uid 1000); 21 Mar 2021 14:49:56 -0000 Content-Disposition: inline In-Reply-To: <83mtuwbxlh.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) 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-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=unavailable 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:266707 Archived-At: [ "frame" replaced by "terminal" where appropriate ] Hello, Eli. On Sun, Mar 21, 2021 at 12:38:34 +0200, Eli Zaretskii wrote: > > Date: Sun, 21 Mar 2021 10:30:39 +0000 > > From: Alan Mackenzie > > Cc: Eli Zaretskii , emacs-devel@gnu.org > > > ;; We're inside a minibuffer already, so if the emacs-client is trying > > > ;; to open a frame on a new display, we might end up with an unusable > > > ;; frame because input from that display will be blocked (until exiting > > > ;; the minibuffer). Better exit this minibuffer right away. > > That looks like a bug which ought to be fixed, but I've no idea where to > > start looking for the problem. > It's a "feature" we only allow a single terminal to be in the "input" > state at any given time. Er, OK. There surely must be good reasons for this. > > > `emacsclient ~/foo' causes a throw to top-level in most cases before > > > spawning a new frame to avoid some trouble, but I'm not sure if this > > > trouble applies for our case. > > When starting emacsclient, I've seen minibuffers being preserved, but I > > think I've also seen them being aborted. By trouble, I think you mean > > that described in the comment above. > I confess that I don't have a clear idea of what is the problem you > are trying to solve in the context of this discussion. Why do you > want to "move" the minibuffer when emacsclient starts a new frame (or > is it when it closes a frame?), and what does "move" mean in this > context? The following description includes things which aren't yet committed. "Move" means to move the minibuffer from frame F1 to frame F2, as for example, C-x 5 o requires when minibuffer-follows-selected-frame is t (the default). When enable-recursive-minibuffers is t, there can be a "stack" of minibuffers on a frame. The entire stack gets moved. The top minibuffer in the stack is at f->minibuffer_window, any lower elements are stored in w->prev_buffers, where w is XWINDOW (f->minibuffer_window). It is also required to move minibuffers when the frame containing them gets deleted. Otherwise the minibuffers would continue to be active, yet be inaccessible from any frame - this would be undesirable. When the (second) last frame in a --daemon Emacs gets deleted, any minibuffers it contains get moved to the initial frame. When calling emacsclient opens a new frame, these minibuffers need to be moved onto that new frame (or else be aborted, somehow). The problem I'm trying to solve here is to understand what happens when emacsclient opens a frame on a different terminal from where emacs --daemon was started, when there are active minibuffers on the original terminal. What would be nice would be for these minibuffers to be moved onto the new frame (when minibuffer-follows-selected-frame is t) or left on the other non-initial frame (otherwise). It appears, from Miha's observation yesterday, that any active minibuffers would get aborted in this case, to prevent the old frame blocking the new one. It may well be that further work in this area isn't worthwhile - just how often is somebody going to create a frame in a different terminal whilst a minibuffer is active, anyway? -- Alan Mackenzie (Nuremberg, Germany).