So, I thought that since the Verilog ctags parser already supports both Verilog and SystemVerilog, it would be a matter of enabling the latter within Geany. But I'm currently stuck at creating a proper tag map in tm_parser.c - I didn't consider that tags have *meaning*.

I understood that tag categories were named mostly for convenience, but apparently the behavior of something marked as `tm_tag_variable_t` is not the same as that of something marked `tm_tag_local_var_t`, for example. And now, the problem is that SystemVerilog is not a "programming language" but a hardware description language, so trying to figure out how a "port" or a "module" maps to a set of tags intended for programming is complicated. If this were a matter of "getting creative" and assigning the tags randomly, that'd be done, but apparently I need to be careful because assigning one tag or another will result in different propagation rules, showing up or not on the left panel, etc.

For the time being I created a draft PR so I can discuss it further.

(Right now, there is a commit that does the SV integration, but the result is little more than what I would have gotten by adding a bunch of keywords to the filetypes.systemverilog file. The second commit attempts to do the right thing but it's still a WIP.)

I added a few review comments - mostly, since the filetype uses an existing lexer, it doesn't have to be a builtin filetype.

> I understood that tag categories were named mostly for convenience, but apparently the behavior of something marked as tm_tag_variable_t is not the same as that of something marked tm_tag_local_var_t, for example. And now, the problem is that SystemVerilog is not a "programming language" but a hardware description language, so trying to figure out how a "port" or a "module" maps to a set of tags intended for programming is complicated. If this were a matter of "getting creative" and assigning the tags randomly, that'd be done, but apparently I need to be careful because assigning one tag or another will result in different propagation rules, showing up or not on the left panel, etc.

There are many other languages that don't fit the "classical programming language" pattern - for them, you can make the assignments almost arbitrarily. Just avoid `tm_tag_local_var_t` which doesn't show symbols in the sidebar. `tm_tag_undef_t` ignores the symbol completely. You also have to specify these in the groups below so they are shon correctly in the sidebar.

@cousteaulecommandant pushed 1 commit.

c4bc40595d6baa93324d8ec18c3c51089290bf6b !TODO! (WIP) SystemVerilog: provide appropriate Ctags

OK, [made the changes]

Looks good.

I don't quite understand the use of tm_tag_local_var_t. I was thinking that perhaps it was only hidden on the sidebar but still accessible via Ctrl-click, but that doesn't seem to be the case.

This is used for parsers like C/C++ that also parse function bodies and extract all variables from functions - displaying them in the sidebar is just too verbose. I don't remember exactly how ctrl+click is implemented for these but it's possible that it works only within a function. I don't know if there is something in the verilog parser where tm_tag_local_var_t could be applied.

Overall, my concern is what's the purpose of the different tags. I think it has to do with how they "propagate" to other files and contexts, and that one tm_tag_t behaves differently from another.

The only problem I can think of is what we call "scope autocompletion". E.g. for C something like ```C typedef struct { int x; int y; } Foo;

int main(void) { Foo foo; foo. // <--- here you should get an autocompletion popup with x and y } ```

I think `.` is hard-coded in the Geany code and the tag manager checks whether `foo` is of a type that can contain members - see https://github.com/geany/geany/blob/c043996a9a3dc1b0aa36571cd5f5d61fd8d2eb59... This typically works well for "normal" languages but honestly we kind of ignore what mess it could produce in other languages ;-).

For example, if I open a file that declares a certain C typedef, or C++ class, and use it in another file, it appears highlighted in light blue. I suppose this has to do with ctags "exporting" the type to other files.

What we do is that we extract tags that can be types https://github.com/geany/geany/blob/c043996a9a3dc1b0aa36571cd5f5d61fd8d2eb59... and then inject the names of these types to all the Scintilla editors as fake keywords so they get colorized.

However, you'd have to enable this behavior for Verilog in https://github.com/geany/geany/blob/c043996a9a3dc1b0aa36571cd5f5d61fd8d2eb59... otherwise no such coloring will happen. The index 3 means that the type goes to keyword at index 3 which however isn't defined for verilog in https://github.com/geany/geany/blob/c043996a9a3dc1b0aa36571cd5f5d61fd8d2eb59... and would have to be added there. The verilog lexer seems to define more keyword groups so it should work if you decide to give it a try. https://github.com/geany/geany/blob/c043996a9a3dc1b0aa36571cd5f5d61fd8d2eb59...

So it depends whether you want to enable such a coloring - if not, it shouldn't happen automatically and you are free to use whatever `tm_tag_...` you wish - otherwise you have to be more careful.

I don't know how much finished this PR is but I added a few comments.

Getting there, slowly but surely. Thanks a lot for your feedback and guidance :)

