extraneous(?) autocomplete info

[curej]

I'm getting a ton of (what I would call) extraneous autocomplete information in Ruby Netbeans.

For example, if I type the name of a model object and then type a period (whether I'm in a controller or a view), it shows a dizzying dropdown list of thousands of methods, including several hundred different versions of the "new" method (but no documentation - most method signatures are followed by "No comment found").

Has anyone encountered (and solved) this problem, if we agree that this is a problem? Could it be that I simply have access to all of those thousands of methods and so they must be reported by autocomplete?

[Erno Mononen]

Hi,

curej wrote:

>
> I'm getting a ton of (what I would call) extraneous autocomplete
> information in Ruby Netbeans.
>
> For example, if I type the name of a model object and then type a
> period (whether I'm in a controller or a view), it shows a dizzying
> dropdown list of thousands of methods, including several hundred
> different versions of the "new" method (but no documentation - most
> method signatures are followed by "No comment found").
>
> Has anyone encountered (and solved) this problem, if we agree that
> this is a problem? Could it be that I simply have access to all of
> those thousands of methods and so they must be reported by autocomplete?

This is due to Ruby's dynamic nature; in a lot of cases it is difficult
for the IDE to figure out what's the real type of the receiver, i.e. the
IDE isn't sure about what methods are available for the receiver at
runtime, so it falls back to showing all the methods available in the
project.

Some work has already been done in 6.7 to make the IDE more intelligent
in this respect, and when the IDE thinks it knows the type it displays
the relevant methods first in the code completion dialog. A lot remains
to be done still though - it is actually not too difficult to analyze
method bodies (to figure out possible return types), but to make it fast
enough is a bit of a challenge. In addition there are constructs that
are difficult/impossible to analyze - imagine e.g. a method created
dynamically using class_eval, as in:

Foo.class_eval(some_user_entered_string)

Going forward, I'm hoping to gradually improve the IDE's type inference
so that more and more cases get covered (and hopefully I can make it
faster too), that should help wrt. long code completion lists.

Erno

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[curej]

Erno,

Thanks for the explanation. It makes sense that the dynamic nature of the language makes things this task considerably more of a challenge than it would be in, say, Java.

I don't suppose there is any way the user can help the IDE by "hiding" or temporarily limiting the visibility of certain libraries that are not pertinent? I'm new to Ruby so forgive me if this sounds ignorant. But, for example, it seems to me that when I am in Rails, some of the methods that are reported as being available in autocomplete are actually from gems that I am not using in that project - Sinatra, etc? Is this correct or only my imagination? If correct then perhaps there's a way to hide these libraries from view while in Rails so that they do not muddy the namespace.

curej

On Wed, May 27, 2009 at 9:24 AM, Erno Mononen <Erno.Mononen@...> wrote:

Hi,

curej wrote:

I'm getting a ton of (what I would call) extraneous autocomplete information in Ruby Netbeans.

For example, if I type the name of a model object and then type a period (whether I'm in a controller or a view), it shows a dizzying dropdown list of thousands of methods, including several hundred different versions of the "new" method (but no documentation - most method signatures are followed by "No comment found").

Has anyone encountered (and solved) this problem, if we agree that this is a problem? Could it be that I simply have access to all of those thousands of methods and so they must be reported by autocomplete?

This is due to Ruby's dynamic nature; in a lot of cases it is difficult for the IDE to figure out what's the real type of the receiver, i.e. the IDE isn't sure about what methods are available for the receiver at runtime, so it falls back to showing all the methods available in the project.

Some work has already been done in 6.7 to make the IDE more intelligent in this respect, and when the IDE thinks it knows the type it displays the relevant methods first in the code completion dialog. A lot remains to be done still though - it is actually not too difficult to analyze method bodies (to figure out possible return types), but to make it fast enough is a bit of a challenge. In addition there are constructs that are difficult/impossible to analyze - imagine e.g. a method created dynamically using class_eval, as in:

Foo.class_eval(some_user_entered_string)

Going forward, I'm hoping to gradually improve the IDE's type inference so that more and more cases get covered (and hopefully I can make it faster too), that should help wrt. long code completion lists.

Erno

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Anthony Richardson-3]

This is a good idea. I have rails vendored, yet when I try and
navigate to methods it always wants to take me into the gem sources
rather than the vendored version. An way to decalre to the IDE what is
relevant would be good.

Cheers,

Anthony Richardson



On Thu, May 28, 2009 at 1:55 AM, curej <curej10@...> wrote:
> I don't suppose there is any way the user can help the IDE by "hiding" or
> temporarily limiting the visibility of certain libraries that are not
> pertinent?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Erno Mononen]

Anthony Richardson wrote:
> This is a good idea. I have rails vendored, yet when I try and
> navigate to methods it always wants to take me into the gem sources
> rather than the vendored version. An way to decalre to the IDE what is
> relevant would be good.
>  

Agreed -- for some reason I actually thought we already prefer vendor/
to gems for navigation, but indeed that's not the case. Shouldn't be too
hard to implement, will target 6.8 (too late for 6.7 at this point).

Erno


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...