Re: Zig parsers for Global

[Shigio YAMAGUCHI]

Hi,
> From what I gathered about the '|x|' statement in Zig, it is like an index 
> variable,
> like the first 'y' in the C/C++ code 'for(int y = 0; y < 4;)', that's why I 
> made it
> a definition; can change it if you like.

Other parsers don't treat variable definitions to be definitions. So I
think you should
adjust accordingly. Your parser also seems to treat normal variables
as other symbols.

> > o Definition/reference links are not displayed at all.
>
> It is just the names beginning with a '@' that are not displayed in the htags 
> main
> 'Definitions' (index), I thought.

No, that's not what I meant. I'm talking about the links on the source code.
Definition/reference links in the source code were not displayed at all
at least as far as I've processed zig source code
(https://github.com/ziglang/zig).
The coloring process is complete (comment, string, reserved word and
etc) though.

Regards,
Shigio

On Tue, Sep 5, 2023 at 3:07 PM Simon D <si.octal.nibble@gmail.com> wrote:
>
> Hi,
>
> > 150    for (log_scopes.items) |log_scope| {              <== definition
>
> From what I gathered about the '|x|' statement in Zig, it is like an index 
> variable, like the first 'y' in the C/C++ code 'for(int y = 0; y < 4;)', 
> that's why I made it a definition; can change it if you like.
> Then on the next line 'if (mem.eql(u8, log_scope, ...' , it would be a 
> reference.
>
> > o Definition/reference links are not displayed at all.
>
> It is just the names beginning with a '@' that are not displayed in the htags 
> main 'Definitions' (index), I thought.
>
> > Does this mean it's still a work in progress?
>
> Yes
>
> > Finally, thanks for all the hard work!
>
> Thanks
>
> Simon
>
>
> On Tue, 5 Sept 2023, 05:17 Shigio YAMAGUCHI, <shigio@gnu.org> wrote:
>>
>> 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



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