[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:

• [x] merging parsers submitted from Geany,
• [x] 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
• [x] looking for a volunteer who rewrites SystemVerilog parser

[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.