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#L1076

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.properties#l120

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.

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