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 10:00:17 -0700 (PDT) Message-ID: <737e992e-d9c8-4783-8ae4-85a7ab65e2b1@default> References: <83fv1r3gzp.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445706071 14090 80.91.229.3 (24 Oct 2015 17:01:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 17:01:11 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Przemys?aw Wojnowski , adatgyujto@gmail.com, Dmitry Gutov To: Nix Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 24 19:00:56 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 1Zq2BV-000624-OL for ged-emacs-devel@m.gmane.org; Sat, 24 Oct 2015 19:00:49 +0200 Original-Received: from localhost ([::1]:45021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq2BV-0000ji-5V for ged-emacs-devel@m.gmane.org; Sat, 24 Oct 2015 13:00:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq2BQ-0000gP-UM for emacs-devel@gnu.org; Sat, 24 Oct 2015 13:00:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zq2BP-0007ls-8d for emacs-devel@gnu.org; Sat, 24 Oct 2015 13:00:44 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:34980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq2BL-0007kB-8J; Sat, 24 Oct 2015 13:00:39 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9OH0JUN030058 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Oct 2015 17:00:19 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t9OH0I11013743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Oct 2015 17:00:19 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t9OH0IH4027501; Sat, 24 Oct 2015 17:00:18 GMT In-Reply-To: <87vb9wcpw9.fsf@esperi.org.uk> 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: 141.146.126.69 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:192552 Archived-At: > > Sounds like good ol' Emacs TAGS, to me (or across-project Imenu). > > Of course, the limiting factor is TAGS files that support such > > "things". But the infrastructure is there for it. People have > > been using Emacs TAGS files to "jump to the [definition of the] > > thing at point" for 40 years. >=20 > btw, recent GNU GLOBAL has now shifted to using a SQLite database for > its tags files, which makes it hugely more extensible, in theory, and > also makes it possible that Emacs could (once the modules code lands so > we could write a glue layer to SQLite) directly extract info from it. >=20 > Raw TAGS files are more or less unsuitable for anything but C and Lisp, > and are pretty poor even for that (e.g. you can only jump from uses to > definitions, the definition can only be in one place...) I don't think this is something inherent in TAGS files. You can write a TAGS file for any kind of "definitions". And I put that in quotes because such a "definition" can really mean anything at all. A TAGS file is just an index into a document or a set of documents. The fact that a program might not exist yet for creating useful TAGS files for some language does not change this. And the same thing you say about TAGS could be said about, say, Imenu: Until/unless someone writes the code needed to use Imenu in a particular mode, it does not support that mode. That's not a problem with or limitation of Imenu. It's just a lack of interest in writing the requisite support for it for that mode/language. It's also not clear to me what you mean by "the definition can only be in one place". AFAIK, you can have multiple definitions of ("defining" locations for) the same thingy in a single TAGS file. And certainly you can have multiple such in a _set_ of TAGS files. And part of the use of TAGS files is searching across multiple TAGS files. TAGS files are composable: they can be used together. Please correct me if I'm mistaken. I'm no expert on TAGS files. (Also, it is welcome that SQLite and other indexing and querying means also be made available to Emacs. Emacs is not limited to TAGS or Imenu or ... Tomorrow you might use a SQL database with SQL/JSON indexing and querying. Who knows?)