apache
Auto Completion Fixes/Enhancement in both the IDE and VSCode Extension
Description
There is a noticeable delay in the AutoCompletion popup in both NetBeans IDE and the NetBeans VSCode Extension. After investigation, it appears the delay originates from the default value of "completion-auto-popup-delay", which is set to 250 ms in the upstream NetBeans codebase:
ide/editor/src/org/netbeans/modules/editor/resources/NetBeans-preferences.xml Manually overriding this value to 0 in:
%APPDATA%\NetBeans
successfully removes the latency in NetBeans IDE.
However, applying the same change in the VSCode extension under:
C:\Users<User>.vscode\extensions\asf.apache-netbeans-java-27.0.1\nbcode\nbcode\config\Editors\text\x-java\Preferences\org-netbeans-modules-editor-settings-CustomPreferences.xml
does not affect auto-completion behaviour, suggesting the extension may not read or honor this preference.
There are also related settings such as "javadoc-popup-next-to-cc" that appear configurable in the IDE but are not exposed or functional within the VSCode extension.
Additionally, some NetBeans IDE–specific features (for example, Maven Plugin Goals UI and pom.xml IntelliSense) are not available in the extension, and it is unclear whether this is by design, a technical limitation, or related to project scope.
Use case/motivation
-
Reducing the completion popup delay significantly improves responsiveness and overall user experience, especially for users accustomed to real-time IntelliSense.
-
Ensuring the VSCode extension respects the same configuration options as the IDE provides consistency across NetBeans tooling.
-
Exposing IDE-like settings (popup delays, JavaDoc popup behaviour, completion timing) would make the VSCode extension more appealing and usable for developers who prefer VSCode but rely on NetBeans’ Java capabilities.
-
Clarifying the intended scope and limitations of the VSCode extension helps contributors understand what enhancements are feasible and welcome.
Related issues
-
Should the default completion popup delay be reduced to 0 upstream? The current default of 250 ms introduces noticeable sluggishness. I am willing to submit a PR for this change if it is acceptable.
-
Does the VSCode extension intentionally ignore or bypass the editor settings stored in the "org-netbeans-modules-editor-settings-CustomPreferences.xml" files? If so, is there an alternative way to configure the behaviour of auto-completion within the extension?
-
Why are certain IDE settings such as "javadoc-popup-next-to-cc" not exposed or functional in the VSCode extension? Is this due to architectural constraints within the LSP implementation, or simply unimplemented?
-
Why are some IDE-specific features (such as Maven Plugin Goals UI and enhanced pom.xml IntelliSense) missing from the extension? Are these features out of scope for the extension's purpose, or is there a technical constraint preventing their inclusion?
Are you willing to submit a pull request?
Yes
Should the default completion popup delay be reduced to 0 upstream?
IMO: not by default. Since setting delays to 0 is not without side effects. It can even get in the way of regular editing since you might not even want it to pop up while typing quickly. (there is also always the hotkey which ignores all delays and opens auto completion)
edit: but reducing the default delay might be possible if it doesn't cause any problems.
Should the default completion popup delay be reduced to 0 upstream?
IMO: not by default. Since setting delays to 0 is not without side effects. It can even get in the way of regular editing since you might not even want it to pop up while typing quickly. (there is also always the hotkey which ignores all delays and opens auto completion)
edit: but reducing the default delay might be possible if it doesn't cause any problems.
Yeah it's fine if it's not on by default, but the fact that it's not even configurable through UI is what's problematic. I digged through the Internet and found out that setting was removed from the UI few years ago in an update, leading to manually tinkering with configuration files which is not ideal imo.