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

[Dmitry Gutov]

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.