[RFC] Which language do you want us to support?

[masatake]

This is /dev/null (The 2nd meaning of https://en.wiktionary.org/wiki//dev/null) where requests go. We never promise to write the parser you want. I will help you if you want to write a parser only if you will provide the result under 'GPLv2 or later.' I want to merge the result to our code base.

I would like you to write the document that explains the target language specification.
Much sample input files or information for large code base may help developers.

You can use thumb-up emoji.

For summarizing purpose, I will remove your comment.

For me(@masatake), the most of the languages I will use daily C, Python, Shell, Make, Automake, Autoconf, Asm, RPMspec, and Ld-script are available, and their parsers work well though there are
many points I have to improve.

Member in the organization, feel free updating this comment.

If you find an implementation including .ctags file for a language, you can report here as I did about asn1 parser. We can import the implementation if the author agrees distributing it in GPL v2 or later.
For importing, we need volunteers who helps us write test cases.

Don't report about issue about a client tool like vim here. ctags just generates tag files. It doesn't provide tree structured UI panel (or something.) If you need a help from ctags side to improve your client tool, open an issue.

My queue:

• merging parsers submitted from Geany,
• merging @b4n's new (mostly rewritten) Cobol parser
• merging (and reworking) asn1 parser
• improving javascript parser with the newly introduced symbol table
• implementing unoidl parser or thrift parser in peg for study
• rewriting java parser after extracting the token chain feature from Cxx parser as common rontines
• looking for a volunteer who rewrites SystemVerilog parser

[masatake]

In #2105, we will merge Haskell parser developed at Geany project.

---

Haskell

Just a question those who are put "thumb-up". hasktags is not enough for you?

(The comments you put in this PR will be mesmerized by me and will be deleted to keep this PR simple.)

---

Merged the parser at Geany project. See #2712.

[masatake]

Improving clojure

[masatake]

Scala

---

Some hints are in #654.

[masatake]

Vala

I myself have no chance to read vala code but it is interesting target to research how to write a parser utiliing lex (and yacc) in ctags.

---

@masatake is working on this parser. #2677

[baruch]

please add dlang, there is an old work for that at https://github.com/snosov1/ctags-d

---

@barunch, Universal-ctags has d parser already though I don't know its quality. The patch you introduced in better than one in Universal-ctags? If the answer is yes, or there are an area we have to discuss, please open an issue. (added by @masatake)

[masatake]

xsd

[masatake]

asn1

We can import the changes in https://github.com/grogers0/ctags .
It uses setjmp/longjmp. We should not use the functions. Rewriting is needed.

2019-12-16: I got the permission to import the parser from the original author.

[masatake]

java10 (var keyword)

[qingkong1998]

swift

(Originally two langauges swift and objectivec are listed here. @mastake deleted objectivec.)
(Other client sides releated comments posted by @qingkong1998 are removed.)

[TrentSe]

Prolog would be great. I'm happy to assist (though not my area of expertise...).

[masatake]

@TrentSe,

I'm happy to assist

There is only a few chance I can get this kind of offering.
I wrote how to assist me in the initial comment of this issue.

I would like you to write the document that explains the target language specification.
Much sample input files or information for large code base may help developers.

[TrentSe]

Hey Masatake,

You're most welcome. I'd be attempting it myself without your help, so makes sense for us to team up!

I'll read up and get back to you...

Where would you like me to put the input files / language spec...?

[masatake]

You're most welcome. I'd be attempting it myself without your help, so makes sense for us to team up!
Great!

Where would you like me to put the input files / language spec...?

Please, open a new issue for developing our prolog parser.

[TrentSe]

Please, open a new issue for developing our prolog parser.

Thanks Masatake. Created as #2628.

[Shane-XB-Qian]

would you mind adding filter pattern for vim9 script?

• def and export def
• e.g export def Foo(bar: dict<any>, zzz: dict<any>): void end with enddef
• or def Foo() etc.. end with enddef

// there would may have (export) 'class' also, but for now, those two.

// And actually/also :

var foo: dict<any> = {
  # something...
}
foo->extend({
  bar: function('s:bar', [foo])
})

then foo.bar() looks for now cannot find s:bar.

[Shane-XB-Qian]

vim9 means vim9 script, is a new version of vim script, compared to legacy one.
// so perhaps it can be thought as a new language? or if (you) donot think so, it's ok then let me open a 'new issue'.

// pls ignore the naming in the example, it's not regarding to lsp, but just a example. which for now, looks not supported by ctags to parse for vim script language.
// updated my comment as well, sorry if confused.

[masatake]

How different vim9 from vim8? script?
If it is very different, someone has to write a new parser for it.
If it is not , extending the parser for vim in ctags is enough for support vim9.

[Shane-XB-Qian]

perhaps for now just need to extend the current viml parser, just treat (export)\? def ... enddef as a function as well; as for another case in my above comment, not sure if it's easy to extend it.
// just for now, maybe in the future needed a new parser for it.

[masatake]

I studied the vim9 script a bit. It seems that the language is being developed and extended now.
We may need a new parser AND a new maintainer for the parser who updates the parser for catching up with the development of the language.

[gwerbin]

I studied the vim9 script a bit. It seems that the language is being developed and extended now.
We may need a new parser AND a new maintainer for the parser who updates the parser for catching up with the development of the language.

I believe the Neovim developers have at least attempted to make a Vim9Script parser, although the language itself is a moving target. Maybe they can assist?

Moreover, there has been a lot of work recently in using Tree Sitter to generate incremental parsers. Perhaps the rate of parser development can be accelerated in general by incorporating Tree Sitter as a dependency?

[Shane-XB-Qian]

Neovim developers have at least attempted to make a Vim9Script parser

um, really? vim9 script mostly is to official vim, bram is developing the vim9; neovim was using lua, as i knew.

// i noticed @k-takata also is a 'member' of this repo, perhaps he would help you out this vim9 script parser......
// before vim9 ready/released, the earlier phase of vim9 script ctags parser should be helpful still, since some had been used vim9 script to dev something... so i proposed this.

[gwerbin]

um, really? vim9 script mostly is to official vim, bram is developing the vim9; neovim was using lua, as i knew.

Yes, although it was more of a Sunday night side project than anything: https://www.youtube.com/watch?v=ajvBcJhH1Y4. Neovim itself is still committed to Lua.

[ergunkocak]

Swift

[miki725]

was nim ever considered https://nim-lang.org/?

[masatake]

Considered. #393