bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38807: [Feature request]: Support lisp workers like web workers.


From: HaiJun Zhang
Subject: bug#38807: [Feature request]: Support lisp workers like web workers.
Date: Mon, 6 Jan 2020 13:08:28 +0800

在 2020年1月4日 +0800 PM5:51,Eli Zaretskii <address@hidden>,写道:
Date: Sat, 4 Jan 2020 17:33:18 +0800
From: HaiJun Zhang <address@hidden>
Cc: address@hidden, address@hidden

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.


reply via email to

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