settings in filetypes.pascal: ``` [settings] tag_parser=Pascal lexer_filetype=Pascal ``` I try to improve pascal lexer with class and function name hightlighting (in LexCPP named "Global classes and typedefs"). For that geany tagger has to fill a wordlist with keys found by tagging function (see ctags/parsers/pascal.c)
In general parser seems to work sucessfully, because sidebar is updated correctly, which means function names can be seen there (`sidebar_update_tag_list works` o.k.).
On the other hand, if I attach debug code to `document.c:document_highlight_tags` function to see result of call of `symbols_find_typenames_as_string` always an empty string is returned.
Diving deeper in the code, I see whithin `symbols_find_typenames_as_string`, `typedefs->len`is always zero, which means `app->tm_workspace->global_typename_array` is not filled correctly.
additional information: * attached a pascal source file to be used to verify the problem. [test_small.zip](https://github.com/geany/geany/files/15048965/test_small.zip) * patch to see content of `typedefs` inside `symbols_find_typenames_as_string` ``` --- ./src/symbols.c +++ ./src/symbols.c.new @@ -217,6 +217,8 @@ else typedefs = app->tm_workspace->typename_array;
+printf("DEBUG: MARK_1 global: %i typedefs: (%i) typedefs->len: %i\n", global, typedefs, typedefs->len); if ((typedefs) && (typedefs->len > 0)) { const gchar *last_name = ""; ``` As already written, typedefs->len shows always zero, for the attached pas source, 2 would be correct. * attached a picture, sidebar is shown correct. 
`symbols_find_typenames_as_string()` uses `symbols_find_typenames_as_string()`, which itself uses `tm_workspace::typename_array`. This is filled *only* with what is deemed a "typename", which currently has to match `TM_GLOBAL_TYPE_MASK` (which is any of `tm_tag_class_t`, `tm_tag_enum_t`, `tm_tag_interface_t`, `tm_tag_struct_t`, `tm_tag_typedef_t`, `tm_tag_union_t` or `tm_tag_namespace_t`). This doesn't include functions you get from the parser.
The Pascal parser only recognises functions and procedures, it would need extending (upstream in uctags) to recognise type declarations before anything can happen in Geany.
And as @b4n says, only type names are passed to the lexer for highlighting.
Closed #3848 as completed.
Ok, thats the cause of current behavior. But from my point of view, it should not be so. Then at least for every file type an own TM_GLOBAL_TYPE_MASK should be definable. tm_workspace.c seems to be written for C/C++ language only.
I see also in other parts of source code to much focus on C and C-like languages. This should not be for a general IDE like geany wants to be.
Close this issue, I'll search for a solution for my needs. As a first workaround adding of `tm_tag_function_t` to TM_GLOBAL_TYPE_MASK should work.
Something else constructive: How about not to use `typedef`, but something like `tagsdef`, which holds the list of `TMParserMapGroup`s per language, which on its part holds the tags for that MapGroup-item (whatever it is defined in tm_parser.c for certain language: typedef, class, members, structs, articles, indexes, ..). Then the lexer could hold an own wordlist (and styling) for each of this MapGroup.
Another attempt could be to make external tag files available for Lexers Sytax Highlighting. Prefer loading tag-file per filetype and/or tag-file per project. Then after each save of source file an external tagger could update the tag-file, which geany could recognize to update internal key lists.
Ragards
The problem with loading all external tags into the wordlists is that the lexers only recognise syntactic elements, in this case "identifier" and not the semantics that it is a typename or a function name. Also they have no knowledge of scope and no way to pass that information to them.
The lexers will select the style of an identifier as the first list it finds the name in, so in C++ for example if the standard library `set` type was loaded from global tags then the lexers would style all `set()` functions as types. And `set(...)` is a pretty common function and they would all show as types. Because of the lack of scoping this happens even if the `set` type is not visible at the point of the `set()` function call.
If extra lists for function names were added the fact that the lexers do not have semantics or scope will mean identifiers (eg local variables) that happen to have the same name as a function in any loaded file or tags will be styled as a function name.
Similar clashes will happen in any language with separate namespaces. There is no simple solution to this issue.
github-comments@lists.geany.org