Spyder: On the fly code completion interferes with normal typing

Created on 4 Sep 2019  路  28Comments  路  Source: spyder-ide/spyder

Description

What steps will reproduce the problem?

This may be intended behavior, however, it didn't happen with 3.X.

With code completion and on the fly code completion turned on (note these are on different panes in preferences, which makes discovery hard), try to type the following function definition in a new editor window.

def f(x):
    return x

The code completion pops up a window with xrange as the completion of the return x. If you are typing quickly (as I do) it will auto-complete x as xrange, yielding

def f(x):
    return xrange

I think 3.x had a way to control whether ENTER auto completes or not, I don't think I see that in 4 (this issue reporter window is modal, so I can't check while I am typing this)

Anyway, this may be the intended/desired behavior, but I find it hard to imagine most will find it useful. One may counter that x is a bad variable name, but I only really do math in Python, so x is very common usage.

Versions

  • Spyder version: 4.0.0b4
  • Python version: 3.7.3
  • Qt version: 5.9.6
  • PyQt5 version: 5.9.2
  • Operating System: Windows 7

Dependencies

pygments >=2.0    :  2.4.2 (OK)
qdarkstyle >=2.6.4:  2.7 (OK)
sphinx >=0.6.6    :  2.1.2 (OK)
pyls >=0.27.0     :  0.28.2 (OK)
nbconvert >=4.0   :  5.5.0 (OK)
pandas >=0.13.1   :  0.25.1 (OK)
numpy >=1.7       :  1.16.4 (OK)
sympy >=0.7.3     :  1.4 (OK)
cython >=0.21     :  0.29.13 (OK)
qtconsole >=4.5.2 :  4.5.4 (OK)
IPython >=4.0     :  7.8.0 (OK)
matplotlib >=2.0.0:  3.1.1 (OK)
pylint >=0.25     :  2.3.1 (OK)
Editor Bug

All 28 comments

@andfoy, please take a look at this one. What do you think we should do about this?

I think it is better if users disable automatic completions if they find it cumbersome

Sorry @andfoy but that's not enough. I think this is a real problem and something we should try to address better instead of simply dismissing it. Else we'll have to disable automatic completions by default before Spyder 4.

Perhaps we could detect if the user is typing too fast to avoid auto-completing a single entry?

I too have found automatic completion to be rather annoying at times.
I thing the main issue is having <enter/return> select the completions. It is the natural thing to do I guess?

Maybe we could consider disabling the key for selecting the automatic completion and use <tab> instead?

I see the use case the user mentions, typing a line of code and then pressing return to move to the next line should not select a completion... and having to type <esc> seem awkward.

Perhaps we could detect if the user is typing too fast to avoid auto-completing a single entry?

This might work, but will require some tweaking, so basically only fire automatic completions if there is a "pause"

competions

I thing the main issue is having select the completions. It is the natural thing to do I guess?

I agree with this comment, we could disable completion inserting when using Enter

With respect to the comments issue raised by @goanpeca, I think its difficult to know if someone is writing inside a comment, due to the existence of multiple LSP servers. Also, some users like to complete words in their comments or strings

Perhaps we could detect if the user is typing too fast to avoid auto-completing a single entry?

Maybe we could do that

I probably mislead when I used the term 'too fast'; I'm just typing code and then hit return when I'm done with the line. The speed only matters because I don't give myself time to notice an autocomplete suggestion popped up which I would then have to hit ESC to clear it before pressing return. I wasn't suggesting I wanted different behavior based on typing speed.

For what it's worth I tried this in Sublime Text and got essentially identical behavior, so at least some other editors consider this correct/desirable behavior.

Another test. In an empty editor, type x.base and hit return. In this example x doesn't exist, yet 'base' gets auto completed to 'basestring', so you end up with x.basestring in the editor.

For me this makes the functionality useless, as trying to complete a line by pressing return is fraught with error. Yet some other editors do it this way, so what do I know?

I, for one, would like to use tab for completion (as in bash), as @goanpeca suggested.

Yes, I think that's the best solution too.

@goanpeca, please take a look at this one.

@ccordoba12 so use tab instead of enter?

Yeah, let's try that to see how it goes.

Considering prior art (e.g. Rstudio) may be valuable on this one. Despite being a huge fan of OTF in Rstudio and missing it in Spyder, I have the latter's implementation disabled due to the problems discussed here. (As @rlabbe also noted, I had a very hard time finding the relevant setting despite being an ex-Spyder-dev鈥攃an this be a separate issue?).

