@cousteaulecommandant Thanks for the patches, they look good to me.
Regarding the regex ctags version of the parser vs Geany's version of the parser: we could use the regex ctags version, I was just thinking that since we have the hand-written version in Geany already, it might be a base for a hand-written parser that could eventually be submitted upstream so I kept the `geany_` parser. Hand-written parsers tend to offer better flexibility in parsing and are much faster than regex parsers. But before such a parser could be submitted upstream, it would have to offer all the functionality the current regex parser offers.
Could be a nice early 2023 project, what do you think :-)
PS: Similarly, it might be good to figure out a way to also exclude occurrences of the substring "struct" that aren't the keyword struct itself, such as in strings, or as part of words, e.g.:
Probably could be done by checking if after ``` p=(const unsigned char*) strstr ((const char*) line, "struct"); ``` `p-1` and `p+6` are not alnum (plus all the necessary range checks).
PS: I have no idea how to write ctags parsers and have just been blindly modifying what geany_matlab.c did.
This is the correct and official way to write ctags parsers, welcome :-). Plus cannibalising other ctags parsers.
I notice that other tests have a much more complex .tags file which seems to include an argument list, probably for autocompletion hints.
Instead of `makeSimpleTag()` you create a function similar to the `makeTagFull()` here
https://github.com/geany/geany/blob/607fcec1fa5aff005090fbda17280976dcee68c8...
which fills in the things you want to support into the `tagEntryInfo` struct and then create the tag using `makeTagEntry()`. For the argument list it's the `e.extensionFields.signature` member. You should also call `initTagEntry()` to set the tag name and kind. The rest is optional. For readline-based parsers ctags sets the line number for you, you don't have to care about it by yourself.