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.
I have been experiencing activation of the autopopup although it was set to "false". Took me a while to track the issue to the CompletionSettings class. The problem is that CompletionSettings implements some form of "soft"-singleton. It keeps a SoftReference on the instance and if that's null, it recreates the instance. The steps to reproduce the problem are: 1. Disable autopopup for a mimetype. 2. Edit some file of the previous mimetype. At this point CompletionSettings is updated with the proper autopopup values (via notifyEditorComponentChange). 3. Trigger some OutOfMemory situation. The VM will try to free as much memory as possible now. The SoftReference from CompletionSettings will be freed ! 4. Type some autopopup trigger like the dot(.). This will ask for the CompletionSettings completionAutoPopup. At this point the soft reference is null, it will recreate a new instance of CompletionSettings. The completionAutoPopup method calls initialize() which reads the settings from MimePath.EMPTY with some "true" defaults. 5. Note how completionAutoPopup becomes true now and the completion popup is displayed. See the attached patch for a fix, it just uses a normal hard reference instead.
Created attachment 90175 [details] Simple patch to use a hard reference.
Thanks Emilian. I have added this issue to the list [1] of NetFIXed issues. Dusane, would you please be so kind and review + integrate the patch if you don't have any objections? Thanks! [1] http://wiki.netbeans.org/NetFIXIssues
CompletionSettings should represent a simple wrapper around the Preferences instance storing the code completion settings valid for ALL languages/mime-types (BTW: How do you disable code completion autopopup for a mime-type?). The Preferences instance constructed for the MimePath.EMPTY should be the only one used; there is no reason for using Preferences instances created for particular mime-types). In such a case, CompletionSettings recreation should not break anything. Thanks for pointing this problem out. Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/6150dfd3724d
Changing completion for a single mimetype is simple: just use the MimeLookup. It's also a very nice way to configure the IDE, not all people want the same settings for all file types... I don't agree with your patch though. You had a perfectly fine mechanism to tweak some completion settings per mimetype, which had a bug. Removing the feature altogether does fix the bug, but it also removes the flexibility for no good reason. What kept you from just adding my patch ?
OK - fixed in jet-main without removing the flexibility. http://hg.netbeans.org/jet-main/rev/8ce03218e26f
It looks better now. I see that your main concern is that you didn't want the singleton to be updated once the editor changes (via EditorRegistry). The new class looks better although you might as well have created static methods since getInstance is no longer providing a singleton but behaves as a factory -- creating new instances for each call. Glad that the per-mimetype feature is still there :-)
Integrated into 'main-golden', will be available in build *200910300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6150dfd3724d User: Dusan Balek <dbalek@netbeans.org> Log: Issue #175591: CompletionSettings inconsistent - fixed.
Integrated into 'main-golden', will be available in build *200910301401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8ce03218e26f User: Dusan Balek <dbalek@netbeans.org> Log: Issue #175591: CompletionSettings inconsistent - fix cont.
Thanks Dusane for integrating the patch and more importantly thanks very much Emilian for providing the patch!