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 16:37:42 +0000 Message-ID: References: <838s6jdthq.fsf@gnu.org> <83im5mcd7i.fsf@gnu.org> <87h7l6t2gg.fsf@miha-pc> <83mtuwbxlh.fsf@gnu.org> <83blbcbji1.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="24920"; 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 17:38:50 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 1lO16I-0006PT-Bj for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 17:38:50 +0100 Original-Received: from localhost ([::1]:52258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO16H-00076b-CX for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 12:38:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO15I-0006H8-FL for emacs-devel@gnu.org; Sun, 21 Mar 2021 12:37:48 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:38832 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lO15G-0003pu-64 for emacs-devel@gnu.org; Sun, 21 Mar 2021 12:37:48 -0400 Original-Received: (qmail 84295 invoked by uid 3782); 21 Mar 2021 16:37:43 -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 17:37:43 +0100 Original-Received: (qmail 17517 invoked by uid 1000); 21 Mar 2021 16:37:42 -0000 Content-Disposition: inline In-Reply-To: <83blbcbji1.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=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:266714 Archived-At: Hello, Eli. On Sun, Mar 21, 2021 at 17:43:02 +0200, Eli Zaretskii wrote: > > 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. Thanks, that's very clear. > > 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? Not quite: if there're also minibuffers in the destination frame (with minibuffer-follows-selected-frame set to nil), the two minibuffer stacks get combined in the destination. > 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? What is left on the source frame is a single minibuffer, " *Minibuf-0*", which functions as the null minibuffer. > > 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? I don't think there's all that much wrong with aborting it. It is a little inconsistent with creating a new emacsclient frame on the same terminal - here, any existing minibuffers survive. > isn't that what the user wants? I honestly don't know. But as long as the code ends up doing something consistent and reasonable (and this aborting the minibuffers _is_ reasonable), I don't think it's worth spending too much time on. Given how there's just one keyboard input stream, it would be a LOT of work to make that one input stream per terminal. We surely don't really need this. -- Alan Mackenzie (Nuremberg, Germany).