The only difference is the coloring of the various lists - see the mapping to the theme colors:

Honestly this is why I was confused. In the default theme, both word and word3 are bold navy blue and therefore indistinguishable - in fact I didn't know Geany treated them differently for Verilog until I saw it in filetypes.verilog - whereas word2 is dark red. It makes sense because this way navy blue = keywords but dark red = "standard functions". But it doesn't make sense that some keywords are considered one type and others are another type; I couldn't figure out which criteria was used to make keywords "word" or "word3" (the latter seem to be "stuff for net/variable declaration", but then again so are many of the keywords declared in "word").

I have also moved all the keywords that used to be in word3= to word=

Some of them appear to be builtin types so maybe it makes sense to keep them in word3 - other languages do something like that too. Not sure about reg wire input output inout though.

All of them are "keywords", according to the standard (Annex B).
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.

The only thing about "different" keywords I could find was in section 19.11 of the standard, which states that you can actually "disable" all of the new keywords added in Verilog 2001 and 2005, so if your design is super old and uses variable names that have later become reserved keywords, you can disable those so that you can use them as regular identifiers.
In this scenario, it might be useful to highlight these in a different color, since they're "keywords that can be forced to stop being keywords".
And that's why I thought it might be a good idea to put them in the (now empty) word3= category.

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.

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

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.

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.

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

That's the plan, yes. The Verilog lexer also seems to support SystemVerilog, so I've got the two hardest parts covered. I already have a commit that adds the language, and a PR almost ready.

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 #1831 - if it's alright, maybe that one could be merged.

That one only adds keywords though; proper handling of SystemVerilog may require a bit more. (And the parser and the lexer are already made so why not?)

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.