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: Sun, 21 Mar 2021 17:43:02 +0200 Message-ID: <83blbcbji1.fsf@gnu.org> References: <83mtuze31r.fsf@gnu.org> <838s6jdthq.fsf@gnu.org> <83im5mcd7i.fsf@gnu.org> <87h7l6t2gg.fsf@miha-pc> <83mtuwbxlh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26932"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 21 16:43:58 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 1lO0FA-0006td-Jf for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 16:43:56 +0100 Original-Received: from localhost ([::1]:40672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO0F9-0004bR-Lh for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 11:43:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO0EJ-0004A2-Ds for emacs-devel@gnu.org; Sun, 21 Mar 2021 11:43:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41266) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO0EI-0006DN-1j; Sun, 21 Mar 2021 11:43:02 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3608 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lO0EF-0006bK-Kg; Sun, 21 Mar 2021 11:43:01 -0400 In-Reply-To: (message from Alan Mackenzie on Sun, 21 Mar 2021 14:49:56 +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:266710 Archived-At: > Date: Sun, 21 Mar 2021 14:49:56 +0000 > Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org > From: Alan Mackenzie > > > 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. The "good reasons" are that we are unable to handle input from two or more keyboards: they will mix up into a single garbled stream of input events. That's because there's only one channel through which Emacs reads input -- the single event queue we have in keyboard.c. > 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). AFAIU, this just means copying the data that describes the stack of the minibuffers, is that right? If so, what is left on the frame that is the source of that: a single empty minibuffer? or the entire original stack? or something else? > 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. And what's wrong with aborting the active minibuffer in this case? isn't that what the user wants?