Added new parser for Inko

[yorickpeterse]

This adds a new ctags parser that can parse Inko
(https://inko-lang.org/) source code.

I based this on the commit that added the systemtap parser (6bc1a8a#diff-3dd5375cb7338d3815ab63cd09ddff93), as the documentation about adding a parser (http://docs.ctags.io/en/latest/optlib.html?highlight=optlib#submitting-an-optlib-file-to-the-universal-ctags-project) appears to be a bit out of date (e.g. the PRELOAD variables appear to not be used).

[yorickpeterse]

@masatake What do you think of these changes? Should I take a different approach for adding the parser, or is this how they are supposed to be added?

[masatake]

Please, add following two items to the header of inko.ctags:
(1) Copyright notice, and
(2) the reference to the language (https://inko-lang.org ?)

[yorickpeterse]

@masatake Oops! I initially had the copyright in place, but must have accidentally removed it before committing my changes. I added it, along with a summary plus link similar to the systemtap parser.

[masatake]

If you add a new parser specific field, you must update the expected output of some test cases.

[masatake]

https://docs.ctags.io is not updated. See #2093 .
So read rst files under docs/ directory directly.

[masatake]

Other than some minor issues, it looks good for me.

[coveralls]

Coverage increased (+0.02%) to 85.503% when pulling ccdaccd on YorickPeterse:master into 91c73c5 on universal-ctags:master.

[yorickpeterse]

@masatake

https://docs.ctags.io is not updated. See #2093 .
So read rst files under docs/ directory directly.

What exactly needs to be updated? I didn't see any references there for systemtap, so I'm not sure what to use as a reference.

[masatake]

https://docs.ctags.io is not updated. See #2093 .
So read rst files under docs/ directory directly.

What exactly needs to be updated? I didn't see any references there for systemtap, so I'm not sure what to use as a reference.

Sorry, no update is needed. It is just information.

[masatake]

impl Bar for Socket {
  def moo !! Integer {}
}

I'm thiking about what should be tagged in above code.
I remember #1604 and #1604.

[masatake]

Can a real Inko processor accept your test cases as valid inputs?
See http://docs.ctags.io/en/latest/input-validation.html?highlight=input%20validation

Don't you want full qualified tag?
http://docs.ctags.io/en/latest/optlib.html#generating-fully-qualified-tags-automatically-from-scope-information

Running ctags with --verbose option, you can see statistics about which regex patterns in tables are matched (and not matched) frequently. You can use it for optimization.
#1912

You can work on the above items after merging :-)

[yorickpeterse]

I'm thiking about what should be tagged in above code.
I remember #1604 and #1604.

A trait can only be implemented once for an object, so I don't think this would be necessary.

Can a real Inko processor accept your test cases as valid inputs?
See http://docs.ctags.io/en/latest/input-validation.html?highlight=input%20validation

Inko does not provide a way of just syntax checking a file at the moment, but all existing input examples are valid syntax.

Don't you want full qualified tag?

I personally haven't really had a use for it so far, and only optlib/puppetManifest.ctags seems to be using it.

Running ctags with --verbose option, you can see statistics about which regex patterns in tables are matched (and not matched) frequently. You can use it for optimization.

I tested it with a file that contains 24815 lines. This file takes about 1.2 seconds to process, which seems pretty reasonable to me given the size.

[masatake]

I tested it with a file that contains 24815 lines. This file takes about 1.2 seconds to process, which seems pretty reasonable to me given the size.
Merge state

Is the software having 24815 available as an open source software?
If yes, I would like to add to https://github.com/universal-ctags/codebase.

[masatake]

(I started writing this comment to make a question to you. However, during writing I got an answer by myself. The answer I got is important for improving Rust parser. So I put what I wrote here as notes for myself. )

[yamato@slave]~% cat /tmp/foo.rs 
impl SomeTrait for SomeObject {
     fn bar(&self) {
     }
}
[yamato@slave]~% cat /tmp/foo.inko
impl SomeTrait for SomeObject {
  def bar {}
}
[yamato@slave]~% u-ctags --sort=no --fields='*'-lnr -o - /tmp/foo.rs 
SomeObject	/tmp/foo.rs	/^impl SomeTrait for SomeObject {$/;"	kind:implementation
bar	/tmp/foo.rs	/^     fn bar(&self) {$/;"	kind:method	scope:implementation:SomeObject	signature:(&self)
[yamato@slave]~% u-ctags --sort=no --fields='*'-lnr -o - /tmp/foo.inko
SomeObject	/tmp/foo.inko	/^impl SomeTrait for SomeObject {$/;"	kind:reopen	end:3	implements:SomeTrait
bar	/tmp/foo.inko	/^  def bar {}$/;"	kind:method	scope:reopen:SomeObject	end:2

I'm comapring Inko and Rust. Consistency between languages are not the most important things in ctags.
However, making them consistent is better.

If we introduce "implements" field to Inko, I would like to use it in Rust. It looks for me that the two languages have similar grammars.

A. SomeObject implements SomeTrait.
B. SomeTrait implements SomeObject.

Which sentence is correct?
The answer is A. So the field name should be "implements:".

[masatake]

Thank you.

[yorickpeterse]

@masatake

Is the software having 24815 available as an open source software?
If yes, I would like to add to https://github.com/universal-ctags/codebase.

It's just the same content repeated over and over and over again, not actual software you'd find anywhere. It's as follows: big.inko.txt

Thanks for merging!

[masatake]

It's just the same content repeated over and over and over again, not actual software you'd find anywhere. It's as follows: big.inko.txt

I see.