I generally enjoy using Cursor, but there are two things that are almost driving me to look for a different solution:
(1) The tab-completion suggestions are often rendered in such a way as to make them very difficult to distinguish from the surrounding code, particularly when the completion is to a long line or to a multi-line block. The annoying rendering falls into two general categories:
Note: I am in “dark” mode.
(1a) Long lines with a tab completion suggestion render the suggestion near the right edge of the pane, making it difficult to even see what the tab completion is.
(1b) Suggestions sometimes render as large changes around single letters of an existing line. For example, imagine the capitals are the original line: x fOr y iN somEvariable …
Basically, the completions are too similar to the existing code and my eye cannot easily and quickly distinguish the completion/suggestion from the existing code.
(2) For languages like Python, indentation is a core part of the language. Therefore, if I place my cursor at the beginning of a line with the intention to hit tab to indent the line, it’s annoying to have cursor offer a suggestion that takes precedence over the indentation task. Perhaps assigning a special key to the indentation function would be a solution. I think I’d rather assign something like option or command-tab to the AI completion function.
I’d love to be able to assign a highly visible background or some other rendering modification for AI tab completions, to make them more visible … maybe even a thin border around the completion region?
I’m not a vscode guru, so there may be ways to address all of this, and I’m all ears… Thanks in advance!
Ok … I found Command+] is the “always indent” keymap … I can learn the muscle memory for that, but that doesn’t change my opinion about the tab behavior for cursor ai suggestions.
I think I’d rather have tab do normal indenty and editor things and assign a special key to accepting cursor ai suggestions PLUS make those suggestions much more visible.
About the Tab key: Good news: you can now remap Accept Cursor Tab to a different key. Open Keyboard Shortcuts (Cmd+K Cmd+S) and search for Accept Cursor Tab Suggestions, then assign any key instead of Tab. You also mentioned Command+] for indentation, that’s the standard VS Code shortcut.
About suggestion visibility: To help us narrow this down, could you share:
Screenshots of specific cases where suggestions are hard to see (especially long lines and multi-line blocks)
Which theme you’re using
Your Cursor version (Help > About)
Which extensions you have installed (especially theme or color-related ones)
Also try temporarily disabling extensions (cursor --disable-extensions from the command line) and see if visibility improves.
Thanks for the quick reply! I will try that suggestion. I searched for “theme” in the Cursor settings and only “Themed Diff Backgrounds” comes up. Please guide me as to what exact theme information would be helpful to you…
So, that’s an example of a completion suggestion that looks exactly like normal text in the editor, just offset to the right. I type/work very quickly, and this kind of thing slows me down because there aren’t enough visual context clues to differentiate this as a suggestion rather than actual text that ended up in the wrong spot
… so my reflex is to sometimes hit goto-end-of-line and then return; or if this line were a little longer, the spacing between the suggestion and the existing code would be smaller and if my cursor was at the p in print(), trying to indent the line, I may not notice it’s a completion and tab ends up replacing the code instead of indenting…
… and here’s an example of a completion that I can’t tell if it’s coming from Cursor’s Pyright, ms-python, or cursor’s AI. There’s no way to get rid of this very long suggestion that is basically polluting my ability to read the code (it pushes the rest of the line out of visbility). Pressing ESC on the line doesn’t make it go away. Attempting Command-. results in “no code actions available.” Attempting “editor.inlineSuggest.showToolbar”: “always” doesn’t change the behavior etc etc…
UPDATE: Disabling Anysphere/Cursor Pyright makes those suggestions go away. Further, it seems these are disabled by disabling “Cursorpyright › Analysis › Inlay Hints: Generic Types Whether to show inlay hints on inferred generic types.”
Would you please provide a mechanism to at least be able to decline the suggestions and/or make them go away so we can read the file’s text? It’s a bit crappy to have a bunch of disabled text you can’t affect, all over your code – it looks like the suggestion is already shortened with an elipsis, but it’s not short enough, it’s not reactive to the available screen real estate, and I haven’t found a way to decline it…
UPDATE2: So I’ve been reading up a bit more and it seems that “inlays” come from an LSP while “suggestions” are a different mechanism entirely (related to Command-. etc). I guess inlays are explicitly not part of the text and have behaviors defined by vscode not the LSP. ChatGPT suggests binding a key to editor.action.toggleInlayHints to be able to quickly turn them on/off.
I think perhaps the interactions between the defaults for Pyright and Cursor AI’s code completions is what’s been driving me nuts, particularly when they overlap.
This is another example along the same vein, but where the suggestion is “far” from the cursor, which highlights how the styling congruence between existing and suggested text can be quite confusing.
… and here is an example of the kind of completion rendering that IMHO should be avoided completely. A heuristic should prefer [all grey]lowest_status() vs [mixed grey]west_status()
… or these, where the completion is the [‘name’] and the category after id: { …
… and where (hard to see) the completion in the second image is for the first line, but appears on the second line, and extends beyond the right edge of the editor pane (its right edge is just beyond the .get on the first line). Normally, completions wrap, I think it obscures what’s being replaced (on the second line).
Perhaps some experimentation with completion display methods is warranted. For long completions, it may work better to show these in a repositionable floating panel initially positioned in whitespace near and prior to the code block being replaced (which would avoid obscuring any text being replaced). Some form of highlighting (a thin border? lighter background?) would also be very helpful–in cases like this the completion really does get lost within the existing text of the file.
I might have been wrong; long line completions on single lines also overrun the editor pane. It’s subtle in these screenshots (look for the faint vertical line intersecting “what”).
If the completion is already essentially a floating pane (modal), I’m thinking it actually may be really nice to have it always display somewhere relative to the cursor as a copy of the current line’s continuation with changes highlighted.
E.g., I might set this to be up and to the right of the insertion cursor. A constant position of the completion relative to the cursor would allow for much faster scanning while typing IMHO.
… and here’s a case where a completion is offered under a multi-cursor, but accepting the completion with tab affects only the first cursor.
I can think of multiple ways to handle multi-cursors relative to completion, but none of them are this one. I’d rather disable completions during multi-cursor. After all, multi-cursor implies you are editing something with identical prefix structure and identical goal structure.
… and here’s a case where the “state” is greyed out by Pyright as a warning that it’s never used in the function, but the next line, which is in the exact same style, is a completion suggestion. Real text needs to be styled so as to consistently be different from suggested text (completions, annotations, LSP inlays, etc) …
In combination with completion text not having a consistent positional relationship to the cursor, you otherwise have no idea if what you are looking at exists in the file or not. You have to make a cursor excursion to the word state to probe whether it’s actually there.
… and here is a case where the completion is for something PRIOR to the cursor! Note the connection here with a prior reply of mine where I point out that a Pyright styling of non-completion text (the word “state” in that other screenshot) prior to the cursor uses identical styling to suggested text, thus causing the programmer to have no idea if the styled text exists or is suggested!
What is natural to do here, for a python programmer, is to hit tab to get to the indentation level necessary to continue coding. However, if the completion showed up just after the last time you’ve looked up at the screen, you end up with an inserted change ABOVE where you’re typing. I’ve missed this before, and ended up with changes I didn’t mean to accept.
Or this case, where the completion is way below and to the right, instead of offering (what would be a very similar) completion at the line where the cursor is.
I think offering single-line completions anywhere but on the line that the cursor is on, should be avoided, unless there are completions on the line below the cursor.
Ah, perhaps cursor is suggest that all of the lines between the cursor and the suggestion will be removed, in favor of the suggestion–can’t remember if in that case Cursor greys out the intervening text. If not, then perhaps it should (or it should be styled with a strikeout, in such cases…).
… and in cases like this one, the completion rendering beyond the borders of the editor pane leads to almost completely invisible completion suggestion, when the agent/chat pane is closed, and the entire Cursor window is the editor pane …
Or this case, where the cursor was originally to on column 0, and I was in the process of pushing tab 3 times in order to get to the correct indentation level to begin typing. This is typically done in rapid fire pushing the tab key.
However, before getting to the desired position, Cursor snaps in a completion upon the second tab push, and the third tab push accepts the completion … again, potentially silently inserting the completion.
… it’s becoming clear that for indentatation-is-structure languages, putting AI completions onto the tab key may be a very bad idea.
Thanks for such detailed feedback with examples! This is really valuable info for the team.
About the visibility of Tab suggestions: this is a known issue, and the team is aware. Unfortunately, there aren’t any settings right now to change the contrast or the suggestion display style. Your examples clearly show where the current visuals cause problems.
On the multi-cursor behavior, there are similar topics, like this one:
This appears to be new behavior. In this case the completion is offered in a box. The box is still being rendered “partially off pane.” What you’re seeing there is the right edge of the Cursor window (after the <div), the white behind it of another window, etc.
I don’t think I saw anything like this before, so perhaps the team has implemented something along the suggestions I’ve made. However, when using magic mouse scroll movements, swiping left over the completion text box, the text scrolls left only a little … it’s still NOT possible to get a view of the full completion by scrolling.
Can you tell what’s a completion on this line? I can’t. Turns out most of the line, starting from immediately after the cursor, is a completion.
Seriously, one of the most flow breaking aspects of cursor (for me) is how often I can’t tell wtf is the actual text that already exists, and whether it’s worth pressing tab and editing out the parts I don’t want or hitting ESC and adding the parts I need manually.
Can I perhaps at least set a different “theme” or at background color for all completion text?
