Autocompletion getting in the way when creating new local variables?

Here's the scenario:

Start typing a new undeclared variable name, such as "label"

Immediately, autocompletion pops up, with "msg_labels_t" preselected.

If you then type "=", appcode changes "label" to "msg_labels_t" and then inserts the "=". The only way to avoid this is to hit Escape to dismiss autocompletion before typing "=".


These characters will cause appcode to insert the preselected autocompletion:
     *
     =
     .


These characters will cause appcode to dismiss autocompletion without inserting the preselection:
     /
     &
     <
     >
     ^
     !



So what's the rule for which keyboard events automatically insert the preselected autocompletion choice? Is there a way around this? I remember Idea introduced this behavior a while back, and I can't remember how I worked around it there.


Since I always create new variables by typing the new name and use intentions to create the variable for me, this bites me a lot. To make it more annoying, the escape key is really tiny on my keyboard.
6 comments

This annoys me as well.

I don't understand why autocomplete doesn't stick to its shortcut, ie ctrl-space. Why does it go into effect when I hit space or any other character(without ctrl)??

Quite a few times, I then have to delete what was just written, and do it again using esc. This is the opposite of helping. The times when the first guess is correct are very rare.

In addition, I'll probably never use 'msg_labels_t' in my whole life so the autocomplete "smarts" need some work as well.

0

Ok I removed this behavior by going to
Settings -> Editor -> Code Completion
and setting
"Preselect the first selection" to "Never" instead of "Smart"

Now I can write 'label' unhindered.

In an ideal world, I'd like to keep smart preselect, but have it only "fire" when I enter ctrl-space.

I am going to try this workaround for a while and see if there's any negative effects.

The other thing I did before is:

- Write the method call, e.g. [self getThatString];
- Then hit opt-cmd V to extract a variable

This creates a predefined variable with the right type (return type of the method).

0

Thanks, I guess I should try "Never" and see whether that's painful in the other way.

I seem to remember that there are other scenarios where appcode preselects the right thing, and in that case the workflow is much better when this preselected autocompletion does the right thing.

Alternatively, since appcode already closes the autocompletion as soon as you type characacters such as "&", I'm thinking it would be good if they just extend that behavior to characters you would commonly type after a variable name, such as "="


- Will

0

There a some pros and cons of autocompletion, as you alredy have found.

The probelm is that there are way to many various context and expectations about the behaviour that conflict with each other (e.g. ability to quickly insert an element from the list and possibility to type the new variable's name). The option 'Preselect first completion item' was intented to allow choosing the preferred way of using autocompletion.
Try setting this option to Never and, when necessary, use arrow keys to select elements or press ctrl+space shortcut to make the list behave as normal completion list.

You can also disable autocompletion and use the ctrl+space shortcut (autocompletion doesn't stick to a shortcut, because it is autocompletion - it requires no shortcut).

0

Willis, can we ask you to file a request for the characters that you think should finish the completion list?

0

I can certainly appreciate that this is a complicated issue, with a lot of tradeoffs. And don't get me wrong, autocompletion works great in many other scenarios, when I'm not trying to create new symbols. It would be a shame to have to turn it off because when it works, it's like magic.

After playing with this a bit, I think I really just need "=" and "." to dismiss autocompletion.

Here's the issue: Preselected autocompletion gets in the way of creating new variable

Thanks,
Will

0

Please sign in to leave a comment.