Re: emacs rendering comparisson between emacs23 and emacs26.3

[조성빈]

> 2020. 3. 29. 오후 11:32, Eli Zaretskii <address@hidden> 작성:
> 
> 
>> 
>> 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?

According to them, font-lock doesn’t provide enough control. This is the exact 
text quoted from the linked issue:

>> so, we don't need to reinvent the wheel but neither rely on font-lock in a 
>> way that limit us, as I see it, we can implement our own syntax highlight 
>> functions for each grammar available and let font-lock use them instead of 
>> the defaults. Unless, of course, I'm missing something.
> 
> That only covers how to highlight a region. I think the main complexity is in 
> the change-handling mechanisms, i.e. which regions should be re-highlighted, 
> when.

I don’t know about font-lock enough to say whether this is true or not. 

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

Actually I’m surprised that people here on the mailing list expects people to 
ask here — I think most people aren’t even aware of this list, and even if they 
do, they prefer working on Github + MELPA, with the community. 
I’m pretty sure they aren’t aiming to merge the code into Emacs — they’re in to 
write another external package, like lsp-mode or magit.