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: Fri, 17 Aug 2018 12:12:01 +0300 Message-ID: <83h8jtgxwe.fsf@gnu.org> References: <838t59j821.fsf@gnu.org> <5B73DF10.5070200@gmx.at> <87muto5998.fsf@gmx.de> <5B73ED7E.5000102@gmx.at> <87in4b6hwf.fsf@gmx.de> <5B741C4E.6060403@gmx.at> <83sh3fin70.fsf@gnu.org> <5B756C41.1040600@gmx.at> <83a7pmifvd.fsf@gnu.org> <5B76782F.6060303@gmx.at> <83mutlh1s8.fsf@gnu.org> <5B7688AE.70205@gmx.at> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534497051 736 195.159.176.226 (17 Aug 2018 09:10:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 09:10:51 +0000 (UTC) Cc: michael.albinus@gmx.de, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 17 11:10:47 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 1fqamL-0008Ta-02 for ged-emacs-devel@m.gmane.org; Fri, 17 Aug 2018 11:10:45 +0200 Original-Received: from localhost ([::1]:60767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqaoR-0003bg-8s for ged-emacs-devel@m.gmane.org; Fri, 17 Aug 2018 05:12:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqano-0003bP-Hv for emacs-devel@gnu.org; Fri, 17 Aug 2018 05:12:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqank-0007uj-Jk for emacs-devel@gnu.org; Fri, 17 Aug 2018 05:12:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqank-0007ua-GB; Fri, 17 Aug 2018 05:12:12 -0400 Original-Received: from [176.228.60.248] (port=2476 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fqank-00076V-35; Fri, 17 Aug 2018 05:12:12 -0400 In-reply-to: <5B7688AE.70205@gmx.at> (message from martin rudalics on Fri, 17 Aug 2018 10:34:54 +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:228634 Archived-At: > Date: Fri, 17 Aug 2018 10:34:54 +0200 > From: martin rudalics > CC: michael.albinus@gmx.de, emacs-devel@gnu.org > > > That just postpones the question, because now we need to have some > > infrastructure in place that "knows" which frame's input goes to what > > thread. > > To the thread that owns that frame. > > > And it leaves intact the fundamental implementation-level > > difficulty, about which I will write shortly: namely, that we have > > only one input "pipeline", which needs to somehow be enhanced to > > multiplex between several threads. The fact that the prompt is shown > > in another frame doesn't resolve the difficulty with channeling the > > input in response to that prompt, especially when multiple different > > prompts are being displayed at the same time. > > There would still be only one input "pipeline" at any time, namely > that of the selected frame. Just that switching frames now would call > for "saving" the input pipeline of the frame switched from and > "restoring" any input pipeline of the frame switched to. Tricky at best, IMO. Frame switch is just another input event. I guess you are thinking about adding calls to thread-yield into input processing code? Also, does it mean that every call to make-thread will now pop up a new frame? > IIUC we are able to save and restore an input pipeline when we enter > and leave a recursive minibuffer so the mechanism for doing such > switches seems to exist for minibuffer reading. What will appear in the minibuffer window of the previously-selected frame while we interact with another thread's frame? > And reading a key sequence through the echo area is IIUC synchronous > anyway so a user cannot practically switch frames during that. Are you sure they cannot switch frames in the middle of reading from the minibuffer?