emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cc-mode fontification feels random


From: Eli Zaretskii
Subject: Re: cc-mode fontification feels random
Date: Sat, 12 Jun 2021 18:16:02 +0300

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

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]