[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User interaction from multiple threads

From: Phil Sainty
Subject: Re: User interaction from multiple threads
Date: Wed, 29 Aug 2018 01:05:35 +1200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 28/08/18 17:38, Eli Zaretskii wrote:
> several minibuffers doesn't solve the basic problem, which is: how
> should Emacs decide which of the threads' prompts gets submitted to
> the user at any given time.  When we solve that basic problem, we
> could talk about the details like whether this happens in the same
> minibuffer or in several.

Backing up a little, the notion of multiple minibuffers seems like it
could be relevant to the question of whether we are dealing with
low-level user interactions, or with the higher-level functions used
for asking the user questions.

Is that still an open question?

IIUC the main concern about dealing with user interaction at a low-level
was the point about the prompt already having been generated by the time
the interaction takes place.

At face value, it seems to me that if we had per-thread minibuffers
then perhaps that concern goes away?  I.e. it wouldn't matter that a
given thread had written a prompt to the minibuffer before the
low-level interaction was requested, if the minibuffer it had written
to wasn't being used by the main thread and/or other threads?

(I do recall some earlier discussion about the possibility of thread-
specific frames being created.  I didn't understand the purpose of
that at the time, but perhaps it was similar?)

If handling the user interactions at a low level is desirable, and
multiple minibuffers could enable that, then perhaps the practicality
(or lack thereof, as the case may be) of thread-specific minibuffers
is more than just a "detail", and might factor into the overall
approach that is taken?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]