Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

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.

> plus many other tools that already use
> CEDET APIs, and could delete that code from robe.

Being able to delete any considerable amount of code is doubtful. 
Speaking of "many other tools", a compelling example would help. IMenu 
already works adequately thanks to ruby-mode, and which-func-mode works 
as well.

> In other words, your ruby experience would have more options without
> having to add them to robe yourself.

I get that idea, of course. An extra file with a bridge to Semantic 
wouldn't be the worst thing to have.

> It is speculative to suggest that writing a ruby wisent parser would
> take less time than to write all the same types of extensions already on
> top of CEDET in Robe since I'm not sure which subset of features is the
> useful subset for something like ruby.

Therein lies the problem: I've been trying out CEDET for a while, and 
I'm still not sure which extensions I'd want to reimplement. TAB 
completion in semantic-complete-jump is kinda nice, but it has a 
downside compared to the xref interface as well.

> In this case, things like semantic-complete-jump you could use the TAB
> technique to disambiguate, and semantic-ia-complete-jump might be able
> to distinguish depending on what sort of type information is available.

At first I was going to say it might be a solid (if small) improvement, 
but... there might be a mismatch:

- Simply searching for methods with the given name, like 
semantic-complete-jump, iterating through all matches, is wasteful IMO. 
It's much better to use the context if you can (or allow the user to 
input the fully qualified method name, as an extra feature).

- Even when the context is used, Robe can still return multiple matches. 
So if semantic-ia-complete-jump can't deal with that (and display all 
matches, for instance), it's not a good fit either.

> 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.

> The semantic javap extension pulls java tags from Jar files, and does
> not need to claim they are temporary tags because the data provided is
> as-good as the java parser.  If your ruby system is similar, then the
> system would not need to extract additional data from the source file.

Likewise, Robe would return a list of more-or-less exact tags.

Ruby runtimes keep the location of every defined method.

> In C++ and Java, the common files would be 'system' includes.  The
> naming is a bit C centric, but the basic idea is that there are system
> includes projects refer to, and those in turn aren't in a project, but
> refer to system paths to continue navigating between themselves.

That can be a system include, or it can be a library in a Git checkout 
that, say, two projects are using (it's included in the build by both of 
them).

> 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.

> Of course, the above examples for C don't have external REPL buffers to
> maintain, but might use independent GNU Global databases which are less
> heavy weight than an external process-per-project.

Yes, I believe you're going to have the same problem with etags, gtags 
or etc, if you try to use it in the described scenario.

> I'm not sure I followed this.  The shared code refers back to project1
> in some way?  This sounds like messy code you wouldn't want to write so
> I'm not sure I understand what you are trying to do.

I want to keep track of which project I'm working in right now. For code 
navigation forward, not back, like described above.

> Standard emacs mark-ring stuff is usually sufficient for traveling back.

Mark rings are highly inadequate, but that's beside the point.

> 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.

> Indeed, I suggested it to simply show someone made a useful grammar that
> looks relatively simple.

Simply redoing it to clear the copyright status won't be enough. Last I 
checked (some 3 years ago), the grammar didn't work. I've also seen 
complaints to that effect somewhere on the web.