[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ru
From: |
Eli Zaretskii |
Subject: |
Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags |
Date: |
Fri, 05 Feb 2016 13:15:45 +0200 |
> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> 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.
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/03
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/03
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/04
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/04
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags,
Eli Zaretskii <=
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Dmitry Gutov, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/06