Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 15 Aug 2018 14:27:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> In that window, the commander also gives me the opportunity to, at any
> time, pause, resume and cancel copying.  And it allows to do copying
> in a non-blocking "background" mode.  That latter option is quite
> valuable because I only after some time may detect that copying takes
> too long and I would like to perform some other synchronous activity
> before it has finished.
> 
> In this scenario, the entire copying operation is controlled by the
> window dedicated to that copying thread and all my dialog with that
> thread goes through that window (and maybe some modal child window
> popping up on top of it).  Maybe I'm biased - but I would still
> consider this a worthwhile behavior.

It is a worthy behavior, but it would require that we rethink,
redesign, and reimplement most of the Emacs keyboard stuff and the
higher-level abstractions that read from the minibuffer.  For
starters, recall that reading from the minibuffer is mostly a trick:
we just enter recursive editing.  The keyboard handling code has
almost no idea that something special is going on, and it doesn't
distinguish between "normal" top-level keyboard input and input in
response to a minibuffer prompt.  Your proposal in affect means that
keyboard input should be sensitive to the current buffer, and do
different low-level things in different buffers, like send input to a
different thread.  This completely inverts how things work now: we
first read the input, insert it into the minibuffer, and then
higher-level code works on the text in the minibuffer.  By contrast,
you want input to be sent to keyboard code from a buffer(??).