在 2020年1月4日 +0800 PM5:51，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Sat, 4 Jan 2020 17:33:18 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> >
> > How would that work? We don't have any such message queues in Emacs,
> > and no machinery to display them, nor for telling the user which job
> > reported the message.
> >
> > Some APIs need to be added for communication use. The UI part of the email client known what happens and
> > will tell the user.
>
> Sorry, such general and vague suggestions aren't useful. You need to
> propose specific changes that are consistent with how Emacs is
> designed and implemented. You need to describe those new APIs, and
> you need to tell how will they be used by the existing code that
> displays messages in the echo area.

On the UI part, create a worker like this:
——————xxxx——————
fetch_mail_worker = new Worker(xxx)

fetch_mail_worker.onmessage = function (msg) {
    // display the new mail
};

fetch_mail_worker.onerror = function (error) {
    message(“fetch mail error: %s”, error)
};

fetch_mail_worker.start()
——————xxxx———————

On the worker part, fetch emails and post messages or error:
——————xxxx———————-
while(true) {
    error = fetch_next_mail(&msg)
    if error != nil {
       post_error(error)
       break
    }

    post_message(msg)
}
——————xxxx———————-

> It goes without saying that an editor different from Emacs could be
> designed from scratch to support multi-threading between the UI and
> the processing engine. The issues at hand are (a) would such an
> editor be as powerful and flexible as Emacs, in terms of letting the
> programs written in the extension language control what is being
> displayed and where; and (b) would it be possible to add such
> threading to Emacs as it is now without completely redesigning how it
> processes input events and how it displays messages to the user.
>
> So any proposals in that direction must be more concrete and directly
> related to how Emacs works now, otherwise this will not be a
> discussion of any practical interest for Emacs development.

I don’t known if the above code is concrete.