## Feature Request: Context-Aware Completion Modes for Faster Auto-Completion #1915

Problem

Currently, mycli performs auto-completion against all possible candidates globally — keywords, table names, column names, functions, aliases — regardless of the user's current intent. In databases with hundreds of tables and thousands of columns, this leads to:

• Noticeable lag when triggering completion
• Noisy suggestion lists that include irrelevant candidates
• Wasted keystrokes — users often think "table first" (e.g., job_position) but must type SELECT ... FROM ... before table/column completion becomes useful

Proposed Solution

Introduce manual completion modes (or contexts) that narrow the candidate scope:

\mode query     # tables, columns, SELECT/DML keywords only
\mode alter     # DDL keywords, constraints, column types
\mode monitor   # SHOW, STATUS, EXPLAIN, PROCESSLIST, etc.

Each mode would restrict auto-completion to a relevant subset, significantly reducing:

• Candidate lookup time
• Visual noise in the suggestion menu

Alternative / Simpler Approach

If explicit mode switching is too heavy, consider a lighter-weight option:

• completion_scope config in .myclirc:

  completion_scope = dml    # only tables/columns/DML keywords
  completion_scope = ddl    # only DDL keywords/constraints
  completion_scope = all    # current behavior (default)

• Hotkey to toggle scopes at runtime (e.g., Ctrl-T to cycle through modes).

Use Case

A developer frequently switching between:

• Writing SELECT queries (needs tables and columns)
• Running SHOW PROCESSLIST / EXPLAIN
• Modifying schema with ALTER TABLE

Each context benefits from a different, smaller set of completions.

Related Issues / Prior Art

• smart_completion already attempts keyword-aware narrowing, but still scans all schema objects.
• GUI tools like DataGrip and DBeaver provide context-aware completion out of the box.

Desired Outcome

Faster, more focused auto-completion with less cognitive overhead, especially for users working with large schemas or frequently switching SQL contexts.