I'm not sure if you want to apply some of the changes you made to #4037 to this PR as well.

Yeah, as soon as I did that keyword rearrangement there I knew I would regret it :weary: It needs to be done here as well for consistency, problem is that there are many more keywords here and with all the OOP in SystemVerilog the barrier between "type" and "not type" gets fuzzier. But I'll figure it out.

Finally, a unit test should be added under tests/ctags (check the HACKING file for more details). The unit test should include some SystemVerilog code that covers all the kinds except those mapped to `tm_tag_undef_t`.

Noted! I'll see what I can make up.

@cousteaulecommandant pushed 1 commit.

10b4e937ac99acbdac03643ce4591159ef4759a6 tagmanager: Unify Verilog and SystemVerilog tags

@cousteaulecommandant pushed 4 commits.

5a31419ff0c4bbd3a6546cbf38295da2f1d87c72 Add SystemVerilog filetype 143cf1930b1b30a6ee2ad6fdd30ad02feb0b018b tagmanager: SystemVerilog: map ctags 6c1139c39eba96a0aad700cc0e85eb072fb4e36b tagmanager: Unify Verilog and SystemVerilog tags 26dc1eca5fbd522fa1d27a43605bb0a0092060ce Split SystemVerilog keywords into type / not type

@cousteaulecommandant pushed 5 commits.

0151e80e1a36c281dc0084b396114b4f65f12a0b tagmanager: SystemVerilog: map ctags 4ae35826df8aee54d40ba79733822091d2d99edd tagmanager: Unify Verilog and SystemVerilog tags 2e7563729aea50aeb0494c3af3bd70586507cac1 Split SystemVerilog keywords into type / not type 096d52dcd4505a56e004e611fb57010679a48496 Add missing SystemVerilog tasks/functions e4f7c7241306a61d569317dd9f5b748cba541536 Regenerate Verilog ctags unit tests

It has been done. Hooray! @techee: there's only one issue pending which is whether it is OK to leave the comments I put in `group_SYSVERILOG` or if I should remove those as well.

I also re-generated the ctags unit tests for Verilog and added two for SystemVerilog. While doing so, I noticed a couple of issues/bugs in ctags (I think), but those should be fixed in ctags. I left the points of failure marked in comments in the unit tests.

Other than this, the PR is ready to go.

Oddly enough, it works if I build with **meson**, but not if I build with **make** -- SystemVerilog is not recognized as a language in the latter, for some reason. The CI/CD tests are complaining for the non-Meson build, but not for the Meson ones.

Oddlier enough, if I run `make check` it works for me (even though Geany seems not to recognize the language when I open it graphically), so the mystery of why the CI/CD is failing deepens.

@techee: there's only one issue pending which is whether it is OK to leave the comments I put in group_SYSVERILOG or if I should remove those as well.

These can stay.

I also re-generated the ctags unit tests for Verilog and added two for SystemVerilog.

There's one thing I noticed - I think you should also add mappings for types that can appear as parents of other symbols. For instance, because of the missing `oop` package mapping, the symbol tree doesn't generate it in the hierarchy and the bottom part of the screenshot below shows just flat symbol list instead of a proper tree. <img width="314" alt="Screenshot 2024-11-20 at 0 18 08" src="https://github.com/user-attachments/assets/3ab6831b-fa05-4ed8-90ff-ac8008b9861c">

While doing so, I noticed a couple of issues/bugs in ctags (I think), but those should be fixed in ctags.

If you decide to update the ctags parsers, you should get it merged to ctags first and then open a PR in Geany with the change.

Apart from the symbol tree issue, the PR looks pretty good to me 👍.

There IS an oop package mapping,

Yeah, sorry, I was confused - I checked the `sysverilog.sv` test which had "package" test unchecked in the top comment so I thought it wasn't mapped.

I think I know what is going on - it doesn't work for types that are declared _after_ their members like ```verilog typedef struct packed { logic [7:0] data; logic parity; } struct_t; ```

where `struct_t` is behind `data` and `parity`. At least for C/C++ we dealt with such situations already for typedefs and I think it would work if you used `tm_tag_typedef_t` mapping but we should probably generalize it for other mappings - I'd have to check the code.

In any case, nothing for this PR which I think is ready to be merged.

Merged #4039 into master.

@cousteaulecommandant See https://github.com/geany/geany/pull/4063 - it seems to fix the symbol tree for SystemVerilog.

There's one more drawback to have function parameters mapped to anything else than `tm_tag_local_var_t` - all parameters from other functions appear in the autocompletion popup everywhere while when you use `tm_tag_local_var_t` they appear only within the function body where they were declared.

I think there's nothing urgent here that has to be fixed - I just mentioned it as I noticed it and I don't know Verilog so it's really up to you.