* what features does the ctags regex parser have that the geany one does not (I have significant doubts about your previous description of the regex parser as "almost complete", but maybe matlab is extremely simple)

Not "almost complete"; just "way more complete".
OK, maybe that was an overstatement anyway. My point was that it had a few improvements over Geany's current one.
Specifically, it deals with the main issue I fixed in #3358, also deals with leading spaces (i.e. indented definitions) which I fixed here, and also parses classdef tags (class definitions) which I haven't implemented yet. Then again, it doesn't deal with comments that may be problematic in certain scenarios.
It also parses variables (not just structs assigned with the struct() function as Geany does), but I think that's overkill since it'll catch EVERY assignment to a variable.

Looking back, it is an extremely basic parser. But it looked more complete and correct when I first looked at it.

* what features does the geany parser have that the ctags one does not have (if any)

I didn't find an obvious one. Well, it parses structs. (Or rather, it detects when you're assigning the output of the struct() function to a variable, but that's far from the only way to create a struct.)

* how do they compare in speed (and how do they compare to the C language parser)

I really should implement a timing function to answer this; it would be quite helpful for deciding.

* how much effort is it to add features from the Geany parser to the ctags regex one

Before #3358 very easy since there's only the struct thing.
After it, still quite easy.
However, I have no idea how to add the "ignore definitions inside block comments" since that'd require a stateful parser, and the one implemented in u.ctags doesn't seem to have that. (I'd be surprised if that couldn't be done in ctags at all; it's just that I don't know how.)

* how much effort is it to add features from the ctags regex parser to the Geany one

Not much. Most of the issues were already fixed by #3358 and the commit "Ignore leading whitespace" in this PR.
The only missing feature is the classdef creation, which is a really naïve implementation anyway. I have a draft for that somewhere, but I parked the development of that when I was trying to figure out how to add classes.

functions start() and stop() are tagged as standalone functions not associated with Motor.

This is where it gets challenging. I can think of an implementation that remembers the last declared class, and shoves all functions declared afterwards into that class (there's usually a single class definition per file). But this means that once the class finishes, other functions declared outside of the class will erroneously be considered part of the class. (This is an unlikely scenario though, and I'm not even sure you can do that sort of thing in Matlab.)
Also, I'm not sure if classes can be nested. (Wow, so much for the "Matlab expert" you just recruited!)
If these two issues are a problem, then the proper way to go would be to learn where a class ends, and that implies implementing a proper parser that actually does some lexing, counting all the <keyword>...end blocks. This can be extra tricky since end can mean different things.
So I think it'll be smarter to stick to the "line-oriented parser, with something that remembers the last declared class", even if it has some corner cases.

the ctags parser makes tags for the properties CurrentSpeed and SpeedRange

This is going to be a bit trickier, specially if the user decides to define multiple properties in the same line. Even neglecting that corner case, it's something I'll have to think of. This is the section where all the class attributes are defined so it's important to get it right.

ctags cheats here, and you see it work because it thinks you're assigning to regular variables (because of the =), but it would fail e.g. with

properties
    width, height, depth
end

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