[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#38807: [Feature request]: Support lisp workers like web workers.
Date: Fri, 03 Jan 2020 16:39:27 +0200

> From: arthur miller <address@hidden>
> CC: "address@hidden" <address@hidden>, "address@hidden"
>       <address@hidden>
> Date: Fri, 3 Jan 2020 14:19:40 +0000
> > Then 3 can be done in a separate thread from 2 and 1?
> > How would that help?  Until 3 is done, the user doesn't see the
> Couldn't prepare and converting to bitmap, inclusive rendering the bitmap bo 
> done in a separate thread from
> displaying the same?

We don't really generate a bitmap, it's an inaccurate description of
what the terminal-specific backend of the display engine does.

And if you change it to generate a bitmap, then doing so is most of
the work, and it needs to consult Lisp data, at least in its current
incarnation.  So proposing that this runs in a separate thread still
doesn't solve the problem of separating some significant workload from
Lisp, that is something that needs to be designed.

> Of course, displaying can not be done until previous work has finished, so I 
> don't know if Emacs could
> interleave the work with something else useful?

In general, it is not useful to have a display system that doesn't
update the screen in near-real time.  If you ever tried editing via a
slow remote connection, you know what I mean.  So display must happen
very soon after the command which triggers it finishes, or users will

reply via email to

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