[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
User interaction from multiple threads
From: |
Eli Zaretskii |
Subject: |
User interaction from multiple threads |
Date: |
Tue, 14 Aug 2018 18:12:54 +0300 |
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?