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.

Improving clojure

Scala

Some hints are in #654.

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

lex & flex

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)

xsd

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.

java10 (var keyword)

swift

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

terraform (oracle/opengrok#3108)

thrift

https://thrift.apache.org/docs/idl
https://raw.githubusercontent.com/apache/thrift/master/test/ThriftTest.thrift

ReasonML

Kotlin, Please, Thank you

See #2769 (appended by @masatake).

Kornshell (AST available)

Pandoc (rather than simply Markdown... by using the Pandoc AST all tokens can be very simply extracted)

Which means that with one implementation you gain support for (see https://pandoc.org for full list):

• Markdown & CommonMark
• reStructuredText
• AsciiDoc
• LaTeX
• Textile
• txt2tags
• HTML
• roff man/ms
• Texinfo
• Docbook
• JATS
• TEI Simple
• docx / odt / OpenDocument XML / pptx
• various wiki formats
• ...

Pandoc could either be an external binary dependency, or a shared Haskell library.

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

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

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

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.

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

Thanks Masatake. Created as #2628.

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.

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.

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.

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.

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 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?

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.

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.