> I need to understand how to integrate the parsing function with the rest of
> ctags
I think the only thing you have to do is to overwrite the existing regex-based
parser with the code of this parser. And then have a look at the unit tests to
see what fails.
> I'd consider at least pulling
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
@cousteaulecommandant Sorry for the late response :-(
If it's not a big problem (and it shouldn't be, you should be able to simulate
what the regex parser does), I'd suggest that you update your parser with all
features that the universal-ctags regex parser has (otherwise it won't be
accepted)
@cousteaulecommandant thanks for the analysis, couple of comments/suggestions
> Then again, it doesn't deal with comments that may be problematic in certain
> scenarios.
This is more a note to me and @techee than you, we do need to be careful of
theoretical situations and perfection, the most
> * 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 example where a regex parser might not be as capable as a parser written in
C is making tags for the properties and methods in a matlab classdef. Using
the example in https://au.mathworks.com/help/matlab/ref/classdef.html. At the
moment the ctags parser makes tags for the properties
> because it used regex and Geany didn't handle those nicely
IIUC the @techee comments on #3557 Geany can handle regex parsers by importing
the `.c` file, ie `matlab.c`.
So its all about quality and speed, thats where there are always concerns about
any regex parser.
A parser written in C
> The existing upstream [...] is currently a regex parser but a C parser can do
> things the regex one can't, and is usually faster
My bad; I completely misunderstood the other discussion then. I thought you
meant that you _didn't_ want to pull in the one from uctags (because it used
regex
> But until that happens
Well I was trying to _subtly_ hint that you should make it happen :-)
The existing upstream is from 2008 according to its copyright (didn't check
git) so it is going to take one of you matlab users to do it for it to happen,
clearly the originator is unlikely to
> So my understanding was that either that a version of the Geany C parser was
> to be upgraded to include any extra capability that the ctags regex parser
> had and was then merged upstream, or the regex based parser from upstream was
> merged into Geany. Not that changes were made solely on
> #3358 which I understand was ready to merge but has been sitting there for a
> while.
Geany does __NOT__ want to maintain parsers separate from ctags, we simply do
not have the effort available to devote to language specifics, and making
changes available upstream means more people benefit
@cousteaulecommandant pushed 5 commits.
56afcc71d19fb6ed26441b6eaf5adddc620999d1 ctags: Matlab: function name only,
without args
568806ea78e98ac2e82b288fa15d443600631294 Modify (fix) test accordingly
19feb68c28427d423015b71428962ed766fc8c57 Improve ctags tests for Matlab
12 matches
Mail list logo
