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

[Po Lu <luangruo@yahoo.com>]

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.

Anyway, I'll try to explain what the problem is with the fontification.
BEGIN_A_KIND_OF_SECTION starts a closure, ENTRY (dx, dy, shx, shy)
expands to the important part of which is a nested function declaration
(that is then put in a struct, etc, but that is not really relevant
here):

  [use: fcsr, f20, f21, f22 capture: etc]
  __section_name_entry (dx, dy, shx, shy, AP, ...)
      float dx, dy, shx, shy;
      frame_t *AP;
  {
    ...

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.

The fontification of "_P" is also wrong.  It is a macro that expands to
nothing if prototype checking is not enabled in the compiler, and
otherwise literally expands to each one of its arguments.  Yes, the way
the macro is defined is not standard C, but CC Mode has so far fared
quite well:

#   define _P(args...) ##args

register float is the type of argument that is expected to be taken by
the closure.  There can only be several: register float, register
doublefloat, register int, doubleword, long.

section_name is an argument to the macro, and is used to name both
section_name_desc and __section_name_entry, and other things:

  struct [align: 8] proc_jump_struct section_name_desc;
  [use: fcsr, f20, f21, f22 capture: etc]
  __section_name_entry (dx, dy...
  ...
  section_name_desc.entry = (char *) &__section_name_entry;
  ... and more code here ...

so it should not be fontified as a function either.  In tree-sitter,
"cells" (an argument in the K&R area) is also fontified as a function.

> This kind of "argument" is not useful.

Why?