Re: User interaction from multiple threads

[martin rudalics]

> 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.

... or a key sequence ...

> 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,

... the (currently) active 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(??).

I'd want to relax the organization of minibuffers.  Instead of
maintaining them in form of a stack, allow random access to the
minibuffer list.  Instead of having always only the one on top of the
stack active, allow to make any of them the active one.  And allow any
of them to appear in its own dedicated minibuffer window where the
selectedness of that window's frame indicates the currently active
minibuffer.

martin