(Note that this PR is **unrelated** to **SystemVerilog;** all I added here is still plain old Verilog. I still plan to create a commit adding support for SystemVerilog, but that'll be on a different PR.)

@cousteaulecommandant Thanks. I think nobody from Geany developers uses Verilog so I guess we'll trust your choices :-).

> I have added all those "new" keywords to the word3= category to distinguish them from the "classic" keywords from the previous century, although I honestly don't know what's the difference between the two categories.

I think it would be best to put the new keywords to the "word" list among the original keywords.

The only difference is the coloring of the various lists - see the mapping to the theme colors: ``` word=keyword_1 word2=keyword_2 word3=keyword_3 ```

> Finally, I have added $ to the list of wordchars=, because Verilog is special and considers $ to be an identifier character like _ (so e.g. $finish and gotabout$350 are valid identifiers).

Note that Geany currently doesn't respect the `wordchars` characters for everything and for some things the "old" hard-coded `a-zA_Z0-9_` is still used. Should be fixed eventually.

> (Note that this PR is unrelated to SystemVerilog; all I added here is still plain old Verilog. I still plan to create a commit adding support for SystemVerilog, but that'll be on a different PR.)

Just a note - the Verilog ctags parser contains also System Verilog parser. We could enable it if you add the SystemVerilog filetype.

> As a side note, I see that words2= includes a bunch system tasks and functions ($display, $finish, etc.), but the list is not complete (see [chapter 17 of the Verilog standard](https://www.eg.bucknell.edu/~csci320/2016-fall/wp-content/uploads/2015/08/ve...) for a complete list; there are 122 in total).

> Do you think it would be a good idea to add those as well?

> Note that these are not "keywords" per se, just system functions, but I suppose it's OK to handle them as "keywords" for the purpose of highlighting. (They're highlighted in a different color from actual keywords, which is the important thing.)

Depends whether Verilog users would expect them to be highlighted or not. The other "keyword" lists are used this way for other languages too but I don't know what's the common practice for Verilog.

> (Note that this PR is unrelated to SystemVerilog; all I added here is still plain old Verilog. I still plan to create a commit adding support for SystemVerilog, but that'll be on a different PR.)

There's also this PR you might want to check https://github.com/geany/geany/pull/1831 - if it's alright, maybe that one could be merged.

I tried to figure out a pattern (are they "types"? "Stuff used to declare variables"?) and had actually started making a list of which things were "variable stuff", moving not only reg and wire but also wand, wor, tri, tri0, tri1, realtype, signed, (unsigned), etc., but eventually I realized that (1) I don't know the standard well enough to see which of these make sense to be in a separate category of keywords; (2) the whole idea of "type" is a bit fuzzy, since everything in Verilog is basically "array of bits"; the stuff in that list is more like "qualifiers" mostly; (3) I have no idea what the original idea of having a separate list of keywords was meant for, since it's not mentioned anywhere, so I can't decided what should go in there and what shouldn't; and (4) overall I see no point in having two lists of keywords (neither C nor C++ seem to have those so I can't think of an analogy). So I thought it would be easiest to just put everything in a single category of keywords.

It's really up to the contributor of filetype support. For instance, java uses ```ini primary=abstract assert break case catch class const continue default do else enum exports extends final finally for goto if implements import instanceof interface module native new non-sealed open opens package permits private protected provides public record requires return sealed static strictfp super switch synchronized this throw throws to transient transitive try uses var volatile when while with yield true false null secondary=boolean byte char double float int long short void # documentation keywords for javadoc doccomment=author deprecated exception param return see serial serialData serialField since throws todo version typedefs= ``` Those "secondary" keywords are normal keywords, just defining primitive types and are highlighted differently which kind of makes sense. But if you feel there's no such analogy in Verilog, it's probably best to have them all in one group.

Honestly I don't quite understand what wordchars does, but it felt right to add the $ there.

I have kind of the same feeling ;-). See https://github.com/geany/geany/issues/4038

Personally I think it's good to see $finish and $display etc highlighted as "this is something important", despite them not being keywords strictly speaking, so the current behavior is good. My question was whether to add the rest of functions starting with $ that are in the standard. I have no idea what most of those functions do, to be honest.

Then I'd say leave it as it is.

Those "secondary" keywords are normal keywords, just defining primitive types and are highlighted differently which kind of makes sense. But if you feel there's no such analogy in Verilog, it's probably best to have them all in one group.

There is, but it's complicated. Basically there are a few "data types" proper (think C's char, int, float), and a ton of modifiers/specifiers describing how the signal behaves "physically" (think static, const, volatile, extern, etc). But I think I can make a distinction between "keywords that are used to declare signals/variables/constants" and "keywords that are not used to declare signals/variables/constants". If that's common practice I can give it a try; I think it can be done.

Option 2 is what I have now - separate keywords in "old keywords" and "newer keywords from a newer standard that a very old file might be using for something else", but I don't think that'll be that much useful.

Option 3 is cram everything into a single category, which I think is what C does. In any case, the default theme uses the same color for both so it's hard for me to see the difference.

...

whether to add the rest of functions starting with $ that are in the standard. I have no idea what most of those functions do, to be honest.

Then I'd say leave it as it is.

On second thought, I think I'll better add those as well. There are a few I use often that aren't listed (`$clog2` and `$signed` are super common, for example), and there's a handy list of all these *"system tasks and functions that are considered part of the Verilog HDL"* in the standard so this is a no-brainer.

----

While you are at, Scintilla supports (in the meantime) even more keyword lists: https://github.com/ScintillaOrg/lexilla/blob/master/lexers/LexVerilog.cxx#L1...

Those look pretty much like what we already have though. * *Primary keywords and identifiers* -> `word=` * *Secondary keywords and identifiers* -> `word3=` * *System Tasks* -> `word2=` * *User defined tasks and identifiers* -> guess this is meant to allow users to add their own keywords (or to detect them automatically from the files?) * *Documentation comment keywords* -> I guess this is `docComment=` (although Geany doesn't seem to support special `///` or `/**` comments in Verilog like it does for C, so no `@todo`, `\param`, etc.) * *Preprocessor definitions* -> this is the only one that I'm not sure about. Not sure if this refers to macro definitions (`` `define A_MACRO 42 ``) or macros per se (`` x = `A_MACRO; ``), or "preprocessor stuff in general" (`` `whatever ``), or "specifically the macros the user has defined", or "only the standard macros".

Maybe it also helps to have a look at the SciTE configuration: https://sourceforge.net/p/scintilla/scite/ci/default/tree/src/verilog.proper...

Apparently they cram all the keywords as keywords1 and leave keywords2 blank (my "Option 3"), keywords3 is the $ stuff (`word2=`) but more complete, keywords4 is blank as well, and keywords5 is not used for "documentation comments" but for "pragma comments" (like `//synopsys translate_off`), which is a nonstandard feature used by some implementations.

For the sake of "keeping the things the way they were", I've gone with option 1, and tried my best at grouping the keywords into things that are used for declaring signals/constants, and things that are not. I think the result is good.

I have also decided to add all the standard system functions/tasks.

This is how it looks now (with `word3` highlighted in a lighter blue). Signal declarations use keywords of one type, other control structures use the other. I think it looks nice. 

I've pushed the new version to this PR (and rebased it on top of master, while I was at it).

Apart from the `wordchar` comment, this PR looks good to me.

@cousteaulecommandant pushed 1 commit.

ffc8f62b5d94625e614c53784bc1f3a7b00140d7 filetypes.verilog: add Verilog-2005 keywords

...Sorry; I didn't realize I have to RESOLVE the code reviews after I fix them. :sweat_smile:

Merged #4037 into master.