From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-25 504696d: Etags: yet another improvement in Ruby tags Date: Fri, 5 Feb 2016 15:15:06 +0300 Message-ID: <56B4924A.2020207@yandex.ru> References: <20160203162536.2954.45438@vcs.savannah.gnu.org> <56B29165.3040404@yandex.ru> <8337t9xhjc.fsf@gnu.org> <56B31B99.6010400@yandex.ru> <83io24wfjl.fsf@gnu.org> <56B4329D.7010101@yandex.ru> <83mvrfv7s3.fsf@gnu.org> <56B47566.5090806@yandex.ru> <83d1sbv25a.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 1454674530 6375 80.91.229.3 (5 Feb 2016 12:15:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 12:15:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 05 13:15:22 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aRfIG-0001PC-Os for ged-emacs-devel@m.gmane.org; Fri, 05 Feb 2016 13:15:20 +0100 Original-Received: from localhost ([::1]:47806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRfIC-00019k-Oe for ged-emacs-devel@m.gmane.org; Fri, 05 Feb 2016 07:15:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRfI8-000176-BE for emacs-devel@gnu.org; Fri, 05 Feb 2016 07:15:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRfI5-00046f-15 for emacs-devel@gnu.org; Fri, 05 Feb 2016 07:15:12 -0500 Original-Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:36124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRfI4-00046b-Og; Fri, 05 Feb 2016 07:15:08 -0500 Original-Received: by mail-lb0-x234.google.com with SMTP id dx2so48456315lbd.3; Fri, 05 Feb 2016 04:15:08 -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=DhCtK/jO6jZ1AEKvlewj+slauFcNHMrQ/g+yXqVhZXM=; b=vb1MV7g5xX6QMOXMPIg5F9rA1BQdFd6Q4gGEGs0g5f2G52uX2WbdPkOeb1oDHffRbl tNuCw4VaD5ZVmQVMw7OvpRvy5rCxYjkMya49FuFQRd5n5CZ6N096/QNVwxel1J2iky4p pJs0JATVcLMSOKFHlaVn4e9rlbE1Vg6VIx2OB4z8wtFeesx0oJP8s/NANfkoTN/ejxmP Cn5q3q5TNqYxitZLchSWhoDfFmx1kIE02n2weYmSc14OPCCZ5z1GHetIGLtZRiCWNEbs Co8iAF6/pxPadhbjTGTT08uQUEmRA46H97TKhg/a/zNGjmK1GC0p74YN56nN644ZV+n9 7Mog== 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=DhCtK/jO6jZ1AEKvlewj+slauFcNHMrQ/g+yXqVhZXM=; b=Y9xiWXLaydC8kg0nyg/vXswb6V3jBMnArNGIiHuxJ/V5I45w424u/RqJ2PiR5ZOREk ri8TI3NFRgPRS8fkEgiQBAbZAusqTuSj73nL4/ZwuvY7p+2oYaBl2hplSRCgz76FTTay NxratOaHK094cmKPQjUm2OUEerdNnA+a2AmDTUUCLO7m5SRejuXgy7m/mXsOZY2WOpfK hFncOMyDj+Q1ah2SFIbAgrALiZ4Bx9NBdLbgnIu4YvFIJ1BSqWl/ZsTzncRfpfQlNBuX JY6lLzRn2p7HsXSgEUrj5CNaUtMs7vwAqbQ0lD/ngatf3hQgCG6iB2oJpTKavZgGV9qs jAew== X-Gm-Message-State: AG10YOTayP0Ymzt5+EzxtHo8x5ycbnp2ls5I8pSjJACF7bgjmtvkz4Yrp/LZrRvbDjmyeA== X-Received: by 10.112.172.200 with SMTP id be8mr5714624lbc.78.1454674508046; Fri, 05 Feb 2016 04:15:08 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id h198sm1454882lfb.47.2016.02.05.04.15.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 04:15:07 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <83d1sbv25a.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:199377 Archived-At: 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.