bug#42028: [Feature Request] 27.0.91; Provide the ability dynamic modules to post events in emacs event loop

[Eli Zaretskii <eliz@gnu.org>]

> From: Ivan Yonchovski <yyoncho@gmail.com>
> Cc: 42028@debbugs.gnu.org
> Date: Wed, 24 Jun 2020 20:33:29 +0300
> 
> > You cannot easily post to the queue from a worker thread, because the
> > queue cannot be posted to asynchronously.
> 
> AFAIK this is not possible at all - thus this feature request.

Your feature just asked for a way to queue events, it didn't say
anything about doing that asynchronously, not from a function invoked
by the main thread.  If you mean the latter, then it AFAIU would need
a serious redesign of the Emacs event queue, to make it accessible
from several threads running in parallel at once.

> > Again, I don't see the wider picture.  Are you familiar with how the
> > current JIT font-lock works?  If so, can you explain which parts of
> > that will be replaced/modified, and how?
> 
> AFAIK the initial tree-sitter parsing (which does not involve anything
> emacs related) may take 200-300ms. In other editors (e.g. vscode) this
> part is not happening on the UI thread but in some extenal background
> thread which then passes the AST to the main UI thread to do the actual
> fontlock. IMO this model might be replicated in emacs in the event of TS
> integration.

What you describe is very different from how JIT font-lock works now.
Which is why I asked the question: I know (more or less) how it works
in other editors, I just don't yet understand well enough how
something like that would fit into the existing fontification
framework.  I hope there is a way of fitting it, because otherwise it
would mean a serious surgery of the display engine as well, which will
make the job significantly larger and harder.