Merge support for the Vala language

[LemonBoy]

The anjuta project has its own fork of Ctags [2] and it does provide support for vala via some patches [1] that would be nice to integrate into universal-ctags.

[1] http://abderrahim.arablug.org/GSoC2008/ctags-vala.diff
[2] https://git.gnome.org/browse/anjuta/tree/plugins/symbol-db/anjuta-tags

[masatake]

Thank you for requesting.

We already have known it(https://github.com/universal-ctags/ctags/blob/master/docs/tracking.rst).

I studied more.

1. The license is explicitly shown at the top of source code(GPLv2+). Good.
2. It seems that it is written in Vala language. (A translator from vala to C is used.)
3. It seems that is has no test case.
4. It extends typeRef field.

Instead of merging the vala translator to universal ctags, I thinkit looks better to make the vala parser a standalone execuable. So universal ctags can utilize the standalone executable(valatags) as a xcmd.

Who maintains the vala parser? Anjuta project?

[craigbarnes]

Who maintains the vala parser?

It seems like they reuse the parser from libvala, which is the parser used by the Vala compiler. That's probably why the language support is written in Vala.

What is required to hook up a standalone executable to ctags? Is there some documentation for xcmd?

[masatake]

Xcmd is gone. See #1442.
So we have to write the parser for ctags from scratch.

[craigbarnes]

So we have to write the parser for ctags from scratch.

The libvala library that Anjuta uses is callable from C. Is it acceptable for ctags parsers to depend on external dynamic libraries? The Vala support could be made optional at configure-time, for anyone who wants to avoid the dependency.

[codebrainz]

Geany's c.c has decent Vala support, though I expect it'd be quite painful to bring it into here.

[masatake]

@codebrainz, thank you. I looked at c.c. There are only a few conditions/branches about Vala. So I think importing it is not so difficult, I guess.

Kind definition for vala can be taken from ctags-vala.diff and c.c of geany.
The last ciritcal issue is that there is no test case.

[codebrainz]

There are only a few conditions/branches about Vala. So I think importing it is not so difficult, I guess.

I wouldn't know, last time I looked in c.c I woke up in cold-sweats after nightmares :)

[masatake]

@codebrainz, you are correct. It is much more difficult than I expected.

[masatake]

I found a completely different approach about merging vala parser in geany.

First, remove all code about c, c++, java, ..., the parsers other than vala from c.c of geany.
Then name it vala.c.
Finally put vala.c to u-ctags.

The much part of code of vala.c and c.c of u-ctags will be duplicated.
However, I don't mind it because the code base is already difficult to maintain.

[b4n]

I've got a new-from-scratch Vala parser I started a while ago for Geany and I never properly finished (mostly because I was playing with various ideas making a parser, none too clever in the end though), but I should be able to resurrect it for u-ctags.

[masatake]

playing with various ideas making a parser

This is more interesting.
This is the area we should explore more.

[b4n]

The main idea I was playing with was an automatic token generator using regexes. However, it's kind of stupid in the sense that it still requires a hand-written parser to handle the tokens, and is (a lot) slower¹ (and less common) than e.g. flex. I didn't experiment (yet) writing a CTags parser with the help of flex (and possibly yacc/bison), but I guess it would be totally fine.

¹ I didn't perform any measurements, but I honestly don't think there is any need to know flex would be a lot faster than any dynamic matching of generic regular expressions :)

[masatake]

YES.

See lflex branch of https://github.com/masatake/ctags.git .

I was thinking about a parser for flex using flex.

What I did the first is making a glue code and finding the way to integrate flex to our build-system.

The syntax of flex (as a target language) is too complicated for initial testing though I want to have flex parser in u-ctags.

I would like to test writing a scanner with flex for simpler language.
CMakefile.txt is one of the candidate.
Could you recommend something interesting target language which is enough simple?

My interest for performance is less than you. However, I expect flex will make writing a parser simpler.

[masatake]

Currently --_mtable-regex parser is slow. However, I think I can translate to options to flex input. flex may generate an optimized scanner.