Re: emacs rendering comparisson between emacs23 and emacs26.3

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 28 Mar 2020 18:43:13 +0200
> 
> >>> Apparently so:https://github.com/karlotness/tree-sitter.el
> >> Sorry, this one is more active:
> >> https://github.com/ubolonton/emacs-tree-sitter
> > Do any of those support font-lock?  Because I think that's the context
> > of Clément's question about modules.
> 
> Apparently they aim to replace it with a new specialized jit-highlighter:
> 
> https://github.com/ubolonton/emacs-tree-sitter/issues/4
> https://github.com/ubolonton/emacs-tree-sitter/pull/16
> 
> But that's not due to modules' limitations, but because of font-lock's 
> limitations (allegedly).

I'm not sure what limitations they have in mind: font-lock supports
functions, not just regular expressions.  Why does it have to be
replaced?

In any case, tossing JIT font-lock and going back to using all kinds
of hooks is a non-starter.  Emacs 19 and 20 did that, and we found
this method to have fundamental problems which couldn't be resolved in
satisfactory ways.  That is why Emacs 21 introduced jit-lock.el and
the associated support in the display engine for fontifying what is
about to be displayed.  Going back to hooks (if that is what they
intend to do; I couldn't be sure from reading the discussion) is a
step in the wrong direction.

Likewise using overlays instead of text properties (again, not sure
they actually intend doing that, maybe they just talked about it) is
wrong even if we assume the tree-based implementation that sits on a
branch.

More generally, I'm surprised, to say the least, that such a
significant job is being done without saying even a single word here,
let alone making sure the basic design is deemed reasonable by the
core developers.  Do they really think this will make the acceptance
of the code easier?