> Other parsers don't treat variable definitions to be definitions. So I > think you should adjust accordingly.
Ok > No, that's not what I meant. I'm talking about the links on the source code. Does Japanese use character byte values >= 0x80, as I removed those values from my flex (zig.l) files. In yours: ALPHA [a-zA-Z_\x80-\xff] ALPHANUM [a-zA-Z0-9_\x80-\xff] In mine: ALPHA [a-zA-Z_] ALPHANUM [a-zA-Z0-9_] Sounds like that could be the problem, sorry. Simon On Tue, 5 Sept 2023, 08:41 Shigio YAMAGUCHI, <shi...@gnu.org> wrote: > 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.nib...@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, <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 > > > > -- > Shigio YAMAGUCHI <shi...@gnu.org> > PGP fingerprint: > 26F6 31B4 3D62 4A92 7E6F 1C33 969C 3BE3 89DD A6EB >
