> > With multiple threads asynchonously requesting input, I have a feeling
> > that users will get confused in complicated situations as a result of
> > not knowing which thread the input is for.
> Yes, and I think we all agreed that some sort of serialization is
> needed.
We agree about the serialization, but the issue I am not talking about
now is different. I am talking about managing the various input
requests -- choosing the order of the requests, and identifying which
request is being made now and on behalf of which activity.
I think this is a very important point. We've seen with the development of numerous different Emacs libraries that people will come up with vastly improved variations of standard Emacs functionality if they are given the necessary tools to make it happen.
Providing a comprehensive API to for controlling the queued interaction requests is probably more important than desiging the perfect UI for it.
> And how (in what terms) would you suggest to indicate the
> thread ID in this case?
I don't know enough about the thread feature to figure that out.
Perhaps based on the thread's top-level function call?
Do threads have names?
Threads do have names, but providing one is optional. The function signature is (FUNCTION &optional NAME).
As for givng the toplevel function name, I'd expect most toplevel functions are actually LAMBDA forms.
Regards,
Elias