Re: User interaction from multiple threads

[Phil Sainty]

On 2018-08-24 02:08, Eli Zaretskii wrote:
> > From: Richard Stallman <address@hidden>
> > Perhaps the minibuffer should indicate which thread is making the
> > request when that isn't the current thread.
>
> Why is that important?

Because otherwise it won't necessarily be obvious to the user that a
succession of prompts are unrelated?  They may or may not be able to
figure it out relatively easily, but that depends somewhat on how the
specific prompts in question happen to have been written.

Some kind of identifier for the source of the message seems very
sensible to me.  If nothing else, it immediately tells the user that
the question they are being asked *may* not be related to the thing
they were just doing, which I think is a useful piece of information
to lead with, as it prevents the confusion before it can occur.


> Wouldn't the prompt itself be informative enough?

Undoubtedly that would often be true, but are all prompts written in
such a specific fashion to guarantee they would be unambiguous within
any arbitrary arrangement of asynchronous prompting activity?  I would
be very surprised if that turned out to be true.  At minimum, few if
any of the existing prompts (many of which may now be triggered in
thread contexts), will have been written with this particular scenario
in mind.


> And how (in what terms) would you suggest to indicate the thread ID
> in this case?

`make-thread' takes an optional NAME argument, so perhaps that can be
used when it's set?  Otherwise some kind of internal ID would probably
have to suffice?  If NAME is not generally suitable, then perhaps we
need something additional as a human-readable identifier?


-Phil