Re: cc-mode fontification feels random

[Ergus <spacibba@aol.com>]

On Sat, Jun 12, 2021 at 06:16:02PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 12 Jun 2021 17:04:02 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> >> I see two approaches here:
>> >>
>> >> 1) add the tree-sitter properties/faces to the buffer text (fully or
>> >> partially on the visible regions)
>> >>
>> >> 2) use the tree-sitter information directly from the tree and add the
>> >> visible properties from there.
>> >>
>> >> This second one will require a more complete api of tree-sitter
>> >> functions exposed to elisp, but in my opinion it worth it in accuracy,
>> >> speed and simplicity (a single API to rule them all). And to support
>> >> many languages we don't actually have like rust or the fancy C++ > 11.
>> >
>> >Why can't we have both?  The information you are talking about, which
>> >is needed by Emacs features other than fontification, can be used by
>> >those other Emacs features when needed.  You seem to be saying that
>> >these two alternatives are mutually-exclusive, but you didn't explain
>> >why.
>> >
>> They are not exclusive, but redundant. If we use the current
>> infrastructure then we will spend a lot of time translating properties
>> and contextual information.
>
>That depends on what you mean by "current infrastructure".
>
Properties, properties navigation.

>> And avoiding to have part of them outdated. Navigation and
>> indentation will continue to be based on properties we need to set
>> and update all the time to make the match one by one.
>>
>> Basically we will be duplicating the information that is already in the
>> tree. Creating many list objects, overloading the gc, and so on. So we
>> potentially will save only the parsing time.
>
>Why would we do a silly thing like that?
>
to convert the tree into some lisp objects we can use with lisp
functions (to check, read, compare and so on)

>> The first one may work with a very primitive api to handle and iterate
>> the tree-sitter tree. The second one will require to use cursors,
>> finders and some other features from the tree-sitter API; improving
>> performance for sure but replacing a lot of the work lisp is doing now.
>>
>> The second approach will probably make happy the C developers more than
>> the Lisp ones.
>
>So where's the dilemma?
>
For me none, but lisp developers may not like to rely so much in an
external library.