Re: Call for volunteers: add tree-sitter support to major modes

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  Yuan Fu <casouri@gmail.com>,  Alan Mackenzie
>  <acm@muc.de>,  theo@thornhill.no
> Date: Tue, 18 Oct 2022 18:36:08 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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:

bad_fontification.PNG
Description: PNG image