Context
Looking for a way to use Vim TagBar I had two options:
tags fileThe second one was more appropriated primarily because I found issue #577 that was discussing this subject.
@asterite contributed with an initial script to generate tags using crystal compiler, and that was a fantastic starting point for me, because:
To work with TagBar, I had to add support for writing on STDOUT instead of a file, pass some options and the prototype can be seen on this gist
Proposal
Add a tool, like tags on crystal; the usage would be something like I did on the prototype:
Usage: crystal tags -o [FILE] [DIR]
DIR - directory will be read to generate ctags,
default: NAME, eg: ./custom/path/example
There's long road to add full support to ctags on this prototype, like:
But I do believe that this prototype can be a kickstart for the tool.
You can check a screenshot of my TagBar while viewing the gist script.

If make sense to go this way, I can send a PR adding the tool and more improvements.
Suggestions?
I'm not sure if we should ship this with the compiler or if it wouldn't be better off as its own shard. My main issue is that of maintenance, as I'm not aware of any current core contributor using it in their development setup. The approach taken instead seems to more on tools like crystal tool implementation, which can provide context beyond identifying objects by name and listing all matching.
@jhass thanks for your reply.
I understand your concern about maintenance, the idea of use compiler is exactly lower the maintenance cost, because the structure of the language: methods, classes, won't change frequently.
About the suggestion of a tool called ctags is more because of the desired output.
I use ctags on a daily basis (because my use of vim), I can help on this, particularly because changes will infrequently be.
Yes AFAIK ctags is unable to cover all the cases that the crystal tool implementation does. It could be useful, but none of us is using ctags.
For sure anyone can create an independent crystal app that will use the compiler itself to fetch all the required information.
I've seen too much technical debt causing confusion among users, especially in stuff that needs to rarely change and isn't used by active contributors, yet being shipped with the official main project. That made me rather conservative about "just adding" stuff. If you do commit to maintain it, I see no real difference in doing it in a separate shard compared to the compiler. Keeping it external is just much better suited to declare and communicate where the maintainership burden lies.
you are right about tech debt x maintenance @jhass
as @bcardiff told can require the compiler and use it, I haven't considered this option. I'm gonna create as a separate shard.
Closing this as does not make sense to merge into the language repo
thank you for your attention 馃檱
Thank you for your suggestion!
@bcardiff what is the best approach for creating a shard that uses the compiler? add crystal source as a git submodule and require the files? (once it doesn't have a shard.yml file)
We do ship the compiler as part of the standard library, you can just require into it.
@jhass I was trying to require "compiler", found this sample thank you again 馃槃 馃憤
@fernandes you might find https://github.com/bcardiff/crystal-tool-demo useful also.
Notice that it was done before some code refactor and depending on how you want to consume the compiler you might be able to require only some aspects.