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
{{ message }}
Repository navigation
TuiCode's editor won't get Terminal.Gui's editing improvements: it's built on the TextView that 2.5 retires #468
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:
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.
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.
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.
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.
The diff tab (DiffTab), which draws its own rows and isn't a TextView.
Single-line text fields (InputView, the review summary).
Editor's xshd highlighting. TuiCode keeps its TextMate grammars.
Contributing upstream. Where Editor lacks something (column select), TuiCode builds it on Editor's extension points.
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
Folding waits for a follow-up. Keeping this PR to parity keeps it reviewable, and folding on Editor is then small. Say if you want it in this PR.
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;
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.
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.
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.
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:TextView, TuiCode reaches into its private fields. Those are the caret fieldsAtEachCaretloads, the width cache (through[UnsafeAccessor]and reflection), andList<T>._version. It also keeps a copy ofTextView'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 theTextoverride that resets undo when a file reloads, and Windows tests failed.ContentsChangedall 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):
IVisualLineTransformer, and TuiCode'sLineTokenCachedoesn't depend on Terminal.Gui.IsAotCompatible. A throwawayPublishAotapp that builds anEditorwith 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.Options considered
TextViewand 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.TextViewourselves. 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.EditorTextView's partials are about 1,500 lines, andEditorTabis 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 onmainchanged.Proposing 3.
Proposal
Editor tabs are built on Terminal.Gui.Editor instead of
TextView. Nothing a user does in an editor tab today changes:VerifiedClipboardand OSC 52 as today), undo and redo, Save, dirty marks, reload from disk, and the find bar.IVisualLineTransformeroverLineTokenCache.EditorTextView, itsTextViewworkarounds (the copied draw loop, the width-cache accessors, the caret reflection, the kill-command andContentsChangedfixes) and the AGENTS.md notes about them are deleted, which clears theTextView is obsoletewarnings 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.
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:
DiffTab), which draws its own rows and isn't aTextView.InputView, the review summary).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
Ctrl+M,Ctrl+Y) are cleared, so Editor's macOS key gaps (#252) don't reach users.--smokeopens an editor tab, so the native binary exercises Editor on every release RID.Original idea