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: IDE Date: Sat, 17 Oct 2015 06:06:18 +0300 Message-ID: <5621BB2A.5000802@yandex.ru> 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> <5621B4D5.9040607@gmail.com> 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 1445051211 17000 80.91.229.3 (17 Oct 2015 03:06:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 03:06:51 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Eric Ludlam , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 05:06:44 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 1ZnHpT-0001WL-6P for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 05:06:43 +0200 Original-Received: from localhost ([::1]:56756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHpS-0005hZ-Nv for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 23:06:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHpE-0005hU-2O for emacs-devel@gnu.org; Fri, 16 Oct 2015 23:06:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnHp9-00051Y-11 for emacs-devel@gnu.org; Fri, 16 Oct 2015 23:06:28 -0400 Original-Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:35409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnHp8-00051A-OK; Fri, 16 Oct 2015 23:06:22 -0400 Original-Received: by wicll6 with SMTP id ll6so31873152wic.0; Fri, 16 Oct 2015 20:06:22 -0700 (PDT) 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=DCjJMKkOec1qsafc5vw3US+lBLksBitGjGbcCqCX6+E=; b=cHrKcadfqSZunWi2B7pahU8e9Nw52T1VDf6Igri5zwYdAR5qqzKaaIAUGv1/Dgvyzz mUtK68LVsCQDOJeQ6Lgfik96FUDO/eomWAUqgJTAtRg+PCsHPtmqytIA3zZLhhx2nEil YC7UZ8qJwOQq1yuvQFYf2U84eIm4jN1ezKFfa2AYDILmsSzbYYseNonEzZNbXtvyEmrV ayMaM/wLPn4qVn4G582YEO7x+6iE9ZYacHj8dMqscEZwV052OKJH7w+G1GBoNrP8pFqQ nQQCR1lMbOSnF8nPECZ/BZsN0ihiHQFCW870PP31C57icVZeUn4+JDTaEk7b5bf5eRa2 a7CQ== X-Received: by 10.180.74.47 with SMTP id q15mr8432829wiv.73.1445051182080; Fri, 16 Oct 2015 20:06:22 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id he3sm25839785wjc.48.2015.10.16.20.06.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 20:06:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <5621B4D5.9040607@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::232 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:191806 Archived-At: On 10/17/2015 05:39 AM, Eric Ludlam wrote: > 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. Is that still true if you're editing at the beginning of the file? > 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. My point is, Semantic grammars don't help with writing indentation code (could they?), and we already have SMIE grammars for several languages. It would make sense to be able to make do only with one or the other, not have them both for the same language. >> 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. That's less work than writing a grammar, and it could be reusable (at least partially) across languages. > 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. I mean that you have to use etags at some point anyway. Or gtags, or id-utils, etc. > 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. True enough. >> 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. I was also describing the latter. Although, I suppose, my way could be implemented on top of what Semantic does now, as long as it can "jump to the definition" accurately. > CEDET/Semantic usually gets foo.bar() syntax correct, unless you are > saying something else. Can you elaborate? In the few languages it properly supports now? Maybe it does, most of the time (although not in the problem example I gave in this discussion: https://gist.github.com/dgutov/19c45ef43d1c90b96483; no matter the argument tee is called with, `C-c , J' jumps to the first function with that name). But what about duck typed languages? If a method foo calls bar on its argument tee, we don't know the type of tee, all we know that it has a method bar. >> 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. Not sure what you mean here (which part you believe to have to be written yet, or which data we're talking about). But in any case, symref can afford to be a little slow when prompting for a symbol name, just as long the slowness is not proportional to the size of the repository (or the multiplier is small, at least).