Skip to content

TuiCode's editor won't get Terminal.Gui's editing improvements: it's built on the TextView that 2.5 retires #468

Description

@jamescrosswell

Opportunity

The editor is where a TuiCode user spends the day. It's built on Terminal.Gui's TextView, which 2.5 marks obsolete in favour of Terminal.Gui.Editor. Users feel that in three ways:

  • What they'd get, they don't. Terminal.Gui's editing work now goes into Editor. It folds code (TuiCode can't; see In a long file I can't put away the parts I've read, so the code's shape is spread over screens of bodies #477), keeps a rope-backed document, and tracks line widths as you type. TuiCode reaches none of it.
  • Upgrades put typing at risk. To get multiple cursors, undo, wrapping and a usable frame rate out of TextView, TuiCode reaches into its private fields. Those are the caret fields AtEachCaret loads, the width cache (through [UnsafeAccessor] and reflection), and List<T>._version. It also keeps a copy of TextView's draw loop. Any Terminal.Gui release can rename them, and then every keystroke throws. The 2.5 move (Move TuiCode to Terminal.Gui 2.5 and MentalDesk.Tui 0.2.0 #442, Move TuiCode to Terminal.Gui 2.5 and MentalDesk.Tui 0.2.0 #472) has already broken the Text override that resets undo when a file reloads, and Windows tests failed.
  • Fixes have stopped. An obsolete control doesn't get bug fixes. The unbounded draw loop, the width cache thrown away on every edit, the kill commands that throw on a selection, and the unreliable ContentsChanged all stay TuiCode's to work around.

Nobody is blocked today. The cost is what doesn't arrive (folding, sticky lines on a real document model) and the chance that the next upgrade breaks editing.

What Editor is today (checked 2026-10-09):

  • 2.5.7 is on NuGet and built against Terminal.Gui 2.5.0. Its beta work is done: multi-caret, vertical carets, grouped undo, word wrap, folding, find and replace, configurable keys. plan.md
  • Highlighting is xshd only. TextMate is "post-beta" with no code yet, but highlighting plugs in through IVisualLineTransformer, and TuiCode's LineTokenCache doesn't depend on Terminal.Gui.
  • It doesn't set IsAotCompatible. A throwaway PublishAot app that builds an Editor with C# highlighting compiled with no trim or AOT warnings. The local link step failed for an unrelated reason, so I haven't run it as a native binary.
  • It has no column (box) selection: #139 and PR Keyboard Shortcuts: show every scope and check conflicts per scope #142 are open. Its default keys are unchecked on macOS (#252).
  • It's a small project (19 stars). The last release was in July and the last commit in September.

