From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#22241: 25.0.50; etags Ruby parser problems Date: Sat, 23 Jan 2016 22:29:02 +0300 Message-ID: <56A3D47E.3030802@yandex.ru> References: <86r3i9hnbt.fsf@yandex.ru> <83si1o45g1.fsf@gnu.org> <56A3C53D.1050408@yandex.ru> <83oacc3yx7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453577430 7584 80.91.229.3 (23 Jan 2016 19:30:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Jan 2016 19:30:30 +0000 (UTC) Cc: 22241@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 23 20:30:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aN3sz-0006kR-IG for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jan 2016 20:30:13 +0100 Original-Received: from localhost ([::1]:58339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN3sv-00041U-QU for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jan 2016 14:30:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN3ss-00040N-5p for bug-gnu-emacs@gnu.org; Sat, 23 Jan 2016 14:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN3sp-00076a-0V for bug-gnu-emacs@gnu.org; Sat, 23 Jan 2016 14:30:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN3so-00076C-St for bug-gnu-emacs@gnu.org; Sat, 23 Jan 2016 14:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aN3so-00050Q-IZ for bug-gnu-emacs@gnu.org; Sat, 23 Jan 2016 14:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Jan 2016 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22241 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22241-submit@debbugs.gnu.org id=B22241.145357735219152 (code B ref 22241); Sat, 23 Jan 2016 19:30:02 +0000 Original-Received: (at 22241) by debbugs.gnu.org; 23 Jan 2016 19:29:12 +0000 Original-Received: from localhost ([127.0.0.1]:60801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aN3rz-0004yq-S4 for submit@debbugs.gnu.org; Sat, 23 Jan 2016 14:29:12 -0500 Original-Received: from mail-lf0-f52.google.com ([209.85.215.52]:35014) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aN3ry-0004ye-MO for 22241@debbugs.gnu.org; Sat, 23 Jan 2016 14:29:11 -0500 Original-Received: by mail-lf0-f52.google.com with SMTP id c192so64640169lfe.2 for <22241@debbugs.gnu.org>; Sat, 23 Jan 2016 11:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=OEE6DjcchmPKRWd1RshvfMFX8XiVGUIQiH9c+R+2LCw=; b=oszN4LdrhHYtgwkQXO0yaSr9qacdqjq9HQNYpU4mfurjGItjNM1uxGABy5Ev/1R4yk hc6dqKnu/mFQT2f4gmnOaPx0bGxONeZcAeNv2GxfHEVyDpq+5/scPYL0afWQ6R48lg1X rcrOfgt2RK668En60gNiOaN1VHmr1V5p/Sj6nu0pp1gaLpkHKHI/5jBSa/mw8bl4we8f Z8RDttCK2fW2FPjstMtBP+3WG2GWe+FK3l2vRJs6MRxQ2KlZ4WZYew6/9qZCVSwU5Es6 TXgo+d5Kx0bFeYrcZVvE3cd6QcuzbS5qOb4qTP5qVwGkdx9zrFRziMsJJ1DBXQHb4RmL kfww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=OEE6DjcchmPKRWd1RshvfMFX8XiVGUIQiH9c+R+2LCw=; b=gpU9le9hmWBYmEf6xhnQQn9eho1IQG9bGiUPMA/cJleUWdyYxcUqbjURJdbL9Yg8fQ Fx7CKJIm8e4lE49eIE81ywaLhuFkL8HnP7Gmf7hPauEW7w3DP7d3os8FJJQ6hCxhI7ED fvi+rWu8YeS5xsZY38Rw+/h/KYyHQySMkFKaJwKhGZu4XhsiIC9H8gLt8WXOOBgxQ87s C96bVpvQJ/VDleSfTz5T7jXhKZYiPm95JAHRhWcN0MkXVkkqk89Nyigusi/luAYsAJyf wzMKNnc/5sUCvOJbOiaN/GkWnNM2qz9zP2KiFlqduMATnl9UywIkhIyVWQliFf//rT4J qpDw== X-Gm-Message-State: AG10YOQN/dDseDrmBGGaD7vA/nKhuszYPRl2h7xkRDdHXWKhQ2Ml5ciq3IteOXnGugrJOQ== X-Received: by 10.25.78.66 with SMTP id c63mr2992146lfb.18.1453577344824; Sat, 23 Jan 2016 11:29:04 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id r202sm1619055lfr.43.2016.01.23.11.29.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jan 2016 11:29:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <83oacc3yx7.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111897 Archived-At: 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.