Re: IDE

[Eric Ludlam <ericludlam@gmail.com>]

On 10/20/2015 07:28 AM, Dmitry Gutov wrote:
> On 10/20/2015 04:03 AM, Eric Ludlam wrote:
>
>> We should poke at this.  Can you share a little about what your tool
>> does?  Then perhaps we hypothesize about the efficacy of integrating
>> into CEDET as an example of integrating external tools.
>
> It probably wouldn't gain too much from CEDET integration.

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.

> It has:
>
> - Server, serving JSON over HTTP, with a RPC-like protocol.
>
> - Emacs client in the shape of a minor mode. It defines a 
> completion-at-point-functions element and a keymap with essentially 
> three commands: "jump to the definition", "jump back", "show 
> documentation for the method at point".
>

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 CEDET speak, the tooling that converts a symbol into a location would 
be a special kind of Semantic Database.  This could be tied to a project 
or tied in as a system database depending on what it is querying.  Or 
one of each.  The job of such databases is to provide a search for tag 
by name, completion substring, regexp, and for languages that care, type.

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.

This would enable Semantic's jump to tag system to be as accurate as yours.

I am not sure what your doc piece might be like.  There is some limited 
support for finding doc strings, but usually it just looks for comments 
preceding a tag.

> - To determine the current context (which would be similar to "current 
> tag" in Semantic), it calls ruby-add-log-current-method and parses the 
> returned string. I've improved that function in ruby-mode a year or 
> two ago, and it's pretty accurate.

We used to have a way to tweak add-log but I think the mechanism is for 
an older version of Emacs where we needed to use advice.  It would make 
sense to update this if there is a better way.

> Robe is also pretty hacky compared to most other similar tools:
>
> - The server loads itself into and runs from an REPL buffer. We either 
> expect the user to already have such a REPL running (with the project 
> loaded), or offer to launch one automatically (which fails in certain 
> configurations).
>
> - It doesn't support multiple projects in the same Emacs session.
>

An EDE type project for ruby (whatever that looks like) would provide a 
place to hang project specific REPL buffers as needed.

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

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.

Eric