Thanks! I'll see what I can do.
I'll start with something that does exactly what their parser does, which shouldn't be hard since I already have the parsing done (although I need to understand how to integrate the parsing function with the rest of ctags, and whether something extra needs to be done), and then maybe add some extra functionality such as handling commented out code or an improved class parser.

Or maybe even better, open an issue there and ask there and ask first to avoid some unnecessary work.

Thanks, that's probably a good idea :)

A readline-based parser will always be a compromise - it's easy to create something functional quickly but the more and more language features you add, the more messy it will be. So if you want to create some more complex parser, you'd have to create a token-based parser.

Yeah, I don't expect to have a "real", fully featured, 100% compliant parser, which would need to be token-based and quite complex because Matlab can get quite weird, but just something that will get it right most of the time (easy to deceive on purpose if you're evil enough, but hard to break by accident).

PS: Although you've made it clear that you don't want to maintain your own ctags parser, I'd consider at least pulling #3358 since the current parser is pretty much broken (not to a "causes Geany to crash" degree, but definitely to a "hardly ever produces the right output" level) - i.e. it fixes a bug in the parser that leaves it virtually useless, not a mere feature improvement.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.