[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: |
Dmitry Gutov |
Subject: |
Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags |
Date: |
Thu, 4 Feb 2016 12:36:25 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
On 02/04/2016 06:48 AM, Eli Zaretskii wrote:
Anyway, the example shouldn't put attr_X calls inside a method
definition, or it gives an impression that we handle this situation
intentionally, or somehow differently from the usual case. Whereas we
could as well skip those tags altogether (but we don't really have to,
as long as we only generate non-qualified tags, and check that every
argument is a Symbol literal, i.e. it starts with a colon).
Please modify the test files as you see fit, and tell me what the tags
should be.
I've updated the example and the tags. No further action needed, thanks.
+ alias_method :qux, :tee, attr_accessor :bogus
This one is a bit weird as well:
- An alias_method call with three arguments will raise an ArgumentError.
It's there to test the algorithm, which should not tag the bogus
accessor.
Why is it bogus, though? If it were not a syntax error (because of
alias_method using a paren-less call as well, not because of preceding
comma), it would be a valid attr_accessor call.
For instance, these examples are syntactically valid and would result in
the generation of the method 'foo':
class C
puts(attr_accessor :foo)
end
class C
1 + 2; attr_reader :bar
end
We don't really need to support them, but actively fighting against them
seems odd.
I'm not sure how this simplifies things. The point was that a comma
doesn't reset the mini-state machine to the state where it is once
again ready to see attr_accessor. If you are saying there are other
situations like that, please describe them.
IOW, does etags handle the above intentionally invalid code correctly?
It should.
Point is, the example code is syntactically invalid. etags doesn't need
to handle that kind of code at all, right? It would be better to get a
syntactically-valid example, if we an find one. Not sure if we can;
these are also invalid:
1, 2, attr_accessor :bogus
puts(1, attr_accessor :bogus)
Ok, so it it doesn't simplify things, don't worry about it.
- 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 <=
- 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, 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, 2016/02/05
- Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags, Eli Zaretskii, 2016/02/06