@techee commented on this pull request.
In src/highlightingmappings.h:
> + { 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
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:
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.