From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Fri, 16 Oct 2015 22:39:17 -0400 Message-ID: <5621B4D5.9040607@gmail.com> References: <5610207A.2000300@harpegolden.net> <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> <56194171.1080006@siege-engine.com> <5619E7C7.5000401@yandex.ru> <561A9E6D.8080403@gmail.com> <561BCF54.7060000@yandex.ru> <561D85DE.4090304@gmail.com> <561F1A75.1000909@yandex.ru> <561FA2A3.9030409@gmail.com> <5620F60A.1030104@yandex.ru> 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 1445049592 28670 80.91.229.3 (17 Oct 2015 02:39:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 02:39:52 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 04:39:47 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 1ZnHPN-0005tc-7b for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 04:39:45 +0200 Original-Received: from localhost ([::1]:56710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHPM-00036F-9y for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 22:39:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHP1-00035K-JM for emacs-devel@gnu.org; Fri, 16 Oct 2015 22:39:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnHOx-0003Q0-IE for emacs-devel@gnu.org; Fri, 16 Oct 2015 22:39:23 -0400 Original-Received: from mail-qk0-x22d.google.com ([2607:f8b0:400d:c09::22d]:34820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHOx-0003PT-D1; Fri, 16 Oct 2015 22:39:19 -0400 Original-Received: by qkbl190 with SMTP id l190so525653qkb.2; Fri, 16 Oct 2015 19:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=O5aOyp7J52hz20HiR5V4RYthCHhIiilgkYW1VHQw8CI=; b=dP6Z+pGCd4ITVhGMvQvGKznCIUtbrlrsMy8qKrGec2WSsF6EhVLfKjiOZa0ohvtOm9 RORpQ+8lpPvecT7NXj4KyHyNxohAObcIfSEQQYXjL2LOOvoIyL1ktZPBsMz1QnJtGQzB SbSb4OcL8x9858BFvW+3tN0A24uIrVChGc8jHLscIymAB5i5yERmN5KQxgpEjQAbWcwI wFmUmIf0t14/n24WTQMLWfzYS6gUMJp/OUpS1JWt1PvSJhhaS2GEvKTkPkDsPanh1edI QjidcQWevvtno+bT44K/tg5ElAw5APZ0gYdvBFpuKdFw/agxdOAwnkEvqpdOxIlwNcGy GtlQ== X-Received: by 10.55.197.28 with SMTP id p28mr22823889qki.80.1445049559025; Fri, 16 Oct 2015 19:39:19 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id z10sm9067407qhd.15.2015.10.16.19.39.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 19:39:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5620F60A.1030104@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::22d 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:191805 Archived-At: On 10/16/2015 09:05 AM, Dmitry Gutov wrote: > On 10/15/2015 03:57 PM, Eric Ludlam wrote: > >> CEDET will store tags into a set of overlays in the buffer. That means >> figuring out what tag the cursor is in is as fast as asking for what >> overlay the cursor is in. > > I see. But you have to keep that info up-to-date as well, and that > becomes less fast, because you implement it in Elisp. If we're > comparing to an external program. > The magic of overlays is that the overlays keep the bounds of the tag up to date for you. Once you stop editing, and incremental parser fixes up any weird things you might have done, such as hacking a tag in half, adding new tags, etc. Because it is incremental, is typically instantaneous. >> Imenu stores it's tags in a list, so you need to scan the list to figure >> it out. Imenu's tags are also weak, so the elisp knows very little about >> the tag, only where it is, and enough to queue the reader. > > All true. But we have other facilities as well. For instance, the > modes which use SMIE for indentation can implement extraction of > similar information, in a more accurate way. > I am not familiar with SMIE as an acronym, but a google search makes it look like someone made a parser generator, in which case there is no real difference except that SMIE is tuned for indentation, and wisent is tuned for parsing tags. > If we were able to easily substitute in SMIE-based "current tag" > implementation instead of using Wisent, that would be a plus. The problem is the same (ie - go write a parser to find tags), except the SMIE tagger isn't implemented yet. >> Yes. There are other tools that do different pieces of what CEDET does. > > I mean that you can't *really* use Semantic for "jump to a tag in the > project", because one doesn't usually like to open all project files > at once. But if the "daemon" proposal sees any development, maybe... > If by "open all project files" you mean pull file contents into a buffer and leave it open, then that is not what semantic does. The data is indeed resident in memory, but files stay closed unless the user asks to jump there. The first time you make a request that needs searching, it will open files to parse them, but then it closes the file. Later, it refers only the the cached data, not to the files. >> * It lets you 'copy' a tag, and 'yank' it somewhere else. >> * It provides an accurate 'beginning of defun', 'end of defun', >> 'narrow to defun' > > Emacs usually provides fairly accurate definitions of these as well. The difference is switching from "fairly" to "very", and mode authors would not need to go and write all those beginning-of-defun type overrides. > >> * Provides a starting symbol for some commands, such as symref. > > I wonder if it's ideal: in IntellijIDEA, say, you can click on any of > the method's uses and to list the other references. With your scheme, > however, one has to jump to its definition first. > There is always a desire to go two ways "where is the symbol under cursor", and "who uses the function I'm in". I was describing the later. The former is important, and not solved by my suggestion above. >> * You can parse the local context more quickly determining nesting >> context (ie - method in a class) for decoding symbols (like "this") > > Yes, you can usually resolve what 'this' is (and, consequently, > this.foo()). But not what foo.bar() is, in the general case. Not in a > duck-typed language anyway. > CEDET/Semantic usually gets foo.bar() syntax correct, unless you are saying something else. Can you elaborate? > So, that's a problem. If we could, using semantic-symref could be made > more natural. Yes. There is a spot in symref waiting with a comment for that nugget of code to be written. My primary concern is that of performance since that data is derived, not cached. Eric