@techee commented on this pull request.
- { 2, "types_basic", FALSE },
+ { 3, "types_composite", FALSE }, + { 4, "types_domain", FALSE }, + { 5, "types_exceptions", FALSE },
If I understand it correctly, TRUE indicates the group into which dynamically obtained "keywords" from ctags are mapped. For C it's the various types like ScintillaObject or GeanyDocument, etc. which are then highlighted in the editor with the given style. I haven't seen it used by any scripting language though and there's a danger that the mapping of the given language, in our case ```C static TMParserMapEntry map_RAKU[] = { {'c', tm_tag_class_t}, // class {'g', tm_tag_struct_t}, // grammar {'m', tm_tag_method_t}, // method {'o', tm_tag_namespace_t}, // module {'p', tm_tag_package_t}, // package {'r', tm_tag_class_t}, // role {'u', tm_tag_variable_t}, // rule {'b', tm_tag_method_t}, // submethod {'s', tm_tag_function_t}, // subroutine {'t', tm_tag_variable_t}, // token }; ```
doesn't correctly match the hard-coded "typedef" types from the tag manager:
```C static TMTagType TM_GLOBAL_TYPE_MASK = tm_tag_class_t | tm_tag_enum_t | tm_tag_interface_t | tm_tag_struct_t | tm_tag_typedef_t | tm_tag_union_t | tm_tag_namespace_t; ```
(like mapping `grammar` to `struct` in the raku case - it probably is alright, I guess it's kind of type, but there isn't a guaranteed 1:1 correspondence)
Also, these types don't appear in function prototypes or variable declarations as these are dynamically-typed languages so I think it's not really that useful to have them colorized.