Ruby: assigning to context variable creates a broken tag

[mislav]

There should be no tag generated from this code:

context = A

However, the parser creates a tag named = A. This only happens when assigning to context variable; if the name is changed, the tag isn't defined.

$ ctags --version
Universal Ctags Development, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Jul 21 2015, 12:41:18
  Addresses: <dhiebert@users.sourceforge.net>, https://github.com/universal-ctags/ctags
  Optional compiled features: +wildcards, +regex, +debug, +option-directory, +coproc

[b4n]

A special case was added in 76dbed4 for some reason. I guess we should first find out why before just dropping it.

[mislav]

It seems like the author wanted to add RSpec syntax support. RSpec is a popular Ruby testing framework and is used with such syntax:

describe My::Class::Name, "some description" do
  context "another description" do
    ...
  end
end

Behind the scenes, RSpec defines dynamic classes named after given parameters. However, those classes are internal, exist only at runtime, and are usually never referenced from code. Therefore, I'm not sure why someone would want tags generated from those definitions.

My vote is to drop this obscure feature because it's proven to be brittle. Was it even written with tests?

[masatake]

I guess the original code want to make a tag for "another description" as a context kind.
About describe I'm not sure which part of input should be tagged.
More research is needed.

BTW, @mislav, what kind of file extension for rspec file is popular? .rb or .rspec?

[masatake]

http://www.rubydoc.info/gems/rspec-core/frames

[masatake]

I understand the things well.
I will write test cases as a initial step.

[mislav]

About describe I'm not sure which part of input should be tagged. More research is needed.

My suggestion was to drop this feature. I don't know why someone wanted to index the context & describe as tags. I don't even know how would you jump to such tag from the editor.

[masatake]

For your purpose you can put --kinds-ruby=-dC to your .ctags.

[masatake]

I'm still thinking about this issue.

• "context" and "describe" are not in exuberant ctags, so we can remove it without caring compatibility troubles.
• the original code assumes that a constant string follows "describe" or "context"; two tokens, a class and a constant string follow the keywords are not considered.
• As @mislav wrote somewhere, users may not refer "describe" and "context" tag entries for completion purpose. However, they can be still useful for navigation a file or summarizing a file purposes.

Making the ruby parser handle two tokens after the keywords is possible. However, improving xcmd features to support ripper-tags is more attractive.

I will continue to work on this issue.

[mislav]

However, they can be still useful for navigation a file or summarizing a file purposes.

I think that was it: someone had their text editor configured to provide navigation within a file based on tags generated for that file, wanted to navigate between context/describe blocks, and they thought it was a good idea to build that feature into ctags.

However since the implementation is lacking and creates false positives, you should either work on improving the implementation or dropping the feature. If you ask yourself whether you want to work on improving this feature and maintaining it in the long run with tests, and the answer is yes, then please go ahead and improve it. But as you said, it might be easier to concentrate on external parser support that would handle these complex cases, and focus on just the basic feature set for Ruby in universal-ctags.

[masatake]

You are right. Howerver, these issue gives me a chance to think about ctags and its internal deeply.
I have been a user of Emacs so I'm very new to ctags as a user. So these chances are important for me.
I'm still working on writing a test case for rspec and improving langmap option to support ripper-tags.

[masatake]

In 1.0.0 I will remove 'd' and 'c'.
'c' should be used in constant.
'd' is reserved kind letter. But its implementation will be temporary removed.

[NewAlexandria]

You are both correct with the principal use for identifying tags or other strings following context and describe blocks is for summarization of the file.

Many IDEs offer various UIs for outlining and other summarization of project files. Since test files can have more highly varied structure to the nomenclature of the blocks, I understand they are more eratic.

Summarizing test files is very useful because well-written tests describe the functional dimensions of a library in a wholistic and integrated fashion.

Relying on a standardized tag parser is preferable due, not only, the range of file/language formats – but also because of the range of meaning that comes from testing frameworks. Developing a single-purpose solution seems harder to sustain. I would prefer to argue for the support or help support it myself (if I'm able).

I welcome suggestions about better alternatives, or other avenues to pursue for the ends needed here (code summarization?) Maybe others that work that work closer to core tooling have another perspective.

[masatake]

Two tasks remains.

• Implement C, constants
• provide a consistent way to run ripper-tags as xcmd