« Return to Thread: extraneous(?) autocomplete info

Re: extraneous(?) autocomplete info

by curej :: Rate this Message:

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

« Return to Thread: extraneous(?) autocomplete info