Options considered

  1. Stay on TextView and revisit later. Costs nothing now, and the 2.x warning is soft. But every upgrade keeps the same risk, and folding (In a long file I can't put away the parts I've read, so the code's shape is spread over screens of bodies #477) would have to be built on a control nobody maintains.
  2. Build folding on TextView ourselves. Gets In a long file I can't put away the parts I've read, so the code's shape is spread over screens of bodies #477 without the move, but adds a third layer of rows we draw ourselves over an obsolete base, so moving later costs more.
  3. Swap the editor in one PR, tried before it merges (your call). One switch, no two editors side by side, no setting to remove later. The PR is large (EditorTextView's partials are about 1,500 lines, and EditorTab is tied to them), but you try the branch as your daily editor before merging, and if Editor falls short the PR is closed and nothing on main changed.
  4. Move over behind an opt-in preview. Two editors in the tree for a while, a setting, and three PRs. You'd rather test the switch on a branch. Dropped.

Proposing 3.

Proposal

Editor tabs are built on Terminal.Gui.Editor instead of TextView. Nothing a user does in an editor tab today changes:

  • Typing, selection, cut/copy/paste (through VerifiedClipboard and OSC 52 as today), undo and redo, Save, dirty marks, reload from disk, and the find bar.
  • TuiCode's TextMate colours and themes, through an IVisualLineTransformer over LineTokenCache.
  • The gutter: line numbers, git change marks, and links (Follow link opens the URL under the cursor in the browser, or copies it over SSH #466).
  • Wrap long lines, and wrap by language.
  • TuiCode's multiple cursors (add cursor above/below, select occurrences, move and duplicate lines), column select, kitty's cursors, and review threads and draft comments in the editor.
  • Every editor command and keybinding, still owned by TuiCode's keybindings.

EditorTextView, its TextView workarounds (the copied draw loop, the width-cache accessors, the caret reflection, the kill-command and ContentsChanged fixes) and the AGENTS.md notes about them are deleted, which clears the TextView is obsolete warnings in #487. A large file (50,000 lines) types and scrolls at least as fast as today.

Mockup

No new UI: an editor tab looks as it does today.

 12   public sealed class EditorGroup
 13   {
 14       public void Track(EditorTab tab)
 15       {
 16 ~         _tabs.Add(tab);
 17       }
───────────────────────────────────────────────────────────
 Ln 16, Col 9   C#   LF   UTF-8

Scope

In: every editor tab on Terminal.Gui.Editor, at parity with today; the old editor and its workarounds removed; a native-binary smoke check that opens an editor tab.

Out:

Delivery

One PR, as you asked. It's well past the usual size for one sitting, so the PR description will list what to try, and you try the branch before merging.

Assumed

Original idea

Opportunity

Terminal.Gui's work on editing now goes into Terminal.Gui.Editor, not TextView. That work includes a rope-backed document, folding, and better performance on large files. TuiCode's editor is built on TextView, so it gets none of it. It also keeps carrying its own workarounds for TextView's bugs, and each upgrade can break them. The upgrade to 2.5 has already turned up another one.

Evidence

  • EditorTextView (src/TuiCode.Editor) derives from TextView, which Terminal.Gui 2.5 marks obsolete in favour of Terminal.Gui.Editor.
  • AGENTS.md lists workarounds for 2.1's TextView:
    • a copy of its draw loop, stopped at the bottom of the viewport;
    • the content-width cache, reached through [UnsafeAccessor] and reflection (about 225 ms per typed character at 50,000 lines without it);
    • kill commands that ignore a selection and then throw;
    • ContentsChanged raised unreliably.
  • Move TuiCode to Terminal.Gui 2.5 and MentalDesk.Tui 0.2.0 #442 found another break. View.Text isn't virtual in 2.5, so EditorTextView's Text override no longer compiles. That override resets undo, extra carets and auto-indents when a file reloads.
  • What Terminal.Gui.Editor has (tui-cs/Editor, NuGet 2.5.7, needs Terminal.Gui 2.4.17 or later): a rope-backed document, multiple carets, grouped undo, word wrap, folding (TuiCode has none), find and replace, and extension points (IVisualLineTransformer, IBackgroundRenderer) for layering behaviour on top. It still calls itself alpha.
  • What a move would have to keep:
    • TextMate-grammar highlighting. Editor's highlighting is xshd-based, and TextMate support is after its beta.
    • The git gutter, the diff tab, and review threads and draft comments in the diff.
    • Column selection, wrapping by language, and TuiCode's own multiple cursors.
    • A single native AOT binary. Editor's README doesn't say whether it's AOT-safe.
  • It depends on Move TuiCode to Terminal.Gui 2.5 and MentalDesk.Tui 0.2.0 #442. TuiCode can't reference Terminal.Gui.Editor until it's on Terminal.Gui 2.4.17 or later.

Why it fits

The editing surface is the product: "a terminal code editor you can use all day without reaching for another one". Folding and large-file performance are the kind of daily-driver gaps theme 1 is about. "Fast and self-contained" and "the smallest version that's actually useful" are the bars a pitch has to clear: AOT, start-up time, and whether there's a step short of replacing the whole editor.

Activity

  1. added
    pitchAn a-team pitch: Lead shapes it, reviewer approves it
    on Oct 8, 2026
  2. a-team-app commented on Oct 9, 2026

    @a-team-app
    Contributor

    Pitched now: it's Urgent, so it takes #128's slot.

    Changed since drafting:

  3. jamescrosswell commented on Oct 10, 2026

    @jamescrosswell
    ContributorAuthor

    Don't bother with preview - just switch to the new control in a PR where we can test it before merging.

  4. a-team-app commented on Oct 10, 2026

    @a-team-app
    Contributor

    Done: no preview. Rewritten as one PR that swaps editor tabs onto Terminal.Gui.Editor at parity with today, deletes EditorTextView and its workarounds (clears #487's warnings), and you try the branch before merging.

    One call I made: folding stays out to keep the PR to parity; it's a small follow-up (#477) once this merges. Say if you want it in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pitchAn a-team pitch: Lead shapes it, reviewer approves it

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions