Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Aug 2018 10:34:07 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: rms@gnu.org, hw@adminart.net, emacs-devel@gnu.org,
>  emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, gazally@runbox.com
> 
> On 2018-08-24 02:08, Eli Zaretskii wrote:
> >> From: Richard Stallman <rms@gnu.org>
> >> 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.

Indeed, so maybe those prompts which don't explain themselves (I
expect them to be a small minority) should be improved.

> Some kind of identifier for the source of the message seems very
> sensible to me.

The identifier must be very informative and specific, and I expect
that to be difficult, given the small screen estate we devote to
prompts (of which the ID will have to be a small part).

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

We seem to have different expectations about the current state of
affairs in this aspect, so maybe a small survey should help us make
the proverbial reality check?

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

I don't expect anyone to remember which name corresponds to what job
that is running in the background, when there are enough of them.
That name will have to come from some Lisp written by the same
programmers whom you don't trust to provide self-explanatory prompts,
so we are back to the same problem (except that a thread name will
normally be shorter, so less informative and less specific).