Re: IDE

[Eric Ludlam <ericludlam@gmail.com>]

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