You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orca's core value is managing agent-driven work and reviewing the resulting code changes. I do not think Orca needs to become another VS Code or Cursor.
However, developers still rely on familiar editor workflows when reviewing code or making small fixes:
Consistent syntax highlighting across files and diff views
Symbol context for files, functions, and classes, with navigation to definitions and references
Structural folding for functions, classes, and other scopes
Since Orca already uses Monaco, I propose extending the existing editor and review surfaces instead of embedding another editor.
Proposed capabilities
1. Consistent code rendering
Use the same language detection and syntax highlighting across the regular file editor, Changes mode, single-file diffs, and combined diffs.
2. Lightweight symbol context and navigation
Show the available symbol information through hover or the context menu:
Symbol kind and signature
Definition file and location
References
Inheritance relationships when a semantic provider can resolve them accurately
Provide familiar actions such as:
Peek/Open Definition
Find References
Search in Files as a fallback
When semantic analysis is unavailable, Orca should fall back to workspace search instead of showing misleading or empty results.
3. Structural folding
Fold functions, classes, imports, comments, and other scopes
Provide Fold, Unfold, and Fold All commands
Preserve fold state across file switches where practical
Diff views should never hide changed code without an indicator. If a folded region contains changes, it should be clearly marked, and hunk navigation should automatically reveal it.
Implementation direction
A lightweight, progressive approach seems appropriate:
Monaco-based syntax highlighting and folding
Lazy or on-demand Tree-sitter structural navigation
Optional semantic providers only for languages that need greater accuracy
Providers should start only when a capability is requested and should not index the entire repository during application startup.
Rather than introducing more separate implementations, I suggest consolidating the related work in #5247, #5595, #8574, #961, and #4654 behind a shared capability/provider contract.
Out of scope
Embedding another editor
A VS Code extension host
Always-running language servers
Diagnostics, autocomplete, or debugging in the initial scope
Presenting heuristic results as accurate semantic results
This direction would preserve Orca's focus on agent orchestration and code review while reducing the need to open an external IDE for routine code comprehension.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Orca's core value is managing agent-driven work and reviewing the resulting code changes. I do not think Orca needs to become another VS Code or Cursor.
However, developers still rely on familiar editor workflows when reviewing code or making small fixes:
Since Orca already uses Monaco, I propose extending the existing editor and review surfaces instead of embedding another editor.
Proposed capabilities
1. Consistent code rendering
Use the same language detection and syntax highlighting across the regular file editor, Changes mode, single-file diffs, and combined diffs.
2. Lightweight symbol context and navigation
Show the available symbol information through hover or the context menu:
Provide familiar actions such as:
When semantic analysis is unavailable, Orca should fall back to workspace search instead of showing misleading or empty results.
3. Structural folding
Diff views should never hide changed code without an indicator. If a folded region contains changes, it should be clearly marked, and hunk navigation should automatically reveal it.
Implementation direction
A lightweight, progressive approach seems appropriate:
Providers should start only when a capability is requested and should not index the entire repository during application startup.
Rather than introducing more separate implementations, I suggest consolidating the related work in #5247, #5595, #8574, #961, and #4654 behind a shared capability/provider contract.
Out of scope
This direction would preserve Orca's focus on agent orchestration and code review while reducing the need to open an external IDE for routine code comprehension.
All reactions