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: User interaction from multiple threads Date: Tue, 14 Aug 2018 18:12:54 +0300 Message-ID: <838t59j821.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534259464 14399 195.159.176.226 (14 Aug 2018 15:11:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2018 15:11:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 14 17:11:00 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 1fpayK-0003cE-6s for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 17:11:00 +0200 Original-Received: from localhost ([::1]:44797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpb0Q-00006B-GD for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 11:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpb06-0008P3-BX for emacs-devel@gnu.org; Tue, 14 Aug 2018 11:12:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpb02-0000IJ-8q for emacs-devel@gnu.org; Tue, 14 Aug 2018 11:12:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpb02-0000I8-4M for emacs-devel@gnu.org; Tue, 14 Aug 2018 11:12:46 -0400 Original-Received: from [176.228.60.248] (port=3841 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fpb01-00045W-KR for emacs-devel@gnu.org; Tue, 14 Aug 2018 11:12:45 -0400 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:228527 Archived-At: For background, see bugs #25214 and #32426. Some additional discussion was here: http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00607.html I'm trying to revive those past discussion, because we now have a serious and useful application that bumped into these problems, where formerly we only had theoretical discussions and toy programs. After thinking some more about this, I think we should first pay attention to conceptual issues related to this, before we start talking about implementation. The conceptual problem I see here is the UX when more than one thread needs to interact with the user. For the following description, recall that normally only the main thread will wait on the keyboard descriptor (why that happens was explained in bug#25214). Use case #1: . 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? Use case #2: 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? If the latter, how do we indicate to the user that there is a prompt from another thread? Use case #3: Similar, but now 2 or more non-main threads prompt the user, one after the other, in quick succession. What should happen now, and how will the user know there are multiple prompts? Thoughts?