GNU bug report logs - #38807
[Feature request]: Support lisp workers like web workers.

Previous Next

Full log

Message #116 received at 38807 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: arthur miller <arthur.miller <at> live.com>
Cc: netjune <at> outlook.com, 38807 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#38807: [Feature request]: Support lisp workers like web
 workers.
Date: Fri, 03 Jan 2020 16:39:27 +0200

> From: arthur miller <arthur.miller <at> live.com>
> CC: "michael.albinus <at> gmx.de" <michael.albinus <at> gmx.de>, "38807 <at> debbugs.gnu.org"
> 	<38807 <at> debbugs.gnu.org>
> 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
complain.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.