From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: IDE Date: Sat, 24 Oct 2015 11:43:19 -0700 (PDT) Message-ID: <62d22070-5d6e-4a00-83da-b41092ff412f@default> References: <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <87vb9wcpw9.fsf@esperi.org.uk> <83eggkwdgh.fsf@gnu.org> <87io5wcjro.fsf@esperi.org.uk> <4f369ede-790e-4ce9-b523-208bf1783924@default> <562BBC1B.4090305@yandex.ru> <3fc83de8-936b-40c4-8e0e-13724cb8bbb0@default> <562BC97F.6040805@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445712253 4740 80.91.229.3 (24 Oct 2015 18:44:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 18:44:13 +0000 (UTC) Cc: esperanto@cumego.com, adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Nix , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 24 20:44:00 2015 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 1Zq3nL-0002pp-UR for ged-emacs-devel@m.gmane.org; Sat, 24 Oct 2015 20:44:00 +0200 Original-Received: from localhost ([::1]:45319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq3nL-0007ws-Ak for ged-emacs-devel@m.gmane.org; Sat, 24 Oct 2015 14:43:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq3n7-0007wl-Jz for emacs-devel@gnu.org; Sat, 24 Oct 2015 14:43:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zq3n6-00029V-Dv for emacs-devel@gnu.org; Sat, 24 Oct 2015 14:43:45 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq3n2-00028v-JB; Sat, 24 Oct 2015 14:43:40 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9OIhMP6003545 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Oct 2015 18:43:22 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t9OIhLkU027044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Oct 2015 18:43:22 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t9OIhKRQ015034; Sat, 24 Oct 2015 18:43:21 GMT In-Reply-To: <562BC97F.6040805@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:192576 Archived-At: > > I'm not contrasting TAGS with Gnu Global. You are free to do > > that. I am not arguing in favor of TAGS over other indexing > > and querying mechanisms. >=20 > Emacs doesn't have any real abstraction over TAGS files. etags.el > basically operates on its contents. Yes, and? > > The TAGS file feature defines an index format and an index > > query mechanism. That's all. How and when the content of a > > given index gets generated or updated is a different question. >=20 > The index doesn't even say what kind of hit it is. Is it a definition? > Is it a reference? Is it both? Like, a method override. It lets you index a location in a source file, associating it with a name (symbol). That's all it does. No one is saying that TAGS is the most general indexing system, or that it is adequate for all indexing needs. It is one tool among many possible index-and-query tools. > > And that generation/updating involves parsing, which has > > been acknowledged to be the hard part. >=20 > There are several parts, of varying difficulties. >=20 > > Everything you say in support of claiming that the data > > structure "*is* a problem" is, in fact statements about > > the problem of parsing, not the data structure format. >=20 > Nothing I've said about the file format yet is concerned > with parsing. Please read what you wrote, which you've elided. The problems you mentioned were about (1) having to "re-generate the file each time you reparse the project" and (2) being "forced to parse the TAGS file and perform filtering in Elisp". I guess you could argue that #2 as a problem derives from the TAGS data structure, but nothing specific was said about what that problem is. #1 seems clearly to be about parsing the source files. > > If you want to argue that any use of *files* to hold the > > index structure is problematic then do so explicitly. >=20 > Flat files, yes. Not any kind of files, obviously. You might want to elaborate, if there is something important there. But again. No one is arguing that TAGS files are the only or the "best" indexing feature. It would be silly to do so. They, like Imenu, remain a useful feature for Emacs. And it is unfair, I think, to point to current deficiencies in support for a language as proof, by itself, that the Emacs TAGS feature is problematic for that language. There can be other ways in which it is not ideal, but current lack of someone having written support for this or that language is not, in itself, a reason. The same holds for Imenu. There are no doubt languages for which TAGS or Imenu is not sufficient. But just because a given language currently has no support for creating a TAGS file or an Imenu menu is not a sufficient reason for concluding that TAGS or Imenu is inadequate for that language. Some other, specific reasons need to be given (your mention of methods, for example).