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, <shi...@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.nib...@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 <shi...@gnu.org>
> PGP fingerprint:
> 26F6 31B4 3D62 4A92 7E6F 1C33 969C 3BE3 89DD A6EB
>
