@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.Message ID: <geany/geany/pull/3169/review/1944302606@github.com>