The git repo of ctags now supports context and describes for ruby

[sundbp]

So I've added in those types. It doesn't yet display nicely, but I think that's more to do with the state of the ctags support as with the tagbar parsing of the output.

At least with this in there we don't get lots of error messages.

[majutsushi]

Thanks! I don't really know what ctags git repository you're talking about, though -- the official ctags repository uses subversion (on sourceforge), and the last commit to the ruby module was in 2007. So where was the change made? I'm not sure if it's a good idea to integrate stuff that relies on certain forks to work. So maybe it would make sense to wait until that change gets merged into the official code.

[sundbp]

https://github.com/fishman/ctags

That was the one I looked at.

The change would do nothing for the older version, just stops it erroring
out on the ones with support for the new tags.
On Aug 12, 2012 1:12 PM, "Jan Larres" notifications@github.com wrote:

Thanks! I don't really know what ctags git repository you're talking
about, though -- the official ctags repository uses subversion (on
sourceforge), and the last commit to the ruby module was in 2007. So where
was the change made? I'm not sure if it's a good idea to integrate stuff
that relies on certain forks to work. So maybe it would make sense to wait
until that change gets merged into the official code.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/92#issuecomment-7675058.

[majutsushi]

You're right that the change wouldn't introduce any errors with the upstream version so far, but it may if the change gets merged with different kind names, or if someone uses a different fork. That's why I'd rather not include configurations that depend on specific forks. But I will leave the pull request open and add a note on the wiki so people who are actually using this fork can look it up there.

[sundbp]

Fair enough - would a patch that adds a flag to make it ignore unknown tags
instead of erroring out be better? With default being the current behaviour.

I just want to not have errors, don't mind about the rags being handled :)
On Aug 14, 2012 6:42 AM, "Jan Larres" notifications@github.com wrote:

You're right that the change wouldn't introduce any errors with the
upstream version so far, but it may if the change gets merged with
different kind names, or if someone uses a different fork. That's why I'd
rather not include configurations that depend on specific forks. But I will
leave the pull request open and add a note on the wiki so people who are
actually using this fork can look it up there.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/92#issuecomment-7716790.

[majutsushi]

You don't need a patch. Just put the configuration I have just added to the wiki into your vimrc and everything should work.

[sundbp]

Ah, ok. Thanks!
On Aug 14, 2012 8:38 AM, "Jan Larres" notifications@github.com wrote:

You don't need a patch. Just put the configuration I have just added to
the wiki into your vimrc and everything should work.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/92#issuecomment-7718508.

[jeremyjh]

Hi - this patch is not working for me. I've used the fork of ctags to generate tags for context/describe, and I can see them in my tags file, but they do not appear in the Tagbar when I open an rspec file. Other Ruby members do work such as in a Class file. I've tried both this patch and putting the override in .vimrc and neither seems to work.

These are the entries in my tags file, can you see any reason why they would not be picked up by Tagbar?

"nagios configuration" do spec/models/service_spec.rb /^ context "nagios configuration" do$/;" C
"nagios configuration" do spec/models/services/http_service_spec.rb /^ context "nagios configuration" do$/;" C
"nagios configuration" do spec/models/services/port_service_spec.rb /^ context "nagios configuration" do$/;" C
HttpService do spec/models/services/http_service_spec.rb /^describe HttpService do$/;" d
PortService do spec/models/services/port_service_spec.rb /^describe PortService do$/;" d
Service do spec/models/service_spec.rb /^describe Service do$/;" d

[sundbp]

Nope :( the nesting isn't perfect but they did show in taskbar for me.
On Oct 8, 2012 1:01 AM, "Jeremy Huffman" notifications@github.com wrote:

Hi - this patch is not working for me. I've used the fork of ctags to
generate tags for context/describe, and I can see them in my tags file, but
they do not appear in the Tagbar when I open an rspec file. Other Ruby
members do work such as in a Class file. I've tried both this patch and
putting the override in .vimrc and neither seems to work.

These are the entries in my tags file, can you see any reason why they
would not be picked up by Tagbar?

"nagios configuration" do spec/models/service_spec.rb /^ context "nagios
configuration" do$/;" C
"nagios configuration" do spec/models/services/http_service_spec.rb /^
context "nagios configuration" do$/;" C
"nagios configuration" do spec/models/services/port_service_spec.rb /^
context "nagios configuration" do$/;" C
HttpService do spec/models/services/http_service_spec.rb /^describe
HttpService do$/;" d
PortService do spec/models/services/port_service_spec.rb /^describe
PortService do$/;" d
Service do spec/models/service_spec.rb /^describe Service do$/;" d

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/92#issuecomment-9213972.

[majutsushi]

@jeremyjh
You don't need to apply this patch, just copy the Ruby configuration from the wiki into your vimrc and it should work fine.

[jeremyjh]

@majutsushi yes as I said, I have tried it both ways and neither works.

[majutsushi]

Then there must be something wrong with the way your ctags fork is executed. Are you sure that Tagbar is calling the right executable? Check the g:tagbar_ctags_bin variable after Tagbar has been started.

[jeremyjh]

Ok, yes this was the problem. I had my locally installed ctags in path first but tagbar was looking for "ctags-exuberant". So I just needed to let g:tabgbar_ctags_bin="ctags"

Thanks!!

[NewAlexandria]

Reminder to people that ctags or tagbar (one) will not find rspec describe blocks that are not enclosed in single-quotes (e.g. no describe :function_name do entries)

[majutsushi]

That is a ctags issue. I would recommend opening a bug report on their
sourceforge tracker.

[NewAlexandria]

In the days since, I have learned that the format :name is deprecated - so the action of ctags is future-facing... If not comprehensive.

[alerque]

Hey @sundbp I'm sorry this PR never got resolved. It now has merge conflicts and will need to be updated ... if it is still relevant. I've looked over it a little bit and it is not clear to me that it is. Can you or somebody more informed on upstream ctags development let me know what the status on this is? @NewAlexandria perhaps you have some insight?

(See issue 549 if you are wondering about the late action here! Hopefully we can work through some backlog.)

[sundbp]

I've forgotten what this is about I'm afraid. I'm no longer using it personally. It is likely pragmatic to delete/close the PR.

…

On Mon, 21 Oct 2019, 14:07 Caleb Maclennan, ***@***.***> wrote: ***@***.**** requested changes on this pull request. Hey @sundbp <https://github.com/sundbp> I'm sorry this PR never got resolved. It now has merge conflicts and will need to be updated ... if it is still relevant. I've looked over it a little bit and it is not clear to me that it is. Can you or somebody more informed on upstream ctags development let me know what the status on this is? @NewAlexandria <https://github.com/NewAlexandria> perhaps you have some insight? (See issue 549 if you are wondering about the late action here! Hopefully we can work through some backlog.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#92>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPCJZSXEGUJ2AOR7ILJWLQPWSS5ANCNFSM4AAZL5YA> .

[alerque]

Thanks for the reply @sundbp, and you might be right. Since some other people were interested in this at some point I think I'll leave it open for just a little bit to solicit feedback. If I get through the contribution backlog and this is still around it will be a candidate for closing as no longer relevant. Still thanks for attempting the contribution!