Rstudio delays showing OTF completion until a configurable number of characters are entered (default 3) and a configurable keyboard idle delay has passed (by default ~500 ms) IIRC; other editors/IDEs are similar particularly with the former. Adding one or both would resolve @rlabbe 's example case and be a substantial improvement over the status quo, to the point where given the much better ergonomics and cross-IDE consistency of Return over Tab I would retain the former; it should at least be a configurable option given its strong coupling to user preference/workflow, and that hardcoding it would be a regression over Spyder 3 and other IDEs.

Also, its worth nothing that unlike Spyder, Rstudio (and almost every other IDE/editor I recall using) doesn't show completions in strings or comments as @goanpeca mentioned despite supporting OTF completions out of the box for numerous different languages (unlike Spyder, which only officially supports one); this results in constant popups, typing lags and eating return chars (like here), and is the main reason I currently find Spyder's OTF more trouble than its worth. Can this be opened as a separate issue?

Thoughts @ccordoba12 ?

@rlabbe could you check this https://github.com/spyder-ide/spyder/pull/10262

It adds a delay and disables on the fly completion on comments and strings. It should probably handle your use case better. Please test it.

Rstudio delays showing OTF completion until a configurable number of characters are entered (default 3) and a configurable keyboard idle delay has passed

I also think this is a better solution than using Tab instead of Enter to select the current completion and it'd also help when using other editors as well. Therefore, I'm going to close PR #10250 in favor of implementing this solution.

@goanpeca, in order to not add more options to the Introspection tab of the LSP page (which already has a lot), please create a new tab there called Completion and move all completion related options there, along with these new ones. The rest of the options should stay in the Introspection tab.

Also, please organize the tabs of that page like this:

Completion | Linting | Introspection | Code style | ...

Completion | Linting | Introspection | Code style | ...

Not to bikeshed over a relatively minor detail, but you might consider swapping the positions of Linting and Introspection so that completion, code style and docstring style are still contiguous (as they are currently) given that all three fall under real-time code analysis.

@goanpeca, did you mean to name me? I don't have a say in this project, and I'm not really set up to take pull requests from this project. I'm on beta5, where this behavior still appears.

@rlabbe I don't speak with any authority, but based on what was said, Gonzalo requested that you test his PR, to see if it solves your problem acceptably. If you were to do so, since you should already have the required dependencies with beta 5, you would merely need to run three commands in order:

  1. git clone the Spyder repo (and cd spyder into it)
  2. git pr 10262 (using the standard git pr alias) to grab @goanpeca 's PR branch
  3. python bootstrap.py (assuming you have your Spyder 4 environment activated), which would launch Spyder and allow you to test the change.

More detailed instructions are available in this repo's Contributing guide, although most of that is unnecessary since you already have an environment set up.

However, you should hold off on that for now, since @ccordoba12 closed that PR in favor of a modified and hopefully better approach, so you'll want to do the above to test that PR instead once it is ready. Thanks.

@CAM-Gerlach, thanks for the detailed instructions. I'll be happy to give that a go if they ask me. I've slightly altered the code in my current Sypder, configuration which I don't want to lose, and it looks like this suggestion would work perfectly for me.

Spyder has code to lossesly preserve configuration settings between versions, though with betas and dev releases there is always a small but non-zero chance something could go wrong. Spyder keeps backups of your config file, but you can create one yourself by simply making a backup copy of your config file or your entire config directory (~/.spyder-py3-dev for beta/dev builds) which is a good idea to have anyway.

@rlabbe yes! as @CAM-Gerlach suggested I was indeed asking you to test it to see if it improved your use case. could you please test using the indications by @CAM-Gerlach ?

Cheers

As far as I'm aware the solution to use Tab instead of Enter have not been picked.
I'm using Spyder 4.1.3 (with Kite on and off too) and I'm quite confused that using Enter is making the Editor to pick to top suggestion from autocompletion list.
All of those combinations will do this: Tab, Enter, Ctrl+Enter.
I think Tab should be the only one possible option to use autocompletion.
Is there a way to change this behaviour somehow? Maybe by settings or even by changing the code at some source file and building the IDE with those changes.

So you'd prefer to use Enter to do what exactly? I'm just asking to understand your use case.

Correct me if I'm wrong but I believe the user is asking to make only Tab select completions, presumably so they do not accidentally select the top autocompletion item if they press Enter while typing.

Ok, then that's a duplicate of #12728 then. Let's continue the discussion over there.

Was this page helpful?
0 / 5 - 0 ratings