Tab Completion & Predictions

Traditional autocomplete (IntelliSense in VS Code) suggests variable names, function names, and language keywords based on static analysis. Cursor's tab completion is fundamentally different:

Traditional autocomplete:

• Suggests known symbols (variables, methods, imports)
• Based on language server analysis
• Typically completes a single token or identifier
• Deterministic — same context always gives same suggestions

Cursor Tab (AI autocomplete):

• Predicts what you'll type next based on context and intent
• Uses an AI model trained on code patterns
• Can suggest entire lines or multi-line blocks
• Understands natural patterns, not just syntax
• Adapts to your coding style and the current file's patterns

What this looks like in practice:

When you type function validate in a file that already has other validation functions, Cursor might predict the entire function body — not just the function name, but the parameters, the logic, and the closing brace.

The prediction appears as ghost text — grey, semi-transparent text ahead of your cursor. Press Tab to accept, or keep typing to ignore it.

Cursor Tab is not GitHub Copilot:

While both show ghost text completions, Cursor Tab:

• Uses your full file context more effectively
• Predicts based on recent edits (not just the cursor position)
• Can suggest edits to existing code (not just insertions)
• Works alongside Chat and Inline Edit as part of an integrated system

Cursor's most powerful completion feature is multi-line prediction. Instead of completing one word, it can predict entire blocks.

How multi-line completions appear:

1. You type the beginning of a pattern (e.g., a function signature)
2. Ghost text appears showing multiple predicted lines
3. All ghost text is grey/dimmed to distinguish from your code
4. The completion may span 2-20+ lines

Accepting completions:

Example scenario — writing a test:

You have a function calculateTotal(items) in your project. In a test file, you type:

test('calculateTotal

Cursor predicts:

test('calculateTotal returns sum of item prices', () => {
  const items = [
    { name: 'Widget', price: 9.99 },
    { name: 'Gadget', price: 14.99 },
  ];
  expect(calculateTotal(items)).toBe(24.98);
});

Press Tab and the entire test is written for you.

When multi-line completions work best:

• Writing tests for existing code
• Implementing functions that follow established patterns
• Creating data structures similar to existing ones
• Writing repetitive code (routes, handlers, config)
• Filling in boilerplate (imports, exports, class methods)

Ghost text is the grey preview text that appears as you type. Understanding how it's generated helps you work with it more effectively.

What triggers ghost text:

1. Pausing while typing — after ~300ms of inactivity, Cursor predicts your next move
2. Completing a statement — after a semicolon, closing brace, or newline
3. Starting a new line — especially after patterns like if, for, function
4. Context changes — when you switch to a new logical section of code

What the model considers:

• The current file's content (above and below the cursor)
• Your recent edits in this session
• Other open files in the workspace
• The programming language and framework conventions
• File names and directory structure (hints about purpose)

Ghost text states:

The prediction adapts in real-time:

As you type each character, the prediction updates. If the ghost text shows console.log(result) and you type c-o-n-s, the prediction confirms and you can Tab to accept the rest. If you type r-e-t-u-r-n, the prediction shifts to match your intent.

Partial acceptance:

You don't have to accept the full prediction. Common patterns:

1. Ghost text shows an entire if block
2. You only want the condition, not the body
3. Accept word-by-word using Ctrl+Right Arrow until you reach where you want to diverge
4. Then type your own code — the ghost text updates

Cursor's completions improve as it observes your coding patterns within a session and across your project.

How your behaviour shapes predictions:

• Accepting completions for a pattern reinforces that pattern for future suggestions
• Rejecting completions (typing over them) signals that the model's prediction style doesn't match your intent
• Your recent edits are weighted heavily — if you just wrote three similar functions, the fourth prediction will match the style
• File patterns matter — if every function in the file uses arrow syntax, predictions will follow suit

Techniques to get better predictions:

1. Be consistent in your style — the model picks up on your patterns. If you use const everywhere, predictions will use const.

2. Write clear function signatures first — type the full signature before pausing for the body prediction:

   // Good: gives the model clear intent
   function parseUserInput(raw: string): ParsedInput {
   
   // Less effective: ambiguous
   function parse(x) {

3. Use descriptive variable names — userEmailList predicts more accurately than data

4. Establish patterns early in the file — the first few functions set the template for predictions in the rest of the file

5. Keep related code in the same file — more local context means better predictions

What NOT to expect:

• Predictions won't understand complex business requirements from comments alone
• Very novel logic (no similar pattern in the file) gets less accurate predictions
• Long functions with branching logic may get incorrect continuations
• The model doesn't read your mind — it reads patterns

Not every ghost text prediction should be accepted. Developing judgment about when to use Tab vs when to type is a key skill.

Accept the prediction when:

• It matches exactly what you intended to write
• It's boilerplate or repetitive code you'd have written the same way
• It's a standard pattern (error handling, imports, common algorithms)
• The variable names and logic align with your design
• It's a test that correctly matches your implementation

Type manually when:

• The prediction uses wrong variable names
• The logic is subtly incorrect (wrong condition, off-by-one)
• You want to write something novel that the model can't predict
• The prediction is too long/complex and you'd spend more time reading it than writing
• You're in a section requiring careful thought (security, financial calculations)

The "skim then decide" habit:

Build this habit:

1. Ghost text appears
2. Skim it in 1-2 seconds
3. If it looks right → Tab
4. If it looks wrong → keep typing
5. If it's partially right → accept word-by-word, then diverge

Speed comparison:

You can tune Cursor's tab completion to match your preferred workflow.

Available settings:

Per-language configuration:

If you find completions less useful for certain languages (e.g., they're great for TypeScript but distracting for Markdown), you can disable Tab completion per language:

1. Open Cursor Settings
2. Navigate to Features → Cursor Tab
3. Look for language-specific toggles
4. Disable for languages where predictions are unhelpful

Adjusting the trigger delay:

• Shorter (100-200ms): Predictions appear faster, may feel intrusive
• Default (300ms): Good balance of speed and non-intrusiveness
• Longer (500ms+): Only see predictions when you genuinely pause

If you find ghost text distracting while you're thinking, increase the delay. If you want maximum speed, decrease it.

Disabling temporarily:

Sometimes you want to type without predictions (e.g., writing documentation or novel logic). You can:

• Toggle off in settings (persistent)
• Or simply ignore ghost text — it doesn't interfere if you keep typing