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 operating character by character can always be made better and faster than a regex one, and it can always be made more complete than the regex one, and it can handle languages that the regex one can't (eg C and C++), but of course its harder to write and maintain.

So the default preference is to not pull a regex parser unless there is nothing else available. But if the choice is a regex parser or nothing Geany will take the regex parser unless there are major issues with it. So for example on #3557 it was accepted that the regex based forth parser would be ok since it was as fast as the C language parser and no other forth parser was available.

But the "problem" for the new matlab expert guy (you ;-) is that there is an alternative parser for matlab, the existing Geany parser. But it has a different set of capabilities than the ctags regex one (and a bug which you are trying to address). So my questions to you, the newly minted matlab parser expert :-) are:

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)
what features does the geany parser have that the ctags one does not have (if any)
how do they compare in speed (and how do they compare to the C language parser)
how much effort is it to add features from the Geany parser to the ctags regex one
how much effort is it to add features from the ctags regex parser to the Geany one

The answers to those questions are what should guide the best approach.

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