Re: cc-mode fontification feels random

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 12 Jun 2021 13:01:03 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> If I understand something about our cc-mode functionalities (and many of
> those functionalities we don't want to loose like indentation and code
> navigation). Probably the "right" way to use tree-sitter (maybe Alan
> wants give a more precise technical description) is not only fontify but
> use the tree information to add contextual information to the text
> (something that I think cc-mode does.) And then let font-lock do the
> magic.
> 
> The tree-sitter tree is basically contextual information, and (for
> example) if we have processed the whole buffer and we already have the
> tree, then scrolling won't need to parse anything, adding or removing
> text is a localized modification, so with the previous tree we can
> re-parse only the modified region. The choice may be then if we
> propertize the text of the whole buffer or just the visible region OR if
> we want to "propertize on demand".
> 
> This will save us from the hard parsing in cc-mode to fontify "on the
> fly".

I'm not sure I understand what you are suggesting.  Can you describe
your suggestion in terms of 'face' text properties and the 'fontified'
property, and explain how those should fit into the existing redisplay
mechanisms?

> > I don't
> >really care if TS actually processes a much larger chunk of text, if
> >it does that quickly enough, but processing the resulting faces will
> >take time on the Emacs side, and that is better avoided. 
> 
> But then we won't get all the contextual information we need for
> indentation, code navigation or fold the code right?

Why not?

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