Re: IDE

[Dmitry Gutov]

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.

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

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

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

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

It's a struct, containing both the arguments list, and a doc string.

I display it specially, though: do a little lightweight parsing, and 
highlight the Ruby examples parts with ruby-mode font-lock rules, and C 
sources with c-mode. Plus highlighted function signature at the top and 
a button to go to the source.

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

ruby-add-log-current-method is the value of 
add-log-current-defun-function, but I don't know if you'd be able to use 
it for different languages: the format doesn't seem to be particularly 
standardized.

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

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.

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.

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