Generating ctags for C files in the include/ dir

[bruno-]

Hi,
continuing on the same idea as in vim-rake PR #25,
it would be great if C header files from ruby include dir would get a tags file.

When paired with vim's tags option this would help with looking up C macros
and structures in ruby.h and other header files. Also, ctags is faster and
more precise than vim's [i and [d (although I find all these options useful).

This PR contains a working solution although I don't feel happy about the
error message verbiage.

Anyway, if you're willing to consider merging this PR any feedback is
appreciated and I'll be responsive to make changes.

[tpope]

Error phrasing is adequate. Do we really need C++? Should be C only AFAIK.

This reminded me of a couple of rake.vim patch tweaks I forgot to mention. I just committed them myself.

[bruno-]

Hey,
that's a good question about the C++ in ctags. I think I initially automatically included it because vim's *.h filetype is cpp. After double checking this it turns out ctags treats header files as C++ type too. If C++ is omitted tags file is empty.

I just pushed an update to the PR. If ruby-build is used with -k flag all ruby source files are saved in ~/.rbenv/sources/2.x.x. In this case we run ctags on the ruby source but keep the tags file in the ruby include path. This cool new vim-rake tags feature will just work in both cases (-k flag turned on of off).

Having the tags for C/C++ files of the whole ruby project when writing or just browsing C extensions is a very neat thing.

Btw @mislav helped with making this feature elegant. My initial idea was clunky, so thanks Mislav.

A weird thing about the ctags program:

• ctags -R some/path/foo/ --languages=C,C++ ignores the --languages flag
• ctags --languages=C,C++ -R some/path/foo/ and ctags -R --languages=ruby are both fine

As always, please let me know if you have any remarks about the PR!

[mislav]

Since this method gets called only once, I would rather inline it at the place where it's needed

[tpope]

I think the thing to do here is make generate_ctags_in take an optional languages argument and call --languages="${2:-ruby}". Then move the rest of the logic inline.

[bruno-]

Hi guys,
thanks for the feedback. I've updated the PR.
I must say I was a bit anxious changing the already working code, but I've tested it a number of times on my machine and things seem to work fine.

Please let me know if you have more feedback.

[bruno-]

While I think I implemented all of Mislav's feedback, I left the script output as-is because of Tim's comment.
I personally don't have any preference about this though..

[tpope]

Output is a separate concern. If any interested parties care enough to get it silenced, I'd merge a pull request.

[tpope]

Guess I should have tested first. The output is showing . for the directory, which is worthless.

[bruno-]

Hmm.. sorry to hear things don't work well.
I tested this in a couple different scenarios: as a hook to ruby-install, and via rbenv ctags and in all cases I get absolute dir paths in the output of Running ctags...

[tpope]

Oh, looks to be a 1.8.7 thing. Having trouble understanding why. Can you reproduce?

[bruno-]

I tested with rubies 2.x.

Yes, I was able to reproduce with 1.8.7 when ruby source is *not* kept (no -k option).

• output when installing 1.8.7 with ruby source kept (this one looks ok)
• output when installing 1.8.7 *without* ruby source kept: the dot is visible

I'll keep investigating.

[bruno-]

It looks like 1.8.7 rubies don't have an include/ dir so the "$(ls -d $1/include/ruby-*)" shell expansion doesn't end well.

Sorry for the mistake, I'll take some time to investigate and open a PR with a fix (I'll also check what happens with vim-rake).

[bruno-]

If it's any consolation rubies 1.9.2, 1.9.3 and above seem to be ok: they have the include dir and rbenv-ctags output looks ok.