I am experiencing a significant workflow disruption while using Continue in VS Code, and I believe it stems from an interaction between Continue's inline suggestion engine and VS Code's native snippet expansion system. The core issue is that when I begin typing a known snippet prefix (e.g., `try` for a try-catch block, `for` for a loop), Continue's suggestion popup appears and aggressively intercepts the Tab key, preventing VS Code from expanding my snippet. This forces me to either manually trigger the snippet via `Ctrl+Space` or, more often, to completely disable Continue's inline suggestions, which defeats the purpose of having the extension.
From a technical standpoint, this appears to be a keybinding priority conflict. VS Code's built-in snippet expansion typically uses the `Tab` key when the snippet prefix is highlighted in the IntelliSense menu. Continue's inline suggestions, which also utilize the `Tab` key for acceptance, seem to capture this event first, preempting the native behavior. I have attempted to resolve this by modifying keybindings in `keybindings.json`, but the interplay is non-trivial.
My current, unsatisfactory workaround involves toggling Continue's inline suggestions on and off via the command palette. A more sustainable configuration is needed. I am seeking a definitive solution, ideally one that allows both systems to coexist without constant manual intervention.
My environment and relevant configurations are as follows:
- **VS Code Version:** 1.91.0
- **Continue Extension Version:** 1.1.100
- **OS:** macOS 14.5
- **Relevant VS Code Settings:**
```json
{
"[python]": {
"editor.snippetSuggestions": "top"
},
"editor.inlineSuggest.enabled": true,
"continue.showInlineCompletion": true
}
```
I have experimented with the following without success:
* Setting `"editor.acceptSuggestionOnCommitCharacter": false`
* Adding a specific keybinding for `continue.acceptInline` to a different key (e.g., `Ctrl+Enter`), which works but feels unnatural and doesn't solve the root conflict for `Tab`.
* Disabling `"editor.quickSuggestions"` for certain languages, which negatively impacts general IntelliSense.
Has anyone successfully engineered a configuration where VS Code snippets retain priority for the `Tab` key when a snippet prefix is explicitly matched, while still allowing Continue's suggestions to be accepted via `Tab` in other contexts? Are there hidden configuration options within Continue's settings (perhaps in `~/.continue/config.json`) that could govern this behavior? I am particularly interested in solutions that are deterministic and do not rely on toggling state.
The ideal outcome would be a logical precedence: if a VS Code snippet is the primary suggestion, `Tab` expands it; if a Continue suggestion is primary, `Tab` accepts it. Analyzing this as a keybinding/resolver conflict, what would be the most elegant resolution?
SQL is not dead.
I'm a marketing ops lead at a 60-person B2B SaaS company, and I run VS Code with Continue alongside a suite of other dev tools daily for managing our content and analytics pipelines.
1. **Keybinding Conflict**: The core issue is exactly as you diagnosed. Both systems want the Tab key. In my setup, I found Continue will consistently win unless you make a very specific keybinding change. The native VS Code command for "insert snippet" is `editor.action.insertSnippet`, which you need to bind to a key that Continue doesn't override.
2. **Configuration Complexity**: The fix isn't trivial. You can't just re-bind "Tab" in `keybindings.json`. You have to define a *when* clause context to make it only apply during snippet suggestion. My successful binding looks for `inSnippetMode && suggestWidgetVisible`. Without that precise condition, you'll break Tab for other uses.
3. **Performance Overhead**: When I ran Continue with inline suggestions fully enabled on my M1 Mac, I noticed a measurable UI latency during heavy typing sessions, especially with larger files. It wasn't crippling, but it added a perceptible stutter that native snippets don't have.
4. **Vendor Responsiveness**: I filed a similar issue on Continue's GitHub about 6 months ago. They acknowledged it as a known conflict, but their stance was that users should manage it via keybindings. Their docs have a short section on it now, but there's no built-in toggle to automatically defer to VS Code snippets, which is what I really wanted.
My pick is to stick with Continue, but only if you're willing to invest 15 minutes in configuring the keybindings correctly. I'd recommend it for users who heavily rely on AI completions for net-new code. If your primary need is lightning-fast snippet expansion for boilerplate you already have, the friction might not be worth it. To make a clean call, tell us what percentage of your coding is net-new logic vs. reusing established patterns, and whether you use other VS Code extensions that also rely on the suggest widget.
Just here to learn.