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: Sun, 11 Oct 2015 13:37:49 -0400 Message-ID: <561A9E6D.8080403@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> 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 1444585112 14913 80.91.229.3 (11 Oct 2015 17:38:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Oct 2015 17:38:32 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Eric Ludlam , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 11 19:38:25 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 1ZlKZj-0006b8-Ji for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 19:38:23 +0200 Original-Received: from localhost ([::1]:49249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlKZi-0006JA-IR for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 13:38:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlKZL-0006Ig-Ek for emacs-devel@gnu.org; Sun, 11 Oct 2015 13:38:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlKZH-00008M-BY for emacs-devel@gnu.org; Sun, 11 Oct 2015 13:37:59 -0400 Original-Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]:33368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlKZH-00007P-6P; Sun, 11 Oct 2015 13:37:55 -0400 Original-Received: by qkas79 with SMTP id s79so51105333qka.0; Sun, 11 Oct 2015 10:37:54 -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=6b14+hQgxz7xmI/fW7QsxwkAFqRJ1chP1KDvq+JKBQ4=; b=c2bkeNvryDZcbPpvBgEC+UMuUcCqclnkc83VNSRiuV/2P95hedJStlwNIq4uyekIG9 Q/0M5TZN7Qna9yTkakpiV6olVPZDg/G5Jf9AEJwzKNKoQfSwdw0TTjuvLn1oF2Vn1/ul kPS7tNLL5bewVqWrddCBvQ+ZSsbZ+5aT+SBihNcVJY0xMIfyoV4Ni93RGFjLshStfshn FwWFLFs2HiFtynKKUnrzksxcXOcbHZdOoq0roH0gMDVTcdbwULHLNkWlbr4RZDpGzI8j nNUpOMKfk8BzGhpeDynEqD6+iujYx8JHAtjVX4b3uHEu2z2ccCsZb4eM6jiyhWFCTT/8 72aw== X-Received: by 10.55.198.152 with SMTP id s24mr27696462qkl.1.1444585074512; Sun, 11 Oct 2015 10:37:54 -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 t37sm5486610qge.26.2015.10.11.10.37.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2015 10:37:53 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5619E7C7.5000401@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::22b 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:191250 Archived-At: On 10/11/2015 12:38 AM, Dmitry Gutov wrote: > Hi Eric, > > On 10/10/2015 07:48 PM, Eric Ludlam wrote: > >> I had always intended CEDET to be a baseline for IDE like features. >> Looking just at tagging files, those familiar with it's internals >> recognize that it can use external tools as weak as ctags or GLOBAL, and >> can use a more powerful external tool for parsing as well, such as using >> JAVAC for decompiling .jar files into tags. > > It sounds good if all I have is a parser/tagger. > > But if I already have an external tool that can give me a set of > completions at a given position in a given buffer, and also provides a > go-to-definition feature, what's the advantage of going through > Semantic? SRecode support? CEDET's tools are set up in layers. As an language support author you can start with a series of overrides for writing a lexer or parser yourself. If you have a tool that parses already (such as exuberent CTags), you can instead just start at the high level tagging parser and skip all the lower level stuff. If you have an existing completion engine for cases where you happen to have an interpreter with completion, or something else, you can just override the completion engine directly. The srecode tool does this, and there is an experimental clang version in CEDET's repository as well. Having overrides at all 3 levels is the best, since different tools ask for different features, but it is not necessary as there is backup implementation for the higher level features. > Not to mention that we have tools like Jedi that only (mostly) do > these two things, but don't provide dumps of the syntax tree. > >> As a backup, it also has >> in-buffer parsing for when you've only half-written your code, or when >> no external tool is available. > > That assumes we also have a Semantic grammar for the said language. > And then, we'll need to duplicate whatever logic is used by the > external tool to disambiguate between same-named methods in different > classes. > > If that's even possible. > Of course. For strongly typed languages the problems are deterministic so it's possible. For dynamic languages, they usually provide something you can ask. It's just a matter of integration. I enjoy working on puzzles like this, but for me it is a matter of free time. Kids, job, etc get in the way. >> The same philosophy is throughout CEDET. Unfortunately, those who are >> interested in tooling who brush casually past CEDET only see that people >> complain that it doesn't always complete right, or that the C++ part is >> hard to setup > > The example we've been given in one of the previous discussions of C++ > support is that Semantic can't tell the difference between different > methods with the same name? If Z#foo returns type A, and T#foo returns > type B, it's been shown that Semantic doesn't know which is the type > 'x.foo'. > > Given this, how would we expect it to properly support languages with > type inference like Scala or Go? Not to mention dynamic languages > which normally have no type annotations on methods, and often use more > complicated algorithms for accurate code completion. Semantic has the information to differentiate between two methods of different types. There are still a few short-cuts in the completion engine where it could do a little more to disambiguate. There is a function to '-select-best-tag' in the analyzer, but at the end, it just grabs the first element from the list of possibilities. If you have a particular use case in mind, it would good to have a simple example that shows what it is and maybe it will be easy to update. >> If we look at the two starting key features listed for IDEs, >> "completion" and "refactoring", the basics are all there. CEDET has a >> completion engine, but it is only as good as the input data. > > It's limited by the input data, sure, but it also has to know what to > do with it. > > If only implementing accurate code completion was as easy as writing a > language parser. This is a matter of time and desire. For the code I've been writing lately (arduino hobby stuff), it has been more than sufficient. David was interested in handling templates and was able to add support for that. If someone wants it to handle something new, the data is there to do it. >> CEDET also has 'srecode' which is about >> generating code. This bit is trickier, as the intention is you could >> write one highlevel tool that might extract tag data from your file, >> permute the language-independent tags, and then write them back out with >> srecode. There are tests showing this working, but they are simple and >> proof of concept and not stuff someone would depend on day-to-day. > > SRecode should be in a better position, but I imagine it would also > fail often enough in dynamic languages. I'm not quite sure what the intention is here. Srecode is just template expansion, with mechanisms to enable multiple layers of templates, and support for "application" templates and user override templates for customization. What's missing is someone taking the time to start building the logic to use semantic to pull buffers apart, and srecode to re-write the code. > And in any case, one has to teach Semantic about scoping rules for > each given language, for SRecode to only rename, say, a variable 'foo' > but not function 'foo', or only the variable 'bar', but not the > variable 'bar' up the scope that's being shadowed. > There is a fair amount of logic for supporting language scopes. There is almost nothing about running filters for "all the calls to symbol FOO that has some particular feature". The symref tool has a comment in it that says "do the filtering here", but no one has gotten around to it. My assumption is that it would be easier to start there than start from scratch, unless you just hijack some external tool. Eric