bug#22241: 25.0.50; etags Ruby parser problems

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 26 Dec 2015 05:59:34 +0200
> 
> It's great that we've incorporated some Ruby support, but it has some
> apparent problems:

I don't speak Ruby.  So please give a more detailed spec for the
features you want added.  I wrote some questions below, but I'm quite
sure there are more questions I should ask, but don't know about.  So
please provide as complete specification for each feature as you
possibly can, TIA.

> - Constants are not indexed.

What is the full syntax of a "constant"?  Is it just

  IDENTIFIER "=" INTEGER-NUMBER

?  Is whitespace significant?  What about newlines?

> - Class methods (def self.foo) are given the wrong name ("self."
>   shouldn't be included).

Is it enough to remove a single "self.", case-sensitive, at the
beginning of an identifier?  Can there be more than one, like
"self.self.SOMETHING"?  Your other example, i.e.

  def ModuleExample.singleton_module_method

indicates that anything up to and including the period should be
removed, is that correct?  Is there only one, or can there be many?
Should they all be removed for an unqualified name?

> - "class << self" blocks are given a separate entry.

What should be done instead?  Can't a class be named "<<"?

> - Qualified tag names are never generated.

(Etags never promised qualified names except for C and derived
languages, and also in Java.)

How to know when a module's or a class's scope ends?  Is it enough to
count "end" lines?  Can I assume that "end" will always appear by
itself on a line?  Can I disregard indentation of "end" (and of
everything else) when I determine where a scope begins and ends?

> A
> A::B
> A::B::ABC
> A::B#foo!
> A::B.bar?
> A::B.qux=

Why did 'foo!' get a '#' instead of a '.', as for '_bar'?  Why doesn't
"class << self" count as a class scope, and add something to qualified
names?

> Lastly, it would be great if the parser recognized some built-in
> code-generating methods. Example:
> 
> def A
>   attr_reader :foo
>   attr_writer :bar
>   attr_accessor :tee
>   alias_method :qux, :tee
> end
> 
> should become (the unqualified version):
> 
> A
> foo
> bar=
> tee
> tee=
> qux
> 
> All attr_* methods can take a variable number of arguments. The parser
> should take each argument, check that it's a symbol and not a variable
> (starts with :), and if so, record the corresponding method name.

Why did 'bar' and 'tee' git a '=' appended?  Are there any other such
"append rules"?