Skip to content

Latest commit

 

History

History
316 lines (183 loc) · 13.4 KB

File metadata and controls

316 lines (183 loc) · 13.4 KB

Cold Roadmap

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.


Releases (macOS and Linux)

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 VERSION file

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).


Git refactor (activity bar panel)

Status: Planned

Goal: VS Code–style Git source control in the activity sidebar, consolidating status, staging, commit, and diff entry points.

Current baseline:

Primary touchpoints:

  • New GitPanelWidget under src/git/ (or src/project/)
  • MainWindow::setupSidebarm_sidebar->addPanel(PanelId::Git, ...)
  • GitService — signals for panel model refresh
  • src/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.

Select files to stage

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.

Uncommit

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.

Git diff with colors

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.


Unified Linux titlebar (Zed-like)

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.


LSP for common file types

Status: Planned

Goal: Built-in provisioning and registry entries for the most common languages beyond C/C++ and JS/TS.

Current baseline: LspRegistryclangd, typescript-language-server; resources/lsp/manifest.json.

Primary touchpoints:

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.


Syntax highlighting and LSP hover

Status: Planned

Goal: Richer semantic colors and more reliable hover tooltips (textDocument/hover).

Current baseline:

Primary touchpoints:

  • SemanticTokenDecoder, HighlightTheme
  • EditorWidget — tooltip markdown rendering, stale hover drop
  • Future: semanticTokens/range or 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.


Light and dark themes

Status: Planned

Goal: Cohesive light and dark UI beyond the editor buffer (explorer, sidebars, panels, terminal ANSI, diff, dialogs).

Current baseline: EditorSettings::applyThemeeditor.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.


Better bottom status bar

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.


Terminal as a common tab

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:

Primary touchpoints:

Acceptance notes: Split editor + terminal side-by-side; tab drag between panes; cwd restart on project open unchanged.

Dependencies: Panels/splits/tab drag improvements.


Code runner

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.


Panels, splits, and tab dragging

Status: Half-implemented

Goal: Smoother layout UX: predictable split drops, tab reorder across panes, clear panel vs editor-pane roles.

Implemented today:

Still open (why this stays half-implemented):

  • DropOverlay exists 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 PaneItem types 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.


How to use this roadmap

Starting new work

  1. Pick an item marked Planned (or a scoped slice of a Half-implemented item — see below).
  2. Open a GitHub issue describing scope, what already exists, and acceptance notes from this file.
  3. Assign the issue to yourself and start working.
  4. Read CONTRIBUTING.md and the module CONTEXT.md before coding.
  5. When an item is fully complete, change its status to Done and link the PR/issue in the section header.

Half-implemented tasks

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:

  1. Read the section’s Implemented today and Still open lists (or equivalent baseline notes).
  2. Confirm in the tree which files already implement partial behavior — avoid duplicating LayoutTree, PaneTabBar, etc.
  3. Scope your issue to a single gap when possible (e.g. “wire DropOverlay to 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.md when 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.