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.
Code completion on a variable declaration "Foobar f" suggest two completions, "f" and "foobar". Not only is the "f" suggestion rather useless here, since the "f" is already present, but (more importantly) it makes completion to "foobar", which is usually the intent of invoking CC here, less convenient, because one always has to step over the "f" suggestion to select the "foobar" suggestion. A "no-op" suggestion like "f " here may make sense for _usages_ of the identifier, but hardly for its definition. Therefore it would be preferable to not suggest no-op completions for the name in variable declarations.
The suggested behavior would bring inconsistencies to the code completion results. Imagine situations: 1) Code completion is invoked on "Foobar " - two correct completions ("f" and "foobar") are suggested. Then "f" is typed - code completion should still suggests both completions (both match the typed prefix). 2) Code completion is invoked on "Foobar f" - suggesting "foobar" only would be inconsistency with case 1). Closing as WONTFIX.
I think one needs to distinguish the case of completing to an existing identifier (i.e. a _use_ of the identifier) from the case of completing to a new identifier (i.e. the _definition_ of the identifier). When completing to an existing identifier, one important purpose of the CC popup is to show which existing definitions there are that match the given prefix, including whether there is an identifier that is identical to the prefix. When completing to a new identifier, on the other hand, there is no such informational purpose. Note that you mention "correct completions". But for new identifiers, *any* completion is correct. The CC popup merely shows suggestions for some possible names for the new identifier, but it's not an indicator of correctness here. The programmer has most probably already decided on the identifier's name and only uses CC to save himself some typing. One can assume that he doesn't invoke code completion to select what he has already typed. Therefore, for the case of completing to a new identifier, it doesn't make sense to suggest something that doesn't add to the prefix that is already there. Given this criterion, "only show completions that aren't already completed", there is no inconsistency, not more as with "only show suggestions that match the prefix", which already causes "f" to be shown for "Foobar " but not for "Foobar fo".
PS: There currently is the inconsistency that "Foobar x" suggests "xF" but "Foobar f" does not suggest "fF". I would be in favor of dropping the "<prefix>F" suggestions. This would also get rid of the inconsistency that "xf" suggests "xfF" but "xF" does not suggest "xFF". Oh, and then there's also the inconsistency that there appears to be case correction logic by suggesting "foobar" for "Foo" (instead of suggesting "FooFoobar"), but none in suggesting "somefooFoobar" for "somefoo" (instead of suggesting "someFoobar").
Another data point: (1) "BufferedFoobar f" suggests "foobar", but not "f". (2) "BufferedFoobar " suggest "bf", but "BufferedFoobar bf" does not suggest "bf". IMO that supports the argument that "Foobar f" shouldn't suggest "f".
Not so serious IMHO. In fact, the current heuristics matches my expectations perfectly. Any patches are welcome, but please introduce an Options section for this and provide tests.
Updated TM.
See also Issue #182933
Assigning to default.