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

[Dmitry Gutov <dgutov@yandex.ru>]

On 02/05/2016 02:15 PM, Eli Zaretskii wrote:

>>       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.

Great!

>> 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.

I don't know how important it is, and I didn't want to bother you, but 
it would be nice to have, for completeness. (See debbugs.gnu.org/22563)

We, the Emacs community, have our share of eccentrics who won't hesitate 
to write code in an unusual way, and then be surprised anyway if some 
things don't work.

>> 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.

I'd think we could mostly rely on the fact that the general facility 
works, and you haven't made a typo in Ruby_filenames or Ruby_suffixes.

Creating a bunch of files, and complicating etags's output just for 
that, seems like an overkill.

 > 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?

If you could write unit tests for etags code, you could have some for 
the "detect language" function. Full-on integration tests, again, seem 
like an overkill to me.

 > E.g., the bug I fixed in
 > f6213ce caused Makefile's to be processed as Fortran sources...

That one could be handled by a language-agnostic regression test, I 
think. Or just test that for Makefile, but not worry about other languages.

Of course, I'm just speaking from my own experience, and could be 
discounting how error-prone and/or inconsistent C is.

>> 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.

Not sure how ripper-tags would benefit from it (they can output in etags 
format already), but you can look at 
https://github.com/universal-ctags/ctags/blob/master/docs/xcmd.rst for 
inspiration.