Re: Zig parsers for Global

[Shigio YAMAGUCHI]

Hi
Please let me make a few comments.

1. Gtags

In the following source code, variable 'log_scope' seems to be
treated as a definition(-d) or a reference(-r).

[src/main.zig from https://github.com/ziglang/zig]
150    for (log_scopes.items) |log_scope| {              <== definition
151        if (mem.eql(u8, log_scope, scope_name)) <== reference
152            break;
153        } else return;

$ global -x log_scope
...
log_scope         150 src/main.zig             for (log_scopes.items)
|log_scope| {
...
$ global -x log_scope -r
...
log_scope         151 src/main.zig                 if (mem.eql(u8,
log_scope, scope_name))
...

But wouldn't it be appropriate to treat it as an other symbol(-s)?
Because other places seem to treat variables only as other symbols(-s).

2. Htags

o Function guides(--func-header) are only at the beginning and end of the file.
o Definition/reference links are not displayed at all.

Does this mean it's still a work in progress?

And one more thing.

> Also changed HTML_quoting() in 'htags/src2html.c' to help spot and make safe
> funny characters in source files, like the ones in
> 'libdb/sqlite3.c' (0xB1 and 0xC4); but this change is not really necessary.

I would appreciate it if you could focus on one theme for each patch.

Finally, thanks for all the hard work!

Regards,
Shigio

On Sat, Sep 2, 2023 at 9:44 AM Simon D <si.octal.nibble@gmail.com> wrote:
>
>
> Hi Shigio and other Global developers,
>
> I have created Zig parsers for Gtags and Htags version 6.6.10.
>
> I don't program in Zig, but have tested it on a number of Zig source files.
> Zig is an Open Source language, so you can download its source files.
>
> I did modify makeincludeindex() to include the @import() functions of Zig, but
> it didn't seem to make any difference, so I removed the code.
> The @import functions (like '#include' in C) are made into HTML links with the
> htags parser, and they work.
>
> Had to change compress() for names beginning with '@' in them.
> I don't think you need to change the version number of the format of the
> Global databases. I have left the '@' character in as part of the name, like 
> in
> the built-in function '@ptrToInt' for example, as this is what the text editor
> Kate also does when syntax hilighting Zig code. Thus it gets saved into the
> databases as '@ptrToInt'.
> But the HTML index htags generates, doesn't include an entry for names
> beginning with '@' yet, maybe one day.
>
> Also changed HTML_quoting() in 'htags/src2html.c' to help spot and make safe
> funny characters in source files, like the ones in
> 'libdb/sqlite3.c' (0xB1 and 0xC4); but this change is not really necessary.
>
> I thought I had gone wrong with the Zig function pointers, like 'xxx: fn ()',
> that are in 'struct' statements, as some of them don't get the guide/icons 
> with
> them, but these function pointers are not function definitions.
> I will fix this in the next update of the Zig parsers.
>
> I think I can add code to parse Zig function calls, so this could be a future
> enhancement.
>
> I have also fixed some minor text messages, code and doxygen code, hope they
> are ok.
>
> Hope these parsers are useful for Global.
>
> (Feature request: a Language Server Protocol [LSP] interface).
>
> I will be sending another email soon, more bugs, mainly involving strcmp().
> And one bug found in __bt_first() 'libdb/bt_seq.c' by CppCheck:
>
> 'if ((h = xxx()) == NULL) { if (h->pgno == save.page->pgno) ....}'
>
>
>
> Simon Dommett
>


-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB