GNU bug report logs - #59415
29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sun, 20 Nov 2022 17:56:02 UTC

Severity: normal

Found in version 29.0.50

Done: Yuan Fu <casouri <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: casouri <at> gmail.com, 59415 <at> debbugs.gnu.org
Subject: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file
Date: Mon, 21 Nov 2022 14:41:11 +0200
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Bug Report Emacs <bug-gnu-emacs <at> gnu.org>
> Date: Sun, 20 Nov 2022 22:56:12 +0100
> 
> > I tried the "top-level node” approach, and it didn’t help in
> > package-rrc.c: the top-level node (a function definition) is still too
> > large (spans 7680306-9936062). Since the case I described in the
> > comment against using treesit-node-on is the exception rather than the
> > norm, maybe we can go the other way around: use treesit-node-on first,
> > and if the node seems too small (by some heuristic), enlarge it to
> > some degree.
> >
> 
> Makes sense!
> 
> BTW, should the chunk-size of jit-lock be up for discussion again?  I
> ran the benchmarks from this thread [0] on this file, and it seems like
> increasing the chunk-size from 1500 to 4500 by 500 increments makes it
> average from 2 seconds to 1.65.
> 
> The density of that file absolutely is a concern performance-wise.

FWIW, if the root cause is the humongous data structure, I'm not too
worried, because such cases are extremely rare.  If some clever idea arises
that could improve things without endangering more practical use cases, then
fine; otherwise, I'm okay with the slightly slower performance in these
extreme cases -- after all, the interactive responsiveness is not that bad.

But I still don't understand why fontifications stopped _completely_
starting at that line.  That is, if the entire strict is in error, why most
of it is fontified, and only the last party isn't? what is the mechanism
which causes that?

Thanks.




This bug report was last modified 2 years and 183 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.