This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In Ruby, the autocomplete list is too big. It shows choices that are not available based on "requires" that are not included in my project. For example, I have the "activerecord" gem installed and though I am not using it in my project (non-rails), activerecord methods show up as options. The autocomplete should only display methods etc. for gems that are required, methods etc. that are built into Ruby, and methods etc. defined in the programs.
Sorry, I submitted this one from my Mac. It should be for NetBeans 6.0 - 20070920. It probably applies to all versions.
Agreed. We should be smarter about this. For 6.0 it's too late to make major changes, but I'm planning some minor filtering, such that basically, none of the Rails gems are included in pure Ruby projects, and the RSpec gem stuff only shows up in _spec files, and so on. For a background on why things were implemented like this in the first place, see the discussion from here: http://www.javalobby.org/java/forums/t100988.html#92170271 Specifically, my post which said this: "Regarding "However, I think we can take it as read that content assist for a dynamic language will never be 100% accurate all of the time. So, shouldn't we aim to satisfy the common case, rather than reaching to satisfy every possible scenario?": If the alternatives are between too much and too little, I think "too much" is better. It's easy to disregard some method you're not interested in - but not so easy to find a method you're looking for that the IDE isn't showing you - especially if you want to find out say its parameter description. In my experience, after typing just a couple of characters from the prefix of a method or class name, you are looking at at most a handful of matches, and it's pretty easy to find the one you're looking for. In Java, we're used to each file declaring at the top which classes we're using (the import section). It's tempting to think of the Ruby file inclusions (require statements) as similar - but they're not. There's no requirement to import symbols you're using in this file - all that's required is that some previous file that has already executed by the time this file is executed has imported that given class! Thus, you can have this plain Ruby file, named "foo.rb": x = Test::Unit::TestCase If you run this file it will give you an error. But let's say you have this file: require 'test/unit' require 'foo' Now our foo file is run with the unit test classes in scope and Test::Unit::TestCase is actually a valid symbol in our foo.rb even though it has no imports. I don't think this is completely atypical; requires are different than imports, and I'm sure that when writing related files it's going happen that you have an entry point file which imports what you need and other files take these for granted. Certainly this happens in various frameworks - such as rspec files."
Too late to do anything else about this for 6.0 but it's going to be one of the first things I attack for the update release.
I think that filtering the gems it's a must, maybe it could be implemented faster at the project settings level. Currently I can see several pages of method .test and they are not even sorted by the class.
code completion issue -> reassigning to 'editor'
There is now an option for indexing only gems in vendor/gems (Tools->Options->Misc->Ruby), which should help a bit in Rails projects at least. But CC sure needs still more work to make it more usable.