Code completion in IDEA X.V: how to revert its behavior back to those of IDEA X

Th reasonable assumption is that once an autopopup completion is shown, you hit Ctrl+Space to indicate that you aren't satisfied with the variants suggested, so it works like a second completion invocation and presents more variants. If you don't use the autopopup, you can disable it. Even if you use it and hit Ctrl+Space, your local variable should still be the first suggestion, so it's easy to select it by Enter and nothing really changes in your typing.

Th reasonable assumption is that once an autopopup completion is shown, you hit Ctrl+Space to indicate that you aren't satisfied with the variants suggested, so it works like a second completion invocation and presents more variants.

I understand this, but I'd prefer it if this only would happen after having
shown the popup using Ctrl+Space. As it is now, it changes previous behavior
significantly and at the end has a negative impact on the productivity
because it slows me down.

Tom

I bet more people will say: "hey, I hit Ctrl+Space and it shows the same list I've already seen autopopupped. I want more, otherwise I wouldn't press those buttons! Give me my productivity!". So I'm against changing this.

Please add an option to show the popup only after pressing Ctrl+Space or
after typing a period. Thanks in advance.

Tom

Any ideas not involving setting creation? Out of curiosity, I've counted and found that I've currently have 7 different open suggestions to create a setting in completion. That would almost double the number of checkboxes in the Code Completion settings group. Those who proposed them would be happy, everyone else would have to read them all and understand whether they need them or not. So, I'd prefer to have a single behaviour that would please everyone more or less. I consider adding a setting only a last resort.

Settings / Editor / Code completion / Autopopup code completion = false? (Sorry, If I've understood your question wrong.)

Alexander.

VM option

Other ideas? :)

Are all of there 7 completion options orthogonal to each other?

No matter how you add options, I suggest to initialize them when upgrading
from a previous release that way, that the previous behavior is preserved.
For new installations you can initialize whatever you like.

Tom

I've never said that I'm going to implement them all :)
They're not completely orthogonal. Each addresses some problem, and for each of those problems I'd prefer to have a solution without new settings.
Here they are, for reference:

What about offering a plugin which adds these options. If a user don't want
to see them, (s)he can deactivate the plugin.

Tom

That's certainly possible, at least for some of them. If someone provides this plugin, it would help you. But it's still not a solution I'm looking for, having plugin or not is also a kind of setting ;)

OK, the new behaviour bugs me too.

Try typing System, but if you are like me you will occasionally start with SYstem. Now what happens depends on exactly how fast you type those first two letters. If you complete the SY before the autopopup appears then the first item in the list will be org.omg.PortableInterceptor.SYSTEM_EXCEPTION, on the other hand if you are bit slower then the first suggestion wil be java.lang.System, unless you have previously (unintentionally) accepted SYSTEM_EXCEPTION in which case that becomes the erroneous smart choice. That choice of SYSTEM_EXCEPTION is very sticky, once present it seems to dominate System. Deleting the import doesn't help either.

Another example. I want to type List<Event> and haven't yet imported java.util.List. However, my project also contains a Features.List<T> class (also not imported). Unfortunately it is the Features.List class that is top of the suggested list, with plain java.util.List a long way down.

In both cases it would help if the java. namespace had higher priority. Removing an import should remove any priority boost that your smart choice gives to classes like SYSTEM_EXCEPTION.

Mark

I have nothing really useful to add (yet), but can't help to note that, yes, the completion gets in the way much too often:
I accidentally complete garbage,
it locks my up/down keys,
it doesn't seem to learn any longer (even if I use the 3rd suggestion the umpteenth time, it will still show the same two useless suggestions in front of it the next time)
auto-complete when only-one choice sometimes does not work anymore,
...

The problem with SYSTEM_EXCEPTION will be fixed in the next 10.5.1 EAP, thanks.

As for java.* preference, that's quite controversial. If you have something in your own project, you might quite probable want it to be preferred. That's why we rely on statistics here. If you choose the right List several times, afterwards it should be at the top of the list. If it's not, then it's a bug and we'll appreciate very much if you provide more details on the code context and other ways we can reproduce and fix it.

Thanks for the SYSTEM_EXCEPTION fix.

The problem with your statistics is that they appear to be unduly influenced by mistaken choices --- those automatic choices of the item at the top of the list. Perhaps where an auto completion is removed within say 2 minutes, then its contribution to the stats is also removed (and perhaps even gets demerit points). Alternatively don't update the stats until an auto completion (or auto import) has survived for at least x seconds; choices that don't survive are downgraded in priority.

Mark

The problem is that it's actually quite hard to analyze if something has survived. Any editing operation can occur, and it's not obvious how to define survival. But that's an interesting idea, I'll think about it. In the meantime, you can override stats by purposely selecting the needed variant 4-5 times in a row, this should help.