Re: cc-mode fontification feels random

[Ergus]

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.