> From: Po Lu > Cc: emacs-devel@gnu.org, Yuan Fu , Alan Mackenzie > , theo@thornhill.no > Date: Tue, 18 Oct 2022 18:36:08 +0800 > > Eli Zaretskii writes: > > > It does? Which part(s) are "much worse" and why? > > > > The code you presented is invalid C, so I cannot see how we could pass > > any objective judgment about which fontification is "correct". > > It is not invalid C, at least not for this (proprietary) C compiler. This part definitely isn't valid: extern maybe_tls (int) errno; $ gcc -c buggy_c.c buggy_c.c: In function 'maybe_tls': buggy_c.c:1:26: error: expected declaration specifiers before 'errno' 1 | extern maybe_tls (int) errno; | ^~~~~ buggy_c.c:1:21: error: parameter name omitted 1 | extern maybe_tls (int) errno; | ^~~ buggy_c.c:2: error: expected '{' at end of input And this: BEGIN_A_KIND_OF_SECTION ({ ENTRY (dx, dy, shx, shy) float dx, dy, shx, shy; if (!bar (other_function (dx, dy, shx, shy), etc, etc, etc)) die ("bar", sys_errlist[errno]); }, register float, section_name); can only be valid C if BEGIN_A_KIND_OF_SECTION does something very creative, like expands to nothing at all. So, for a fair discussion, please show the macros used here, and let's see what does tree-sitter do when it's shown the macros. > Notice how tree_sitter fontifies everything between ENTRY and shy as a > type, while dx, dy, shx, shy are actually arguments in the "K&R area". > They are fontified correctly by CC Mode, which only fontifies "float" as > a type. Why is that "much worse" than what CC Mode does? Just yesterday I had a perfectly valid C code where CC Mode was unable to fontify several function calls correctly. I attach it below. You can see it yourself: go to line 2000 in treesit.c of the feature/tree-stter branch. Unlike many CC Mode bugs, this one isn't transient: killing the buffer and revisiting the file reproduces the same problem. (This problem seems to be solved in Emacs 29, btw. But I see its like almost every day in other situations.) I'm quite sure CC Mode "succeeds" with your example of invalid C code simply by sheer luck. And what's more important to me is that it fails in much simpler, straightforward cases, where I wouldn't expect any trouble at all. > The fontification of "_P" is also wrong. The code you posted didn't include the definition of P_, so how do you expect a parser to guess what it is? Include it in the code, and let's see then what happens. > struct [align: 8] proc_jump_struct section_name_desc; > [use: fcsr, f20, f21, f22 capture: etc] > __section_name_entry (dx, dy... > ... This is valid C? And after all that said, I'll trade CC Mode's fontifications for much more performant C mode any day, even if the faster mode sometimes errs. The CC Mode's performance is abysmally slow. > > This kind of "argument" is not useful. > > Why? Because it's biased. Here's the picture I promised: