Re: IDE

[Eric Ludlam]

On 10/21/2015 06:54 AM, Dmitry Gutov wrote:
> On 10/21/2015 06:13 AM, Eric Ludlam wrote:
>
> > Ruby support tooling itself would not benefit from CEDET integration,
> > but tools built on CEDET would gain Ruby support, and that improves the
> > diversity of Ruby related tools available.
>
> If CEDET support won't improve Robe, and if the said support will 
> amount to writing a Wisent grammar, it just becomes a separate task.
>
> Which I don't object to doing, in principle, but it'll go to the 
> bottom of the pile, in terms of priority.
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, plus many other tools that already use 
CEDET APIs, and could delete that code from robe.

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

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.

> > Inside this feature you must have a way to query for the location of a
> > particular symbol, and convert a symbol into a doc reference.
>
> In both cases, I often have to prompt the user (with completing-read) 
> to disambiguate between classes that define the method with the given 
> name.

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.

There is at least one contribution on top of cedet that do similar 
disambiguation using fancy uis.  I think it copied a textmate feature.

> > The output is a list of matches as faux tags.  If an application wanted
> > to know more about the symbol, it would pull in the reference file, and
> > extract real tag data using whatever parser is available.
>
> So as faux tags, I could return all methods with the same name from 
> different classes?

Yes.  You would provide what you do know (full class names, fields, 
methods, different file locations, etc) which could be initially 
reasoned on.  Sometimes no more is needed.  Other times those files 
might be opened to get more data using a better wisent parser.

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.

> > This would enable Semantic's jump to tag system to be as accurate as 
> > yours.
>
> Would that be semantic-complete-jump or semantic-ia-fast-jump?

Both, plus other similar functions different people have written.

> > An EDE type project for ruby (whatever that looks like) would provide a
> > place to hang project specific REPL buffers as needed.
>
> How? Using which major mode? I current use inf-ruby for that (not 
> available in Emacs, for copyright assignment reasons). So it seems I'd 
> have to add multi-REPL support for it first.
>
> The conceptually hard question is what do you do with external files 
> that can be referenced from different projects? Suppose you have two 
> open projects, each with its own REPL, you made a jump to an external 
> file from project1. The you want to "jump to definition" on some 
> method call in there. How do you pick the right REPL to ask for info?

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.

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.

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.

> Suppose, after the first jump, you saved the reference to the right 
> project in a buffer-local variable, so you can refer to it for the 
> second jump. What if I want to do the next jump not from the same 
> exact file, but from its neighbor? As a user, I can be confident that 
> both files must be referenced by the project, but there will be no 
> buffer-local value to use.

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.

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

> Finding an idiomatic approach to that would be great.
>
> > > - It misses some trivial opportunities to infer the type of a local
> > > variable. That would be my first priority to work on... when I deal
> > > with all that project and xref stuff in the core, I guess.
> >
> > I'm not sure which code bit you are referencing here.  If you do your
> > tag parsing with a semantic grammar, then you can optionally use that
> > same grammar to parse function bodies, and thus make detecting local
> > variable types a bit easier.   I'm speculating however as I am not
> > familiar with Ruby.
>
> I don't know how much work would that be. Ruby doesn't have anything 
> close to official, up-to-date BNF grammar. And it's pretty complex.
>
> At the moment, I'm doing context parsing in Elisp, so fix for the 
> "trivial opportunities" might also be in Elisp, at first, with a few 
> simple regexp searches.
>
> However, I'm seriously considering moving that part (and more) to 
> Ruby, so that authors of integration with other editors won't have to 
> redo that work:
>
> - There's a feature request for Vim support.
> - Someone actually implemented an Atom plugin already (not at all 
> popular so far, but that doesn't matter).
>
> I'd also be able to reuse an existing parser. There is one that's been 
> gaining in popularity over the last years.

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.

> > There is a wisent based grammar for Ruby in the 'contrib' area that
> > seems straightforward.  It would probably not be much of a stretch to
> > build one with the right releases to include in Emacs, solve this one
> > problem, and then get support from other CEDET tools.
>
> Since that grammar has been outside of Emacs for so long, I always 
> assumed that the author vanished, and obtaining the release is 
> impossible.

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

Eric