Add an option to prevent using Enter to select completions

[OverLordGoldDragon]

When a typed method name is matched exactly with suggestion's, I have a "press Enter twice or click away or press space" overhead for any linter suggestion. I understand the linter suggestion also includes a docstring excerpt, or that a 'complete' method name can be another method name's substring, but my request can be handled as follows:

• If typed method matches any linter suggestion exactly, then automatically [Enter] the suggestion upon typing, without consuming the next keystroke - unless the input extends a method's name (i.e. is alphanumeric or underscore)
• So, if I type .stem and Enter, I should newline (the Enter isn't consumed by the linter)
• Can make this a configurable so current behavior remains an option

[dalthviz]

Hi @OverLordGoldDragon thanks for the feedback! I think probably having an option for such behavior could be worthy for some people but I'm not sure how complex could it be to implement, what do you guys think @spyder-ide/core-developers ?

[bcolsen]

The easiest thing to do here is to give an option to have enter not complete it ever. I would activate that as I always use tab to complete.

My only complaint about @OverLordGoldDragon is the difficulty in explaining the option in the preferences, while disabling enter is pretty easy(and covers the use case if you are into 'tab').

• Enter accepts code completions. (# Checked by default)

This could go along with disabling "tab" #12682.

As an aside tab will start a completion and accept it but you can't accept the completion with ctrl+space or whatever you set the completion hotkey too. This would be quite important if you disabled 'tab' and 'enter' :-)

[OverLordGoldDragon]

@bcolsen How about: "If enabled, pressing Enter will newline instead of inserting code completion" (what else could Enter do?). And yes, I'd be fine with using Tab instead of Enter.

If that doesn't suffice, you do have at least 202 characters to work with:

[ccordoba12]

We'll take a look at this for 4.2.0.

[ishipachev]

I would support this with such Pythonic case:

After "0." I would like to go to the next line. But hitting Enter force me to put first suggestion from autocomplete.
And some other cases when I want to move to newline, instead of using something from autocomplete form.
My recipe would be let user to switch off "Enter" as a hotkey for autocompleting. Tab works nice for such situations and as far as I know is mostly used in others IDEs.

[ccordoba12]

Thanks for the explanation @ishipachev! We'll add an option to configure this in 4.2 for sure.

[OverLordGoldDragon]

Another use-case, just to be sure it's covered; prepending self. triggers suggestions as if there's nothing after the .:

(gather_fns was typed first.) Enter should be able to bypass these.

[NightSightGit]

@ccordoba12 I tried both the 4.2.5 and 5.0.1 release but can't find the option to disable enter to complete anywhere. I do like to use the auto complete feature with tab but it's driving me crazy that it is also auto completing when I want to return to the next line. I have been searching all over the Internet on how to disable it but can't find anything besides this issue thread, which mentions it should be added since 4.2?

[ccordoba12]

Sorry but we haven't had time to add an option for this.

[RemiDav]

Any update on this? It has been one year since the last message.

This is by far the most annoying issue on Spyder.
Using Enter for newline or Ctrl+Enter for "run block" often inserts unwelcomed code instead of executing the desired action.

[ccordoba12]

Hey @RemiDav, sorry we haven't looked at this. But I'll schedule it so we can address it in one of our next versions.

[dcknuth]

Want to support doing something here. Maybe shift + Enter does not complete and always gives a newline? I like only tab autofills best though.

[geograz]

Is there any development of this issue? Would be nice to turn this off.

[ccordoba12]

@geograz, no, there hasn't been. We'll try to address it in Spyder 6, to be released in the second half of the year.

[DeltaMod]

@geograz, no, there hasn't been. We'll try to address it in Spyder 6, to be released in the second half of the year.

This is still a major nuisance.
Not only is the autocomplete extremely aggressive for things it shouldn't even try to autocomplete for, it wouldn't even be a problem if the "Code Completion" keyboard shortcut in the settings could actually be assigned as the sole shortcut.

Let's say I have a parameter that just says dataset = 1 and I have parameters that include numbers (like p0/x0/Plot0 you name it)
If I want to quickly swap to dataset = 0, and run the codeblock using Ctrl+Enter, this autocomplete will sneak in and replace my 0 with the first item in the autocomplete list composed of all variables that contain the letter 0? I cannot count the number of times I have accidentally had "ArithmeticError" autocompleted for when I've tried to run a code block.

[ccordoba12]

@DeltaMod, I understand your frustration and we'll try to implement this feature for Spyder 6.1.0, to be released during the second half of the year (6.0 will be released in a couple of months but we don't have time for that).

In the meantime, you could disable completions on the fly to avoid that annoying behavior. You can do that by going to the menu Tools > Preferences, then selecting the pane Completion and linting > General and finally unchecking the option called Show completions on the fly. Let us know if that works for you.

[RemiDav]

We'll take a look at this for 4.2.0.

Thanks for the explanation @ishipachev! We'll add an option to configure this in 4.2 for sure.

Then it was 5.3.2, 5.3.3, 5.3.4 ... now 6.1.0

Realistically, will this ever be fixed? Or there will always be something with higher priority and it will keep being pushed back to 13.1.0 and further?

[ccordoba12]

Sorry for the multiple delays but this is a bit low priority for us because it doesn't affect the way we use Spyder. I develop Spyder with Spyder and haven't encountered this problem so far, but I understand it's annoying for users that evaluate code frequently (which is not my case).

In addition, we didn't want to add new features to the Editor before doing a big refactoring that was planned for a long time (its purpose was to improve interoperability between plugins with a new API we created for Spyder 5). The good news is that that refactoring is finally done (see PR #21353, merged last week). But since we're wrapping things up for Spyder 6.0, we won't have time to address this for that release (as I said above).

However, I'll make sure this lands in 6.1.0 because the conditions are finally there to make it a reality.

[RemiDav]

Thanks a lot for the details. I'll remain optimistic about it then.