> 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 or view it on GitHub: https://github.com/geany/geany/pull/4037#issuecomment-2474779969 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/pull/4037/[email protected]>
