> * 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
```matlab
properties
width, height, depth
end
```
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3563#issuecomment-1747754998
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3563/[email protected]>
