This document tracks planned work toward a contributor-ready, shippable editor.
Status labels: Planned, Half-implemented, In progress, Done. Link GitHub issues next to items when they exist.
For how to contribute, see CONTRIBUTING.md.
Status: Planned
Goal: Publish installable Release builds for Linux and macOS (x86_64 and arm64 where applicable).
Current baseline: Source-only builds documented in BUILD.md. CI (.github/workflows/cpp-lint.yml) builds and smoke-tests on Ubuntu only; no tagged releases or installers.
Primary touchpoints:
cmake/— install rules, optional CPack or platform packaging scripts- New
.github/workflows/release.yml— matrix build, artifacts, GitHub Releases on tags - BUILD.md — packaging section (AppImage/deb/tarball on Linux;
.app/dmg on macOS) - Version source — CMake project version or tag-driven
VERSIONfile
Acceptance notes:
- Release binaries built with
-DCMAKE_BUILD_TYPE=Release - Document runtime deps (Qt, optional
libvterm, tool paths) - Smoke test packaged binary under
QT_QPA_PLATFORM=offscreen
Dependencies: None (foundational for wider adoption).
Status: Planned
Goal: VS Code–style Git source control in the activity sidebar, consolidating status, staging, commit, and diff entry points.
Current baseline:
- Git menu actions and explorer context menu in
MainWindow - Status badges via
FileExplorerDelegate PanelId::Gitexists but is not registered inSidebarWidget(only Explorer and Search today)
Primary touchpoints:
- New
GitPanelWidgetundersrc/git/(orsrc/project/) MainWindow::setupSidebar—m_sidebar->addPanel(PanelId::Git, ...)GitService— signals for panel model refreshsrc/git/CONTEXT.md
Acceptance notes:
- Activity bar icon opens Git panel; panel shows repo state when project has
.git - Replaces or supplements menu-only Git workflow without regressing explorer badges
Dependencies: None for panel shell; pairs with selective staging and colored diff below.
Status: Planned
Goal: Checkbox or multi-select UI to stage/unstage specific paths (not only whole-file context menu).
Current baseline: GitService::stagePaths from explorer context; commit dialog lists all index-staged files from porcelain.
Primary touchpoints: Git panel file list model, git add / git reset (or restore --staged) per path, GitCommitDialog.
Acceptance notes: Stage/unstage selected paths; staged list updates before commit.
Status: Planned
Goal: Safe UX for undoing the last commit (e.g. soft/mixed reset) with clear warnings.
Current baseline: Not implemented.
Primary touchpoints: GitService new operations, Git panel actions, confirmation dialogs.
Acceptance notes: Document destructive behavior; refuse or warn on dirty/unpushed edge cases as appropriate.
Status: Planned
Goal: Syntax-colored, readable diffs (hunk headers, additions, deletions) instead of plain monospace text.
Current baseline: GitDiffDialog — split QPlainTextEdit panes, 5000-line cap, no theme-aware colors.
Primary touchpoints: GitDiffDialog or inline diff view in Git panel; reuse HighlightTheme scopes or a small diff lexer on QTextDocument.
Acceptance notes: Colors respect light/dark editor theme; truncation banner unchanged or improved.
Status: Planned
Goal: On Linux, combine window title, menu, and toolbar into one custom title region (Zed-style), reducing vertical chrome.
Current baseline: Native title bar + QMenuBar + run/toolbars.
Primary touchpoints: MainWindow, platform #ifdef Q_OS_LINUX (or similar), custom title widget / optional Qt::FramelessWindowHint with in-window controls.
Acceptance notes: macOS can keep native chrome initially; Linux menus/shortcuts remain reachable.
Dependencies: Independent; coordinate with status bar layout.
Status: Planned
Goal: Built-in provisioning and registry entries for the most common languages beyond C/C++ and JS/TS.
Current baseline: LspRegistry — clangd, typescript-language-server; resources/lsp/manifest.json.
Primary touchpoints:
LspTypes.h— extendLspLanguageKind,languageKindFromPathLspProvisioner,LspArtifactStoresrc/lsp/CONTEXT.md, BUILD.md per-server notes
Phased expansion:
| Phase | Servers | Notes |
|---|---|---|
| A | Python (pyright or pylsp), Rust (rust-analyzer), Go (gopls) | Manifest + download pattern like clangd |
| B | JSON/YAML, HTML/CSS | Often npm-based bundles like TypeScript |
| C | Shell, Markdown, Dockerfile | Lighter servers or PATH fallback with COLD_LSP_ALLOW_PATH |
Each server needs: registry id, extension map, manifest platform URLs, provisioner job (or npm bundle), and documentation in BUILD.md.
Acceptance notes: Open supported file → server starts (or cache hit) → completion/diagnostics/semantic tokens where server supports them; unsupported extensions stay silent.
Dependencies: Manifest/provisioner infrastructure; benefits from syntax/theme improvements.
Status: Planned
Goal: Richer semantic colors and more reliable hover tooltips (textDocument/hover).
Current baseline:
textDocument/semanticTokens/full→HighlightService- Hover debounced 400 ms in
MainWindow→LspClient::requestHover HighlightThemescope mapping
Primary touchpoints:
SemanticTokenDecoder,HighlightThemeEditorWidget— tooltip markdown rendering, stale hover drop- Future:
semanticTokens/rangeor delta for large files (see AGENTS.md)
Acceptance notes: Hover shows formatted markdown when server returns it; token colors align across editor, problems, and diff where applicable.
Dependencies: Overlaps with LSP expansion and theme work.
Status: Planned
Goal: Cohesive light and dark UI beyond the editor buffer (explorer, sidebars, panels, terminal ANSI, diff, dialogs).
Current baseline: EditorSettings::applyTheme — editor.theme dark/light/system for QApplication palette.
Primary touchpoints: EditorSettings, FileExplorer, SidebarWidget, PanelRegion, VtermTerminalWidget, GitDiffDialog, status bar widgets.
Acceptance notes: System theme follows OS when set; no black-on-black in terminal or diff views.
Dependencies: Helps git diff colors and status bar readability.
Status: Planned
Goal: Persistent status widgets (not only ephemeral showMessage).
Current baseline: Default QStatusBar in MainWindow.
Primary touchpoints: New StatusBarWidget or structured permanent widgets — project name, git branch, LSP state, cursor line/col, dirty indicator, runner busy.
Acceptance notes: Key editor state visible without triggering transient messages.
Dependencies: Git panel/branch info; LSP provisioning state signals already exist on LspClient.
Status: Planned
Goal: Open terminal in editor panes with splits and tab drag, like editor files—not only the bottom/right panel region.
Current baseline:
- Terminal in
PanelRegiononly TerminalPaneItemimplemented but not wired fromMainWindow/LayoutTree
Primary touchpoints:
LayoutTree,DocumentManagerorMainWindow— createTerminalPaneItemin panelayout_stateJSON — persist terminal tab placementsrc/terminal/CONTEXT.md,src/layout/CONTEXT.md
Acceptance notes: Split editor + terminal side-by-side; tab drag between panes; cwd restart on project open unchanged.
Dependencies: Panels/splits/tab drag improvements.
Status: Planned
Goal: Reliable run/build for JS, TS, C, C++ with clear errors, cancel, and Output panel UX.
Current baseline: CodeRunner, ToolChainResolver, F5 / Ctrl+F5 / Stop.
Primary touchpoints: src/run/, OutputPanel, tool_paths in settings, AGENTS.md language matrix.
Manual test matrix (document for contributors):
| Extension | Normal run | Without build | Missing tool |
|---|---|---|---|
.js |
node | — | hint in Output |
.ts |
tsc + run / ts-node | node sibling .js |
hint |
.c / .cpp |
compile to /tmp/cold-build/.../cold-out |
run existing binary | hint |
Acceptance notes: Untitled buffer blocked; cancel kills process and cleans temp dir; exit code in status/Output.
Dependencies: Optional automated tests when COLD_BUILD_TESTS is wired.
Status: Half-implemented
Goal: Smoother layout UX: predictable split drops, tab reorder across panes, clear panel vs editor-pane roles.
Implemented today:
- Custom split tree (
LayoutTree,LayoutNode) with menu-drivensplitPane(View → split commands viaDocumentManager) - Cross-pane tab drag:
PaneTabBarMIME drag →tabMoveRequested→LayoutTree::moveItem - Within-pane reorder via
QTabBar::setMovable(true) - Session persistence:
layout_stateJSON inDocumentManager::captureLayoutState
Still open (why this stays half-implemented):
DropOverlayexists but is not wired — no drag-to-split preview or drop zones on panes- Dragging a tab onto a pane edge to create a new split (VS Code–style) is not end-to-end
PanelRegion(Terminal / Output / Problems) vs editor-pane tabs remain separate concepts; unified drag rules pending- Terminal-as-tab and non-editor
PaneItemtypes are not part of the drag story yet
Primary touchpoints: src/layout/, DocumentManager, MainWindow (split commands), future DropOverlay integration.
Acceptance notes:
- Drag tabs between panes and splits (including split-on-drop where overlay defines zones)
- Terminal/editor tabs follow same rules when terminal-as-tab lands
- Session restore matches saved layout JSON after drag/split operations
Dependencies: Terminal-as-tab for full tab-type parity; Git panel does not block layout work.
- Pick an item marked Planned (or a scoped slice of a Half-implemented item — see below).
- Open a GitHub issue describing scope, what already exists, and acceptance notes from this file.
- Assign the issue to yourself and start working.
- Read CONTRIBUTING.md and the module
CONTEXT.mdbefore coding. - When an item is fully complete, change its status to Done and link the PR/issue in the section header.
Use Half-implemented when core plumbing exists but acceptance notes are not fully met. These are good contribution targets if you finish the missing wiring rather than redesigning from scratch.
Before you code:
- Read the section’s Implemented today and Still open lists (or equivalent baseline notes).
- Confirm in the tree which files already implement partial behavior — avoid duplicating
LayoutTree,PaneTabBar, etc. - Scope your issue to a single gap when possible (e.g. “wire
DropOverlayto pane drag” rather than “fix all layout UX”).
While working:
- Prefer extending existing types (
PaneTabBar,LayoutTree::moveItem,DropOverlay) over parallel drag systems. - Update
src/layout/CONTEXT.mdwhen behavior or ownership changes. - Manual test: split via menu, drag tabs across panes, save project, restart — layout JSON should match expectations.
When to change status:
| Situation | Status |
|---|---|
| Only documenting gaps; no code change | Keep Half-implemented |
| Active PR in flight | In progress (optional; link issue) |
| All acceptance notes in the section met | Done |
| Large item partially improved but acceptance notes remain | Stay Half-implemented; list what landed under Implemented today in the PR |
If you complete a half-implemented item, merge the Still open list into history (or delete it) and move shipped bullets under Implemented today so the next contributor sees an accurate baseline.