Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

On 29.03.2020 17:30, Eli Zaretskii wrote:

> > 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?

Hence "allegedly". I haven't looked into this issue, or this project, 
deep enough to say more.

> 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)

I think they're still experimenting. But whatever they come up with in 
that alternative jit highlighter, could hopefully be ported to jit-lock.

> 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.

Yup.

> 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.

There is no point in taking offense at that. I think this is just 
another case of the extended developer community, and especially 
newcomers, being uncomfortable with our old-timey tools. I'm pretty sure 
none of the participants in that project even read your earlier posting 
to emacs-devel about tree-sitter.

And if you ask some of them why they didn't think to ask on the mailing 
list first, the answers will likely be very benign like the story here: 
https://www.reddit.com/r/emacs/comments/fqji2t/any_elisp_projects_looking_for_contributors/flqs6v9/

> Do they really think this will make the acceptance
> of the code easier?

They really hope they won't have to ask.

It's a blessing and a curse of Emacs's extensibility. If this project is 
successful, it is likely to reside entirely outside of Emacs core. Just 
like the lsp-mode project lives outside, and only filed a couple of bug 
reports when the built-in JSON support (which they really have to use) 
showed insufficient performance characteristics.