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: Wed, 21 Oct 2015 21:35:53 -0400 Message-ID: <56283D79.2070904@gmail.com> 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> <871tcyexa9.fsf@fimbulvetr.bsc.es> <87612a7my2.fsf@fencepost.gnu.org> <561DC925.5050001@siege-engine.com> <561E32D2.4060501@yandex.ru> <83wpum3ozk.fsf@gnu.org> <87si59ln6u.fsf@isaac.fritz.box> <56224B63.3010803@yandex.ru> <562592ED.1070104@siege-engine.com> <56262577.70107@yandex.ru> <562702C2.6070505@gmail.com> <56276ECE.3090508@yandex.ru> <56281747.9050305@gmail.com> <56282664.3000409@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 1445477780 25174 80.91.229.3 (22 Oct 2015 01:36:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 01:36:20 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Dmitry Gutov , David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 22 03:36:15 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 1Zp4nd-0007OH-W0 for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 03:36:14 +0200 Original-Received: from localhost ([::1]:55190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp4nd-0003jj-Lf for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2015 21:36:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp4nQ-0003je-Ov for emacs-devel@gnu.org; Wed, 21 Oct 2015 21:36:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zp4nL-0000Ci-PS for emacs-devel@gnu.org; Wed, 21 Oct 2015 21:36:00 -0400 Original-Received: from mail-yk0-x22f.google.com ([2607:f8b0:4002:c07::22f]:32914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp4nL-0000Ce-K9 for emacs-devel@gnu.org; Wed, 21 Oct 2015 21:35:55 -0400 Original-Received: by yknn9 with SMTP id n9so68559473ykn.0 for ; Wed, 21 Oct 2015 18:35:55 -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=/oL0enLABr/91w5v9RJWULS855CHI9Dq5FE/kmW/q1s=; b=0QGngaUGz4V2D5yMFqijb/8LIfI6zEb8wGDUchfwWvDqq+VehZilFR5lzCFdJaX4gN otUxc6vyZF+nMW04bktszRb/ytrdbL72ZwuvKFqvlbCMgdzfZ/+hj7jD0LKE6/j+jBGx +r8/7bmZ0JDIc7NkUQK4duNGvu7zK+lPhRJfISgKabfj1/apznXJZm2eSTtMp3Lu7fzs tW1kpeNHERflDGTITBm9gR4eeN5E8sBnIljYeFDaVA4YWe01+JLtkc7yt93pJl/0k3hp Q8Zpb4Oxh7c9llyw6dgqAQp5fSid6DDRXSiev+0gc/NECLv9T0LySIen6EGEmFu/A1jS 7u0A== X-Received: by 10.13.214.75 with SMTP id y72mr9270267ywd.108.1445477755312; Wed, 21 Oct 2015 18:35:55 -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 u75sm8101918ywf.21.2015.10.21.18.35.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 18:35:54 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <56282664.3000409@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::22f 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:192337 Archived-At: On 10/21/2015 07:57 PM, Dmitry Gutov wrote: > On 10/22/2015 01:52 AM, Eric Ludlam wrote: > >> I don't think it is about if CEDET improves ROBE. I looked at ROBE on >> github, and think there is some core piece of it regarding talking to >> ruby that can be integrated as an extension of CEDET. You could then use >> the company-mode, auto-complete, > > Well, that part doesn't make sense. I couldn't care less about > auto-complete, and company-mode already supports > completion-at-point-functions. Semantic does, too. > completion-at-point-functions is a thinner dependency, and its API is > at least as rich as what Semantic provides. > I assumed auto-complete and company were important because the ROBE documentation talked about how it supported those tools. I'm not sure what is relevant here as far as listing features. There are 12 minor modes that come with semantic doing various diverse things. Things like idle-summary-mode will show you an api summary of the symbol under point. Breadcrumbs shows you a more oo version of where the cursor is. Outside of those modes, the core analyzer and completion engines both use database backends to figure out what is going on near cursor and do completion. There is COGRE which can pull data from the buffer, reference some databases, and pop up a uml diagram of your code which is a bit over-the-top. There are random utilities like semantic refactor that would need to be extended to new langauges but would gain base support from cedet. There are browsers like speedbar and ECB that pull in data and let you navigate the structure of the code. Of course, if none of those things are important, then you would have no reason to want to integrate w/ CEDET. > >> There is at least one contribution on top of cedet that do similar >> disambiguation using fancy uis. I think it copied a textmate feature. > > I'd love to take a look. > It is called eassist. Looks like I was remembering it from 2006, so not sure how it will work with recent Emacs changes. > >> If you instead refer to a library of files unrelated to the system, then >> ideally those would have their own project structure around them to >> enable correct navigation. > > a) There might not be a sufficient project structure (as with the > system includes). > b) The project structure of that external dependency might not be > enough. Here's what should be a clearer analogy: > > Let's say that my projects P1 and P2 include the library lib_foo. It > contains something like this: > > class IFoo { > public: > virtual void bar(); > }; > > class Tee { > public: > int qux(IFoo& foo) { > foo.bar(); > } > } > > Now, somewhere in P1 there's a snippet of code like: > > tee = new Tee(); > tee.qux(new P1Foo()); > > To follow the control flow, I move cursor to the qux call, jump to its > definition (thus moving into lib_foo), and then I need to find the > definition of bar that qux is calling (or rather, all of its overrides). > > But only looking in lib_foo is insufficient for that: P1Foo is defined > inside P1, and lib_foo, by itself, doesn't know anything about P1. > It's P1 that depends on it. > > So a seemingly obvious solution would be, when jumping to lib_foo, to > store the fact that we came from P1 this time around. But there's no > obvious place to keep it (directory-local storage?), and there might > be other difficulties I haven't accounted for. > Ah, I see. I hadn't considered a workflow like this. I can see how that would be useful. I haven't thought about how to solve that problem. I suspect the tooling would be custom where it knows more about the language, and can infer intent based on things like 'virtual' or the prospect of there being overrides. > >> Semantic doesn't demand it's parsers be in wisent, or even in Emacs at >> all. If you have a nice Ruby grammar in Ruby, and you can convert it's >> internal data into lisp-like syntax, pulling it into the Semantic system >> is pretty easy. What you would loose is dynamic reparsing without >> having to save, thus it may be a bit quirky. > > Why would I have to sacrifice reparsing without saving? I could sent > the current buffer contents to the completion server, e.g. over HTTP. > That's actually common practice now. > That sounds good. Eric