Add test file

[janEbert]

Correspondingly, add the generated "tags" file to .gitignore. I tried to add "actual code" and have too many tests rather than only complex ones. Surely, some cases are not covered. For example, using multiple macros for a definition.

[oxinabox]

Do you think we can construct some actual tests that run on CI? They would need to be written in Bash, I guess. Or in Julia using run(`ctag ...`) which could be fine

[janEbert]

Sure, I'd love to look into that! Though I have never set up CI. The tests would fail though as with the simple regexes, edge cases are simply not covered:

#=
const old_zero = 0
=#

... would be parsed as an identifier.

That is also why I think a proper parser would be more useful. I have thought about writing one for Universal Ctags that would be more sophisticated than the current one but it would take some time. Guess the tests failing would be the exact thing we want until then. :)

[oxinabox]

I think easiest would be to setup CI for julia and write the tests in julia, after doing readlines on the genated file.

Then you could do @test_broken for the edge cases that fail.

You can copy the .travisci from any julia project to do that.

[oxinabox]

If you write the tests, so you can run them locally I will make it work with Travis CI

[janEbert]

How would you go about using the external Universal Ctags? They don't have release tags and the binary name may be hard to find due to name overlaps with Exuberant Ctags or Etags.

Or should I just write, try and see using ctags as the executable?

If you write the tests, I will make it work with Travis CI

Thanks, but I'd actually be glad to learn by doing!

[oxinabox]

Can't we just use Exuberant Ctags ? Or are we using new features? (if so that needs to go in the readme)

[janEbert]

You are absolutely right and I see why naming is no problem. We do not use new features, everything is still vanilla. :)

I added the tests and Travis CI, hope you are content with the code. I tried to make local testing easy as well by trying different binaries.

Broken features are marked depending on the identifier name or the "kind" (function, variable, struct, ...).

The tests will fail now because I based them on the updated ctags file (#4).

[janEbert]

Hey, the build keeps being stuck on "Resolving package versions..." when testing. I couldn't find any other reports via searching and have checked out other Project.tomls and runtest.jls, however, nothing seems different. Do you have an idea what could be wrong?

[oxinabox]

Do your tests work fine locally?

[janEbert]

Yes, I tested just now with:

$ JULIA_LOAD_PATH=$PWD julia
julia> ]
(julia-ctags) pkg> test

And it worked fine. Though as I mentioned, if the tests ran in Travis, they would fail because I based them on the new ctags file in #4.

Edit: I also just tested using the same command Travis uses (plus the --project flag) and it did not hang up.

[janEbert]

Sorry to spam; after trying a lot, I still haven't figured out how to remove those duplicate commits from master. I will fix it later, though.

[karlwessel]

Hey, the build keeps being stuck on "Resolving package versions..." when testing. I couldn't find any other reports via searching and have checked out other Project.tomls and runtest.jls, however, nothing seems different. Do you have an idea what could be wrong?

I tried your PR at my own machine and it gets stuck in an endless loop because none of the predefined ctags executables worked. The same probably happens to Travis.

You probably should make sure that trygeneratetags and the tests exit gracefully if no ctags executable is found and maybe add ctags to the list of ctags executables in ctagsbins.

[m-wells]

I'm not sure how much packaging you want to do with this but you could always provide a ctags build if one wasn't found either with BinaryProvider.jl or with the Anaconda Ctags package using Conda.jl.

If you go this route you would probably want to make this into a proper julia package.

[oxinabox]

If you go this route you would probably want to make this into a proper julia package.

That wouldn't really make sense. This file needs to go into your ctags config

[m-wells]

If you go this route you would probably want to make this into a proper julia package.

That wouldn't really make sense. This file needs to go into your ctags config

Not really. It can be passed in as an option to the ctags command via --options=pathname

[oxinabox]

When you do Pkg.add or even use Artifacts stuff the files endup in an arbitrary location. Not somewhere you can reliably find them.

[m-wells]

@oxinabox I created a pull request #6 to package julia-ctags into JuliaCtags (to stick with the Julia package naming conventions). It isn't much but it provides a method to copy the ctags config file into the current directory (naming the new file julia_ctags by default). If a ctags install was shipped with this package (see my comment in the pull request) other methods could be implemented that allow users to generate tags files using the package.

In addition, optionally providing a ctags install also means testing this package becomes much easier on Travis (or any other CI platform).

[janEbert]

Hey Karl, thank you so much for finding that. I actually hadn't forgotten this PR but due to the CI failing and me being so ashamed of the test code (it doesn't seem "right" at all), I never cared finishing it... Sorry! :sweat_smile:

I will fix it later so #6 can be merged as well. By the way, I also wrote an Etags file for use with the Emacs-internal tags engine. Do you want it in the repo as well?

[janEbert]

Sorry it took so long. I also remembered why I didn't add the ctags executable in the first place. It was to avoid incompatibilities in case etags, often mapped to ctags, was found. Of course, due to the possibility of simply ordering the binaries, that didn't make sense. Also, that while-loop was pretty embarrassing, oh man... Good it's gone now. :)