From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 15 Aug 2018 19:47:06 +0300 Message-ID: <83tvnvinlh.fsf@gnu.org> References: <838t59j821.fsf@gnu.org> <5B73DF10.5070200@gmx.at> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534351616 2273 195.159.176.226 (15 Aug 2018 16:46:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Aug 2018 16:46:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 15 18:46:52 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fpywZ-0000O9-Fl for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2018 18:46:47 +0200 Original-Received: from localhost ([::1]:50577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpyyf-0002B2-QJ for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2018 12:48:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpyxZ-00028h-Gv for emacs-devel@gnu.org; Wed, 15 Aug 2018 12:48:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpyxH-0002qy-9o for emacs-devel@gnu.org; Wed, 15 Aug 2018 12:47:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpyx3-0002dw-K2; Wed, 15 Aug 2018 12:47:28 -0400 Original-Received: from [176.228.60.248] (port=1857 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fpywx-0002WX-NP; Wed, 15 Aug 2018 12:47:12 -0400 In-reply-to: <5B73DF10.5070200@gmx.at> (message from martin rudalics on Wed, 15 Aug 2018 10:06:40 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228562 Archived-At: > Date: Wed, 15 Aug 2018 10:06:40 +0200 > From: martin rudalics > > > . The main thread is waiting for user input. The user didn't yet > > type anything > > . A non-main thread runs Lisp that prompts the user for some input > > > > In this case, we probably want the following input to go to the > > prompting thread, right? But it might also be the case that the > > user actually wants the input to go to the main thread, e.g. to > > perform some unrelated command. Should we allow that? If yes, how > > should Emacs know which thread should receive what the user types? > > If we make a rule that each thread owns a frame with a minibuffer, the > decision which thread receives input on a GUI is left to the windowing > subsystem. As you well know, when the user switches to another frame, we redisplay the mini-window on the newly selected frame to display the same prompt/echo there as was displayed on the previous selected frame. So what you suggest won't work without very serious surgery to our handling of the mini-window (which is already quite complex and fragile). > We would have to emulate that behavior on a TTY somehow > but that should be an implentational detail. And that is another complication, of course. I think that at least at first we should go for some kind of serialization of using the mini-window, because having several ones active at the same time is a much harder trick to pull. > > Same as the previous, but now the user is in the middle of typing a > > key sequence, when the non-main thread prompts. For example, > > suppose the user has typed "C-x". > > > > What do we want to happen now? Do we "preempt" the main thread and > > let the following input to go to the prompting thread? Or do we let > > the prompting thread wait until the main thread reads a full key > > sequence and runs the command bound to it? If the former, what to > > do with the partial key sequence ("C-x") that the user typed? > > The partial key sequence should be preserved and typing resumed where > it was interrupted when the user switches back to the main thread by > selecting a frame owned by the main frame. Would be nice, I agree, but again probably not quite simple.