Re: cc-mode fontification feels random

[Eli Zaretskii]

> Date: Sat, 12 Jun 2021 17:23:44 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> >> 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.

If you mean the special properties used by CC Mode, then we are not
restricted by using them.  We can invent new ones, if needed.  Or use
something other than text properties, if that makes sense.  IOW, I
don't see why this would be something we need to bother about at this
point.

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

We could have accessor functions exposed to Lisp, if that's needed.

Again, I don't see why this should bother us now.  We have enough
means to solve these problems.