Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 5 Feb 2016 13:11:50 +0300
> 
> On 02/05/2016 12:14 PM, Eli Zaretskii wrote:
> 
> > No.  What comes after the comma must begin with attr_SOMETHING or
> > alias_method.  The issue being tested here is that we are not in a
> > state where matches for these are being tried.
> 
>      alias_method :qux, :tee, attr_accessor(:bogus)
> 
> or
> 
>      alias_method :qux, :tee, alias_method(:bogus, :bogus2)
> 
> are the main options, I suppose.

These should work for my purposes.

> But they might also look misleading, and indicate that we don't
> support the paren-using syntax intentionally.
> 
> (It's another omission, but AFAICS nobody uses attr_XXX without parens 
> in the context we're interested in.)

If it's important to support that, it should be hard to add.

> > But if you ever figure out how to do that with a less abnormal syntax,
> > feel free to update the test files.
> 
> The problem with me updating the tests is I can't revert the 
> corresponding fix and make sure that the test fails without it.

You can always leave that to me.

> > It could also be a good idea to add a Rakefile or a Thorfile to the
> > ruby-src directory (when I tested the change, I just renamed one of
> > the other files).  It could be that those present special challenges,
> > and in any case we should test the file-name rules.
> 
> I believe the file-name rules should be tested in a language-agnostic 
> way, or just with one language.

I don't see how: the file names that trigger recognition as a specific
language are part of the language-specific rules.  IOW, when etags
sees a file whose basename is "Rakefile", it should process it as a
Ruby file, and how can you test it does that without actually looking
at the tags it produces for that file?  E.g., the bug I fixed in
f6213ce caused Makefile's to be processed as Fortran sources...

> We're probably better in some things, and worse in others, than "Ripper 
> Tags" [3]. I haven't tried them yet myself.

Maybe etags should acquire a feature whereby it could run external
programs to help it find the tags.  Something to think of for future
projects, perhaps.