* bug#22241: 25.0.50; etags Ruby parser problems
@ 2015-12-26 3:59 Dmitry Gutov
2015-12-26 4:13 ` Dmitry Gutov
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Dmitry Gutov @ 2015-12-26 3:59 UTC (permalink / raw)
To: 22241
In GNU Emacs 25.0.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7).
It's great that we've incorporated some Ruby support, but it has some
apparent problems:
- Constants are not indexed.
- Class methods (def self.foo) are given the wrong name ("self."
shouldn't be included).
- "class << self" blocks are given a separate entry.
- Qualified tag names are never generated.
Take this example file:
module A
class B
ABC = 4
def foo!
end
def self._bar?(abc)
end
class << self
def qux=(tee)
end
end
end
end
It should have this unqualified index:
A
B
ABC
foo!
_bar?
qux=
And the qualified names should look like this:
A
A::B
A::B::ABC
A::B#foo!
A::B.bar?
A::B.qux=
Lastly, it would be great if the parser recognized some built-in
code-generating methods. Example:
def A
attr_reader :foo
attr_writer :bar
attr_accessor :tee
alias_method :qux, :tee
end
should become (the unqualified version):
A
foo
bar=
tee
tee=
qux
All attr_* methods can take a variable number of arguments. The parser
should take each argument, check that it's a symbol and not a variable
(starts with :), and if so, record the corresponding method name.
Thanks!
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2015-12-26 3:59 bug#22241: 25.0.50; etags Ruby parser problems Dmitry Gutov
@ 2015-12-26 4:13 ` Dmitry Gutov
2015-12-26 4:34 ` Dmitry Gutov
2016-01-23 16:38 ` Eli Zaretskii
2 siblings, 0 replies; 29+ messages in thread
From: Dmitry Gutov @ 2015-12-26 4:13 UTC (permalink / raw)
To: 22241
On 12/26/2015 05:59 AM, Dmitry Gutov wrote:
> And the qualified names should look like this:
>
> ...
> A::B.bar?
Sorry, this should be "A::B._bar?".
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2015-12-26 3:59 bug#22241: 25.0.50; etags Ruby parser problems Dmitry Gutov
2015-12-26 4:13 ` Dmitry Gutov
@ 2015-12-26 4:34 ` Dmitry Gutov
2016-01-23 16:38 ` Eli Zaretskii
2 siblings, 0 replies; 29+ messages in thread
From: Dmitry Gutov @ 2015-12-26 4:34 UTC (permalink / raw)
To: 22241
And looking at the existing examples:
def ModuleExample.singleton_module_method
should translate to "singleton_module_method" as unqualified name, and
"ModuleExample.singleton_module_method" as qualified name.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2015-12-26 3:59 bug#22241: 25.0.50; etags Ruby parser problems Dmitry Gutov
2015-12-26 4:13 ` Dmitry Gutov
2015-12-26 4:34 ` Dmitry Gutov
@ 2016-01-23 16:38 ` Eli Zaretskii
2016-01-23 18:23 ` Dmitry Gutov
2 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-23 16:38 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 26 Dec 2015 05:59:34 +0200
>
> It's great that we've incorporated some Ruby support, but it has some
> apparent problems:
I don't speak Ruby. So please give a more detailed spec for the
features you want added. I wrote some questions below, but I'm quite
sure there are more questions I should ask, but don't know about. So
please provide as complete specification for each feature as you
possibly can, TIA.
> - Constants are not indexed.
What is the full syntax of a "constant"? Is it just
IDENTIFIER "=" INTEGER-NUMBER
? Is whitespace significant? What about newlines?
> - Class methods (def self.foo) are given the wrong name ("self."
> shouldn't be included).
Is it enough to remove a single "self.", case-sensitive, at the
beginning of an identifier? Can there be more than one, like
"self.self.SOMETHING"? Your other example, i.e.
def ModuleExample.singleton_module_method
indicates that anything up to and including the period should be
removed, is that correct? Is there only one, or can there be many?
Should they all be removed for an unqualified name?
> - "class << self" blocks are given a separate entry.
What should be done instead? Can't a class be named "<<"?
> - Qualified tag names are never generated.
(Etags never promised qualified names except for C and derived
languages, and also in Java.)
How to know when a module's or a class's scope ends? Is it enough to
count "end" lines? Can I assume that "end" will always appear by
itself on a line? Can I disregard indentation of "end" (and of
everything else) when I determine where a scope begins and ends?
> A
> A::B
> A::B::ABC
> A::B#foo!
> A::B.bar?
> A::B.qux=
Why did 'foo!' get a '#' instead of a '.', as for '_bar'? Why doesn't
"class << self" count as a class scope, and add something to qualified
names?
> Lastly, it would be great if the parser recognized some built-in
> code-generating methods. Example:
>
> def A
> attr_reader :foo
> attr_writer :bar
> attr_accessor :tee
> alias_method :qux, :tee
> end
>
> should become (the unqualified version):
>
> A
> foo
> bar=
> tee
> tee=
> qux
>
> All attr_* methods can take a variable number of arguments. The parser
> should take each argument, check that it's a symbol and not a variable
> (starts with :), and if so, record the corresponding method name.
Why did 'bar' and 'tee' git a '=' appended? Are there any other such
"append rules"?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 16:38 ` Eli Zaretskii
@ 2016-01-23 18:23 ` Dmitry Gutov
2016-01-23 18:59 ` Eli Zaretskii
2016-01-30 10:52 ` Eli Zaretskii
0 siblings, 2 replies; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-23 18:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/23/2016 07:38 PM, Eli Zaretskii wrote:
> I don't speak Ruby. So please give a more detailed spec for the
> features you want added. I wrote some questions below, but I'm quite
> sure there are more questions I should ask, but don't know about. So
> please provide as complete specification for each feature as you
> possibly can, TIA.
There's no actual up-to-date language spec, and when in doubt, I fire up
the REPL and try things out (and forget many of the results afterwards).
So there's no "detailed spec" in my head. Let me just try my best
answering your questions, for now.
>> - Constants are not indexed.
>
> What is the full syntax of a "constant"? Is it just
>
> IDENTIFIER "=" INTEGER-NUMBER
Pretty much. IDENTIFIER should be ALL_CAPS, or CamelCase, with
underscores allowed.
INTEGER-NUMBER should be just EXPRESSION, because it can be any
expression, possibly a multiline one.
CamelCase constants usually are assigned some "anonymous class" value,
like in the following example:
SpecialError = Class.new(StandardError)
(Which is a metaprogramming-y way to define the class SpecialError).
But you probably shouldn't worry about ALL_CAPS vs CamelCase distinction
here, and just treat them the same.
> ? Is whitespace significant? What about newlines?
No spaces around "=" is fine. Spaces can also be replaced by tabs. A
newline before "=" is not allowed.
>> - Class methods (def self.foo) are given the wrong name ("self."
>> shouldn't be included).
>
> Is it enough to remove a single "self.", case-sensitive, at the
> beginning of an identifier? Can there be more than one, like
> "self.self.SOMETHING"?
One one "self." is allowed. When you remove it, you should record that
SOMETHING is a method defined on the current class (or module). In Java
terms, say, it would be like "static" method.
The upshot is, it can be called on the class itself, but not on its
instance:
irb(main):001:0> class C
irb(main):002:1> def self.foo
irb(main):003:2> 3
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> C.foo
=> 3
irb(main):007:0> C.new.foo
NoMethodError: undefined method `foo' for #<C:0x000000020141e8>
So the qualified name of that method should be "C.foo", as opposed to
"C#foo" for an instance method.
> Your other example, i.e.
>
> def ModuleExample.singleton_module_method
>
> indicates that anything up to and including the period should be
> removed, is that correct?
More or less. This is an "explicit syntax", which is equivalent to using
"self.". These two declarations are equivalent:
module ModuleExample
def ModuleExample.foo
end
end
module ModuleExample
def self.foo
end
end
> Is there only one, or can there be many?
There can be only one dot there. There could be a method resolution
operator (::) in there, I suppose, but I'm not sure if you want to add
support for that right now, or ever.
> Should they all be removed for an unqualified name?
Yes.
>> - "class << self" blocks are given a separate entry.
>
> What should be done instead? Can't a class be named "<<"?
A class cannot be named "<<". You should not add that line to the index,
but record that the method definitions inside the following scope are
defined on the current class or module. These are equivalent:
class C
def self.foo
end
end
class C
class << self
def foo
end
end
end
>> - Qualified tag names are never generated.
>
> (Etags never promised qualified names except for C and derived
> languages, and also in Java.)
OK, that would be a nice bonus, but we can live without it. ctags
doesn't define qualified names either.
Without qualified names, I suppose you should treat
def self.foo
end
and
def foo
end
and
def Class.foo
end
the same. Only record those as "foo".
> How to know when a module's or a class's scope ends? Is it enough to
> count "end" lines?
Hmm, maybe? I'm guessing etags doesn't really handle heredoc syntax, or
multiline strings defined with percent literals (examples here:
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#.22Here_document.22_notation)
The result shouldn't be too bad if you do that, anyway. Except:
> Can I assume that "end" will always appear by
> itself on a line?
Unfortunately, no. It can also be on the same line, after a semicolon
(or on any other line, I suppose, but nobody writes Ruby like that).
Examples:
class SpecialError < StandardError; end
or
class MyStruct < Struct.new(:a, :b, :c); end
(One could also stick a method definition inside that, but I haven't
seen that in practice yet). So, either:
- 'end' is on a separate line (after ^[ \t]*).
- class/module Name[< ]...; end$
'end' can also be followed by "# some comment" in both cases.
> Can I disregard indentation of "end" (and of
> everything else) when I determine where a scope begins and ends?
Probably, yes.
Indentation is not significant in Ruby, but heredocs can mess up the
detection of 'end' keywords, so we could use indentation as a way to
detect where each scope ends. But if etags doesn't normally do that,
let's not go there now.
>> A
>> A::B
>> A::B::ABC
>> A::B#foo!
>> A::B.bar?
>> A::B.qux=
>
> Why did 'foo!' get a '#' instead of a '.', as for '_bar'?
It's common to use '#' in the qualified names of instance methods, in
Java, Ruby and JS docstrings. '.' is used for class methods (static
methods, in Java), or methods defined on other singleton objects.
Examples:
http://usejsdoc.org/tags-inline-link.html (search for '#' there)
http://stackoverflow.com/questions/5915992/javadoc-writing-links-to-methods
http://docs.ruby-lang.org/en/2.1.0/RDoc/Markup.html#class-RDoc::Markup-label-Links
(the documentation also says to use ":: for class methods", but let's
not do that)
> Why doesn't
> "class << self" count as a class scope, and add something to qualified
> names?
It just served to turn 'qux=' into a class (static) method.
>> should become (the unqualified version):
>>
>> A
>> foo
>> bar=
>> tee
>> tee=
>> qux
>>
>> All attr_* methods can take a variable number of arguments. The parser
>> should take each argument, check that it's a symbol and not a variable
>> (starts with :), and if so, record the corresponding method name.
>
> Why did 'bar' and 'tee' git a '=' appended?
Because 'attr_writer :bar' effectively expands to
def bar=(val)
@bar = val
end
and 'attr_accessor :tee' expands into
def tee
@tee
end
def tee=(val)
@tee = val
end
> Are there any other such "append rules"?
There are other macros (any code can define a macro), but let's not
worry about them now.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 18:23 ` Dmitry Gutov
@ 2016-01-23 18:59 ` Eli Zaretskii
2016-01-23 19:29 ` Dmitry Gutov
2016-01-30 10:52 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-23 18:59 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 23 Jan 2016 21:23:57 +0300
>
> On 01/23/2016 07:38 PM, Eli Zaretskii wrote:
>
> > I don't speak Ruby. So please give a more detailed spec for the
> > features you want added. I wrote some questions below, but I'm quite
> > sure there are more questions I should ask, but don't know about. So
> > please provide as complete specification for each feature as you
> > possibly can, TIA.
>
> There's no actual up-to-date language spec, and when in doubt, I fire up
> the REPL and try things out (and forget many of the results afterwards).
> So there's no "detailed spec" in my head. Let me just try my best
> answering your questions, for now.
Thanks. I have a couple of follow-ups.
> >> - Constants are not indexed.
> >
> > What is the full syntax of a "constant"? Is it just
> >
> > IDENTIFIER "=" INTEGER-NUMBER
>
> Pretty much. IDENTIFIER should be ALL_CAPS, or CamelCase, with
> underscores allowed.
>
> INTEGER-NUMBER should be just EXPRESSION, because it can be any
> expression, possibly a multiline one.
So I guess I will leave constants out for now: etags has no notion of
expressions.
> >> - "class << self" blocks are given a separate entry.
> >
> > What should be done instead? Can't a class be named "<<"?
>
> A class cannot be named "<<". You should not add that line to the index,
> but record that the method definitions inside the following scope are
> defined on the current class or module.
Is the telltale part "<<" or "self" (or both)? If it's "<<", then are
there other such tokens that "invalidate" a class?
> > How to know when a module's or a class's scope ends? Is it enough to
> > count "end" lines?
>
> Hmm, maybe? I'm guessing etags doesn't really handle heredoc syntax, or
> multiline strings defined with percent literals (examples here:
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#.22Here_document.22_notation)
>
> The result shouldn't be too bad if you do that, anyway. Except:
>
> > Can I assume that "end" will always appear by
> > itself on a line?
>
> Unfortunately, no. It can also be on the same line, after a semicolon
> (or on any other line, I suppose, but nobody writes Ruby like that).
> Examples:
>
> class SpecialError < StandardError; end
>
> or
>
> class MyStruct < Struct.new(:a, :b, :c); end
Looks complicated, but I will look into this. I hope no identifier
can be named "end", as in
def foo
bar = end
end
?
> >> A
> >> A::B
> >> A::B::ABC
> >> A::B#foo!
> >> A::B.bar?
> >> A::B.qux=
> >
> > Why did 'foo!' get a '#' instead of a '.', as for '_bar'?
>
> It's common to use '#' in the qualified names of instance methods
What part of the source makes 'foo!' an instance method?
> > Why did 'bar' and 'tee' git a '=' appended?
>
> Because 'attr_writer :bar' effectively expands to
>
> def bar=(val)
> @bar = val
> end
>
> and 'attr_accessor :tee' expands into
>
> def tee
> @tee
> end
>
> def tee=(val)
> @tee = val
> end
So you are saying that attr_writer and attr_accessor cause the '=' to
be appended?
Thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 18:59 ` Eli Zaretskii
@ 2016-01-23 19:29 ` Dmitry Gutov
2016-01-23 20:48 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-23 19:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/23/2016 09:59 PM, Eli Zaretskii wrote:
> So I guess I will leave constants out for now: etags has no notion of
> expressions.
That would be a noticeable omission. Can't you just look for
^[ \t]([A-Z][a-z0-9_])[ \t]*=[ \t]*
? Then record the first group, and simply don't look at what's being
assigned. The right hand value is an expression, and you need to skip
over paired {} and do-end's, but the etags parser has to do that anyway,
right?
> Is the telltale part "<<" or "self" (or both)? If it's "<<", then are
> there other such tokens that "invalidate" a class?
It's "class << self" as a whole. Instead of self, there could be a
variable, or a class name, but let's ignore those cases for now.
If we see "class <<" - it's not a class definition. If it's followed by
"self", record the methods inside the scope as class methods. If it's
followed by something other than "self"... maybe even skip the following
scope altogether.
> Looks complicated, but I will look into this. I hope no identifier
> can be named "end", as in
>
> def foo
> bar = end
> end
>
> ?
No variable can be named 'end'. But 'end' can be a method name (so
foo.end is valid syntax). You should also be on the lookout for :end or
end:, that's an :end Symbol, not a keyword.
In practice, the 'end' keyword is almost always either preceded by ^[
\t]* or by ;[ \t]*.
>> It's common to use '#' in the qualified names of instance methods
>
> What part of the source makes 'foo!' an instance method?
An instance method is a "normal" method, i.e. a method you can call on
an "instance" of a class. Example:
class C
def foo
end
end
(That's C#foo).
c = C.new # instantiate
c.foo # call
>> Because 'attr_writer :bar' effectively expands to
>>
>> def bar=(val)
>> @bar = val
>> end
>>
>> and 'attr_accessor :tee' expands into
>>
>> def tee
>> @tee
>> end
>>
>> def tee=(val)
>> @tee = val
>> end
>
> So you are saying that attr_writer and attr_accessor cause the '=' to
> be appended?
They generate a method with the name bar=, yes.
To clarify the meaning of this: you can't have '=' in a name of a
variable, only at the end of a method name. And if you have 'bar=(val)'
defined in class C, it gets called during assignment:
class C
def bar=(val)
@bar = val
end
def foo
@bar * 3
end
end
c = C.new
c.bar = 4
c.foo # => 12
So attr_writer, attr_reader and attr_accessor generate "accessor"
methods for the instance variables in the given class.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 19:29 ` Dmitry Gutov
@ 2016-01-23 20:48 ` Eli Zaretskii
2016-01-23 21:43 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-23 20:48 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 23 Jan 2016 22:29:02 +0300
>
> On 01/23/2016 09:59 PM, Eli Zaretskii wrote:
>
> > So I guess I will leave constants out for now: etags has no notion of
> > expressions.
>
> That would be a noticeable omission. Can't you just look for
>
> ^[ \t]([A-Z][a-z0-9_])[ \t]*=[ \t]*
>
> ? Then record the first group, and simply don't look at what's being
> assigned.
That's possible, but is it good enough? Does the above regexp
necessarily mean it's a constant?
> > Is the telltale part "<<" or "self" (or both)? If it's "<<", then are
> > there other such tokens that "invalidate" a class?
>
> It's "class << self" as a whole. Instead of self, there could be a
> variable, or a class name, but let's ignore those cases for now.
>
> If we see "class <<" - it's not a class definition.
OK.
Thanks for the other info, I will work on this.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 20:48 ` Eli Zaretskii
@ 2016-01-23 21:43 ` Dmitry Gutov
2016-01-24 15:44 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-23 21:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/23/2016 11:48 PM, Eli Zaretskii wrote:
>> ^[ \t]([A-Z][a-z0-9_])[ \t]*=[ \t]*
^ I missed a * there.
>> ? Then record the first group, and simply don't look at what's being
>> assigned.
>
> That's possible, but is it good enough? Does the above regexp
> necessarily mean it's a constant?
I think so. The important point is that its name begins with a capital
letter.
And we should probably recognize assignments like these:
ModuleExample::CONSTANT = 5
The qualified name "ModuleExample::CONSTANT" if at the top level,
unqualified name is "CONSTANT". When inside classes, modules or methods,
only record the unqualified name; maybe disregard these assignments when
inside methods altogether.
Thanks in advance.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 21:43 ` Dmitry Gutov
@ 2016-01-24 15:44 ` Eli Zaretskii
2016-01-30 12:21 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-24 15:44 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 24 Jan 2016 00:43:21 +0300
>
> On 01/23/2016 11:48 PM, Eli Zaretskii wrote:
>
> >> ^[ \t]([A-Z][a-z0-9_])[ \t]*=[ \t]*
>
> ^ I missed a * there.
>
> >> ? Then record the first group, and simply don't look at what's being
> >> assigned.
> >
> > That's possible, but is it good enough? Does the above regexp
> > necessarily mean it's a constant?
>
> I think so. The important point is that its name begins with a capital
> letter.
>
> And we should probably recognize assignments like these:
>
> ModuleExample::CONSTANT = 5
>
> The qualified name "ModuleExample::CONSTANT" if at the top level,
> unqualified name is "CONSTANT". When inside classes, modules or methods,
> only record the unqualified name; maybe disregard these assignments when
> inside methods altogether.
OK, thanks. I will see what I can do with this.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-23 18:23 ` Dmitry Gutov
2016-01-23 18:59 ` Eli Zaretskii
@ 2016-01-30 10:52 ` Eli Zaretskii
2016-01-30 16:43 ` Dmitry Gutov
1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-30 10:52 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 23 Jan 2016 21:23:57 +0300
>
> >> - "class << self" blocks are given a separate entry.
> >
> > What should be done instead? Can't a class be named "<<"?
>
> A class cannot be named "<<". You should not add that line to the index,
> but record that the method definitions inside the following scope are
> defined on the current class or module. These are equivalent:
>
> class C
> def self.foo
> end
> end
>
> class C
> class << self
> def foo
> end
> end
> end
What about the following snippet: what tags, if any, should it produce
for the 'class' line?
class << a
def inspect
'"bar"'
end
end
Exuberant ctags doesn't produce anything for that line, FWIW.
Also, in the above example, what should be the class-qualified name of
'inspect'?
Thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-24 15:44 ` Eli Zaretskii
@ 2016-01-30 12:21 ` Eli Zaretskii
2016-01-30 22:06 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-30 12:21 UTC (permalink / raw)
To: dgutov; +Cc: 22241
> Date: Sun, 24 Jan 2016 17:44:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22241@debbugs.gnu.org
>
> > Cc: 22241@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Sun, 24 Jan 2016 00:43:21 +0300
> >
> > On 01/23/2016 11:48 PM, Eli Zaretskii wrote:
> >
> > >> ^[ \t]([A-Z][a-z0-9_])[ \t]*=[ \t]*
> >
> > ^ I missed a * there.
> >
> > >> ? Then record the first group, and simply don't look at what's being
> > >> assigned.
> > >
> > > That's possible, but is it good enough? Does the above regexp
> > > necessarily mean it's a constant?
> >
> > I think so. The important point is that its name begins with a capital
> > letter.
> >
> > And we should probably recognize assignments like these:
> >
> > ModuleExample::CONSTANT = 5
> >
> > The qualified name "ModuleExample::CONSTANT" if at the top level,
> > unqualified name is "CONSTANT". When inside classes, modules or methods,
> > only record the unqualified name; maybe disregard these assignments when
> > inside methods altogether.
>
> OK, thanks. I will see what I can do with this.
Please take a look at the results of commit 25b79d7 on the emacs-25
branch. I think I implemented everything except the optional name
qualification. I hope the results are good enough. If you agree,
please close the bug.
Of course, if there are still bugs, or the implementation doesn't
catch some use cases, please show them.
Thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-30 10:52 ` Eli Zaretskii
@ 2016-01-30 16:43 ` Dmitry Gutov
0 siblings, 0 replies; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-30 16:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/30/2016 01:52 PM, Eli Zaretskii wrote:
> What about the following snippet: what tags, if any, should it produce
> for the 'class' line?
>
> class << a
> def inspect
> '"bar"'
> end
> end
No tags on the class line. It's not a declaration either, it's another
way to define a method named 'inspect' on the value of 'a'. 'a' must be
a local variable.
> Also, in the above example, what should be the class-qualified name of
> 'inspect'?
Depends on the value of a. Which would be pretty hard for etags to
track, hence my earlier suggestion to skip it:
If it's followed by something other than "self"...
maybe even skip the following scope altogether.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-30 12:21 ` Eli Zaretskii
@ 2016-01-30 22:06 ` Dmitry Gutov
2016-01-31 3:37 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-30 22:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/30/2016 03:21 PM, Eli Zaretskii wrote:
> Please take a look at the results of commit 25b79d7 on the emacs-25
> branch. I think I implemented everything except the optional name
> qualification. I hope the results are good enough. If you agree,
> please close the bug.
>
> Of course, if there are still bugs, or the implementation doesn't
> catch some use cases, please show them.
Thank you.
First, it doesn't seem like it handles attr_reader, attr_writter,
attr_accessor and method_alias, like I asked at the end of the bug
report. That line of discussion was somehow dropped.
Second: a minor thing. If I remove the space after '=', 'ABC =4' doesn't
get recorded.
Third, this is tangential, but I don't think anybody uses the .ruby
extension for Ruby files (you can see it's not in auto-mode-alist). But
maybe someone somewhere will use it for something else, and etags will
erroneously parse that file as Ruby?
On the other hand, you might want to add *.ru, *.rbw, Rakefile and
Thorfile to the list of Ruby file names.
I'll be sure to let you know if I notice something else.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-30 22:06 ` Dmitry Gutov
@ 2016-01-31 3:37 ` Eli Zaretskii
2016-01-31 5:43 ` Dmitry Gutov
2016-01-31 18:01 ` Eli Zaretskii
0 siblings, 2 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-31 3:37 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 31 Jan 2016 01:06:07 +0300
>
> First, it doesn't seem like it handles attr_reader, attr_writter,
> attr_accessor and method_alias, like I asked at the end of the bug
> report. That line of discussion was somehow dropped.
Right, that part is not implemented. Perhaps later. Is it terribly
important?
> Second: a minor thing. If I remove the space after '=', 'ABC =4' doesn't
> get recorded.
Will fix.
> Third, this is tangential, but I don't think anybody uses the .ruby
> extension for Ruby files (you can see it's not in auto-mode-alist). But
> maybe someone somewhere will use it for something else, and etags will
> erroneously parse that file as Ruby?
I found that on the Internet, I can try to find that again.
> On the other hand, you might want to add *.ru, *.rbw, Rakefile and
> Thorfile to the list of Ruby file names.
That's easy to add. Should we?
> I'll be sure to let you know if I notice something else.
Thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-31 3:37 ` Eli Zaretskii
@ 2016-01-31 5:43 ` Dmitry Gutov
2016-01-31 18:11 ` Eli Zaretskii
2016-01-31 18:01 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-01-31 5:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/31/2016 06:37 AM, Eli Zaretskii wrote:
> Right, that part is not implemented. Perhaps later. Is it terribly
> important?
Exuberant Ctags doesn't do it. I suppose it's rather a missing feature
than a bug.
It's fine if it's not in 25.1, but let's keep the bug open until it's
implemented.
>> Third, this is tangential, but I don't think anybody uses the .ruby
>> extension for Ruby files (you can see it's not in auto-mode-alist). But
>> maybe someone somewhere will use it for something else, and etags will
>> erroneously parse that file as Ruby?
>
> I found that on the Internet, I can try to find that again.
Please do.
>> On the other hand, you might want to add *.ru, *.rbw, Rakefile and
>> Thorfile to the list of Ruby file names.
>
> That's easy to add. Should we?
I believe so. *.ru is a bit questionable (it's not an official Ruby
extension, and it might be used by some other file formats), but it's
used by a very popular Ruby library for web application init scripts,
and those can contain different definitions (in practice, mostly
constants, although it can have functions defined, if the application is
tiny, or somehow exotic). *.rbw is the Windows extension for Ruby
programs that don't need the cmd window. Rakefile and Thorfile can also
contain definitions (usually constants, but not necessarily just them,
in the former, and classes and methods in the latter).
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-31 3:37 ` Eli Zaretskii
2016-01-31 5:43 ` Dmitry Gutov
@ 2016-01-31 18:01 ` Eli Zaretskii
2016-02-01 8:24 ` Dmitry Gutov
1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-31 18:01 UTC (permalink / raw)
To: dgutov; +Cc: 22241
> Date: Sun, 31 Jan 2016 05:37:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22241@debbugs.gnu.org
>
> > Second: a minor thing. If I remove the space after '=', 'ABC =4' doesn't
> > get recorded.
>
> Will fix.
But that was a trap, wasn't it? What can legitimately follow the '+',
in addition to whitespace? (It's amazing, but among all the gazillion
references to Ruby, I cannot easily find a formal description of its
syntax.) According to this rare gem:
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax
(assuming I understand what it says), the RHS can be any literal, and
also any constant expression, is that right? If so, either (a) we
recognize only '^[ \t]([A-Z][a-z0-9_])*[ \t]*=' and get potential
false positives on the likes of
ABC == SOMETHING
ABC =< WHATEVER
etc. (are these possible?); or (b) you tell me which characters can
potentially follow the '=' in an assignment of a constant. My current
best guess for the latter is this:
" # % \' ( + - < ? [ {
0 1 2 3 4 5 6 7 8 9
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
And if we go the latter way, there are still multi-line expressions
that I think are way too much.
Ugh!
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-31 5:43 ` Dmitry Gutov
@ 2016-01-31 18:11 ` Eli Zaretskii
2016-02-01 8:40 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-31 18:11 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 31 Jan 2016 08:43:15 +0300
>
> On 01/31/2016 06:37 AM, Eli Zaretskii wrote:
>
> > Right, that part is not implemented. Perhaps later. Is it terribly
> > important?
>
> Exuberant Ctags doesn't do it. I suppose it's rather a missing feature
> than a bug.
>
> It's fine if it's not in 25.1, but let's keep the bug open until it's
> implemented.
Ah, so it _is_ important. But then I'd need a complete specification
of what is needed. (And I already smell a tip of an iceberg.) Again,
the references are scarce and incomplete, but I already understand
that it could be either of the following
attr_WHATEVER :foo
SOMETHING ; attr_WHATEVER :foo ; ...
attr_WHATEVER :foo, :bar; ...
Is that true? Are there any other forms, or can the symbol be
followed only by a comma, a semi-colon, or whitespece? And what ends
a line like that -- a newline, or can it be continued on the next
line?
> >> Third, this is tangential, but I don't think anybody uses the .ruby
> >> extension for Ruby files (you can see it's not in auto-mode-alist). But
> >> maybe someone somewhere will use it for something else, and etags will
> >> erroneously parse that file as Ruby?
> >
> > I found that on the Internet, I can try to find that again.
>
> Please do.
Couldn't find it. And it isn't important enough to argue, just tell
which file-name extensions to consider Ruby and I will do it.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-31 18:01 ` Eli Zaretskii
@ 2016-02-01 8:24 ` Dmitry Gutov
2016-02-02 18:13 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-01 8:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/31/2016 09:01 PM, Eli Zaretskii wrote:
> But that was a trap, wasn't it?
Almost every feature is a trap, if one considers it long enough. :)
> What can legitimately follow the '+',
> in addition to whitespace? (It's amazing, but among all the gazillion
> references to Ruby, I cannot easily find a formal description of its
> syntax.)
And there isn't one! Ruby is magical that way.
> According to this rare gem:
>
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax
>
> (assuming I understand what it says), the RHS can be any literal, and
> also any constant expression, is that right? If so, either (a) we
> recognize only '^[ \t]([A-Z][a-z0-9_])*[ \t]*=' and get potential
> false positives on the likes of
>
> ABC == SOMETHING
> ABC =< WHATEVER
=< is not a valid operator. You must be thinking of <=.
> etc. (are these possible?); or (b) you tell me which characters can
> potentially follow the '=' in an assignment of a constant.
Why not do it like this:
If 'ABC =' is followed by any character, except for '=' and '>', you
record it as a tag "ABC".
> " # % \' ( + - < ? [ {
> 0 1 2 3 4 5 6 7 8 9
> A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
>
> And if we go the latter way, there are still multi-line expressions
> that I think are way too much.
What about them? Ideally, you'd skip over multi-line expressions, but
you'd have to do that whether you record constants or not.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-01-31 18:11 ` Eli Zaretskii
@ 2016-02-01 8:40 ` Dmitry Gutov
2016-02-02 18:16 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-01 8:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 01/31/2016 09:11 PM, Eli Zaretskii wrote:
> Ah, so it _is_ important.
It kind of is. But I can open a separate bug for it, if you want.
> But then I'd need a complete specification
> of what is needed. (And I already smell a tip of an iceberg.) Again,
> the references are scarce and incomplete, but I already understand
> that it could be either of the following
>
> attr_WHATEVER :foo
> SOMETHING ; attr_WHATEVER :foo ; ...
> attr_WHATEVER :foo, :bar; ...
>
> Is that true? Are there any other forms, or can the symbol be
> followed only by a comma, a semi-colon, or whitespece?
The newline might also be preceded by a comment, I suppose.
But really, if recognizing attr_WHATEVER when it's just one of the
instructions on a line presents a noticeable difficulty, you can
disregard that case: nobody really does that in practice. Or we can
disregard it at least until somebody complains.
So you would handle
attr_WHATEVER :foo, :bar # comment
and probably
attr_WHATEVER :bar;
(the semicolon is redundant, but hey, it shouldn't be too hard to support)
and the most difficult realistic case I can imagine looks like this:
attr_WHATEVER :foo, :bar, # comment
:qux, :tee
> And what ends
> a line like that -- a newline, or can it be continued on the next
> line?
If there's a comma at the end of the current line, the argument list
continues on the next one.
> Couldn't find it. And it isn't important enough to argue, just tell
> which file-name extensions to consider Ruby and I will do it.
Let's go with my original suggestions, then:
.rb .ru .rbw Rakefile Thorfile
Thanks!
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-01 8:24 ` Dmitry Gutov
@ 2016-02-02 18:13 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-02-02 18:13 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 1 Feb 2016 11:24:38 +0300
>
> Why not do it like this:
>
> If 'ABC =' is followed by any character, except for '=' and '>', you
> record it as a tag "ABC".
If you say so. Done.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-01 8:40 ` Dmitry Gutov
@ 2016-02-02 18:16 ` Eli Zaretskii
2016-02-02 19:59 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-02-02 18:16 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 1 Feb 2016 11:40:46 +0300
>
> On 01/31/2016 09:11 PM, Eli Zaretskii wrote:
>
> > Ah, so it _is_ important.
>
> It kind of is. But I can open a separate bug for it, if you want.
>
> > But then I'd need a complete specification
> > of what is needed. (And I already smell a tip of an iceberg.) Again,
> > the references are scarce and incomplete, but I already understand
> > that it could be either of the following
> >
> > attr_WHATEVER :foo
> > SOMETHING ; attr_WHATEVER :foo ; ...
> > attr_WHATEVER :foo, :bar; ...
> >
> > Is that true? Are there any other forms, or can the symbol be
> > followed only by a comma, a semi-colon, or whitespece?
>
> The newline might also be preceded by a comment, I suppose.
>
> But really, if recognizing attr_WHATEVER when it's just one of the
> instructions on a line presents a noticeable difficulty, you can
> disregard that case: nobody really does that in practice. Or we can
> disregard it at least until somebody complains.
>
> So you would handle
>
> attr_WHATEVER :foo, :bar # comment
>
> and probably
>
> attr_WHATEVER :bar;
>
> (the semicolon is redundant, but hey, it shouldn't be too hard to support)
>
> and the most difficult realistic case I can imagine looks like this:
>
> attr_WHATEVER :foo, :bar, # comment
> :qux, :tee
OK, this is all implemented, except...
> > And what ends
> > a line like that -- a newline, or can it be continued on the next
> > line?
>
> If there's a comma at the end of the current line, the argument list
> continues on the next one.
...this. If supporting such split definitions is important, it will
need a slightly more complex code.
> Let's go with my original suggestions, then:
>
> .rb .ru .rbw Rakefile Thorfile
Also done (and doing so exposed a real bug in etags).
Please take a look.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-02 18:16 ` Eli Zaretskii
@ 2016-02-02 19:59 ` Dmitry Gutov
2016-02-03 16:26 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-02 19:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 02/02/2016 09:16 PM, Eli Zaretskii wrote:
>> So you would handle
>>
>> attr_WHATEVER :foo, :bar # comment
>>
>> and probably
>>
>> attr_WHATEVER :bar;
> OK, this is all implemented, except...
Thank you.
>> If there's a comma at the end of the current line, the argument list
>> continues on the next one.
>
> ...this. If supporting such split definitions is important, it will
> need a slightly more complex code.
It's basically a multiline function call. Not sure how frequently that
is used with attr_* in practice, but in our big project at work, just
one out of 190 attr_* declarations is multiline.
So, it happens, but in the vast majority of cases the arguments stay on
one line. Some projects (like Rails) choose to make several calls
instead, as a stylistic choice.
I can't really say yet if the lack of support for multiline calls is a
significant problem, but it is an omission.
Whether to implement it now, or close this bug and wait until another
bug report, is up to you.
>> .rb .ru .rbw Rakefile Thorfile
>
> Also done (and doing so exposed a real bug in etags).
Thanks! Looks good.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-02 19:59 ` Dmitry Gutov
@ 2016-02-03 16:26 ` Eli Zaretskii
2016-02-03 23:21 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-02-03 16:26 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 2 Feb 2016 22:59:35 +0300
>
> >> If there's a comma at the end of the current line, the argument list
> >> continues on the next one.
> >
> > ...this. If supporting such split definitions is important, it will
> > need a slightly more complex code.
>
> It's basically a multiline function call. Not sure how frequently that
> is used with attr_* in practice, but in our big project at work, just
> one out of 190 attr_* declarations is multiline.
>
> So, it happens, but in the vast majority of cases the arguments stay on
> one line. Some projects (like Rails) choose to make several calls
> instead, as a stylistic choice.
>
> I can't really say yet if the lack of support for multiline calls is a
> significant problem, but it is an omission.
>
> Whether to implement it now, or close this bug and wait until another
> bug report, is up to you.
I implemented that now.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-03 16:26 ` Eli Zaretskii
@ 2016-02-03 23:21 ` Dmitry Gutov
2016-02-04 3:43 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-03 23:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 02/03/2016 07:26 PM, Eli Zaretskii wrote:
> I implemented that now.
Thanks!
One nitpick:
attr_WHATEVER :foo, bar
will generate the methods for 'foo', and whatever the value of bar is.
But bar is not very likely to have the value :bar, so we should only
generate the tags for 'foo'.
IOW, skip the arguments that are not Ruby Symbols (don't start with a
colon). The current implementation treats them the same.
The test example looks a bit odd as well, but I'll comment on that in a
separate email.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-03 23:21 ` Dmitry Gutov
@ 2016-02-04 3:43 ` Eli Zaretskii
2016-02-04 8:24 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-02-04 3:43 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 4 Feb 2016 02:21:53 +0300
>
> One nitpick:
>
> attr_WHATEVER :foo, bar
>
> will generate the methods for 'foo', and whatever the value of bar is.
> But bar is not very likely to have the value :bar, so we should only
> generate the tags for 'foo'.
>
> IOW, skip the arguments that are not Ruby Symbols (don't start with a
> colon). The current implementation treats them the same.
Yes, because etags is not supposed to do sensible things with
syntactically incorrect programs.
I'm not sure I understand the rules, though: is the "no colon, don't
tag" rule valid for any symbol following the attr_WHATEVER, or is that
applicable only to the 2nd, 3rd, etc. symbols? IOW, what, if
anything, should be tagged here:
attr_reader foo
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-04 3:43 ` Eli Zaretskii
@ 2016-02-04 8:24 ` Dmitry Gutov
2016-02-04 17:24 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-04 8:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241
On 02/04/2016 06:43 AM, Eli Zaretskii wrote:
>> IOW, skip the arguments that are not Ruby Symbols (don't start with a
>> colon). The current implementation treats them the same.
>
> Yes, because etags is not supposed to do sensible things with
> syntactically incorrect programs.
This is syntactically correct:
class C
[:foo, :bar].each do |name|
attr_reader name
end
end
> I'm not sure I understand the rules, though: is the "no colon, don't
> tag" rule valid for any symbol following the attr_WHATEVER, or is that
> applicable only to the 2nd, 3rd, etc. symbols?
Any of the arguments.
> IOW, what, if
> anything, should be tagged here:
>
> attr_reader foo
Just skip it as well.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-04 8:24 ` Dmitry Gutov
@ 2016-02-04 17:24 ` Eli Zaretskii
2016-02-04 20:06 ` Dmitry Gutov
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-02-04 17:24 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 22241
> Cc: 22241@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 4 Feb 2016 11:24:52 +0300
>
> > I'm not sure I understand the rules, though: is the "no colon, don't
> > tag" rule valid for any symbol following the attr_WHATEVER, or is that
> > applicable only to the 2nd, 3rd, etc. symbols?
>
> Any of the arguments.
>
> > IOW, what, if
> > anything, should be tagged here:
> >
> > attr_reader foo
>
> Just skip it as well.
Done.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22241: 25.0.50; etags Ruby parser problems
2016-02-04 17:24 ` Eli Zaretskii
@ 2016-02-04 20:06 ` Dmitry Gutov
0 siblings, 0 replies; 29+ messages in thread
From: Dmitry Gutov @ 2016-02-04 20:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22241-done
On 02/04/2016 08:24 PM, Eli Zaretskii wrote:
>> Just skip it as well.
>
> Done.
Thanks a lot, marking this as done.
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2016-02-04 20:06 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-26 3:59 bug#22241: 25.0.50; etags Ruby parser problems Dmitry Gutov
2015-12-26 4:13 ` Dmitry Gutov
2015-12-26 4:34 ` Dmitry Gutov
2016-01-23 16:38 ` Eli Zaretskii
2016-01-23 18:23 ` Dmitry Gutov
2016-01-23 18:59 ` Eli Zaretskii
2016-01-23 19:29 ` Dmitry Gutov
2016-01-23 20:48 ` Eli Zaretskii
2016-01-23 21:43 ` Dmitry Gutov
2016-01-24 15:44 ` Eli Zaretskii
2016-01-30 12:21 ` Eli Zaretskii
2016-01-30 22:06 ` Dmitry Gutov
2016-01-31 3:37 ` Eli Zaretskii
2016-01-31 5:43 ` Dmitry Gutov
2016-01-31 18:11 ` Eli Zaretskii
2016-02-01 8:40 ` Dmitry Gutov
2016-02-02 18:16 ` Eli Zaretskii
2016-02-02 19:59 ` Dmitry Gutov
2016-02-03 16:26 ` Eli Zaretskii
2016-02-03 23:21 ` Dmitry Gutov
2016-02-04 3:43 ` Eli Zaretskii
2016-02-04 8:24 ` Dmitry Gutov
2016-02-04 17:24 ` Eli Zaretskii
2016-02-04 20:06 ` Dmitry Gutov
2016-01-31 18:01 ` Eli Zaretskii
2016-02-01 8:24 ` Dmitry Gutov
2016-02-02 18:13 ` Eli Zaretskii
2016-01-30 10:52 ` Eli Zaretskii
2016-01-30 16:43 ` Dmitry Gutov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.