Fixes #5304. Create a TextViewEditor that wraps Editor with a TextView-compatible API

[Copilot]

Fixes

Proposed Changes/Todos

New Terminal.Gui.TextViewEditor project wrapping the Terminal.Gui.Editor NuGet package with a TextView-compatible API surface to ease incremental migration. The project is kept separate from Terminal.Gui to avoid a circular dependency (Terminal.Gui → Terminal.Gui.Editor → Terminal.Gui).

Wrapper API exposed:

• Text, CurrentRow, CurrentColumn, InsertionPoint, Lines
• ReadOnly, TabWidth
• IsSelecting, SelectedText, SelectedLength, SelectAll(), ClearSelection()
• IsDirty
• Load(string path), Load(Stream)
• CaretChanged, SelectionChanged, ContentsChanged events
• UnderlyingEditor / Document escape hatches for advanced usage

Infrastructure:

• Added Terminal.Gui.Editor v2.1.1-develop.75 to Directory.Packages.props
• Updated nuget.config package source mapping to allow Terminal.Gui.Editor from nuget.org
• Added test project (Tests/TextViewEditorTests) with 21 unit tests

Notepad scenario upgraded:

• Upgraded the existing Notepad scenario to use TextViewEditor instead of TextView
• TextView → TextViewEditor type swap, TabKeyAddsTab = false removed (Editor handles tab behavior via IndentationSize)
• File open/save, dirty tracking, unsaved-changes prompts, and tab management all work through the TextViewEditor API

Usage:

TextViewEditor editor = new ()
{
    X = 0, Y = 0,
    Width = Dim.Fill (), Height = Dim.Fill ()
};
editor.Text = "Hello, World!";
editor.InsertionPoint = new Point (5, 0);
// Access advanced Editor features when needed:
editor.UnderlyingEditor.FoldingManager = ...;

• New project + csproj
• TextViewEditor implementation
• Unit tests (21 passing)
• Solution updated
• Existing Notepad scenario upgraded to use TextViewEditor

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[tig]

@copilot Prove this works by porting the Notepad Scenario to use TextViewEditor.

[tig]

@copilot TextViewEditor should not be a new project, just a new View-derived class in ./Views.

[Copilot]

@copilot Prove this works by porting the Notepad Scenario to use TextViewEditor.

Done in 90fd1aa. Added a NotepadEditor scenario that is a direct port of the Notepad scenario using TextViewEditor instead of TextView. The port required only minimal changes:

• TextView → TextViewEditor (type swap)
• TabKeyAddsTab = false removed (not needed — Editor handles tab behavior via IndentationSize)
• CreateAndAddTextView → CreateAndAddEditor
• RegisterTextViewEvents → RegisterEditorEvents
• ContentsChanged event works identically

The scenario demonstrates that TextViewEditor is a practical drop-in replacement for TextView in a real multi-tab editor application — file open/save, dirty tracking, unsaved-changes prompts, and tab management all work through the TextViewEditor API.

[Copilot]

@copilot TextViewEditor should not be a new project, just a new View-derived class in ./Views.

Moving TextViewEditor into Terminal.Gui/Views/ creates a circular dependency: Terminal.Gui → Terminal.Gui.Editor (NuGet) → Terminal.Gui (>= 2.1.0). The Terminal.Gui.Editor package is published externally and already depends on Terminal.Gui, so the main project can't reference it back.

The separate project (Terminal.Gui.TextViewEditor) exists specifically to break this cycle — it sits between the two and references both.

Would you like me to:

1. Keep the separate project as-is (bridge between the two packages), or
2. Remove the NuGet dependency entirely and implement TextViewEditor as a standalone View in ./Views that doesn't use the Terminal.Gui.Editor package at all (essentially building a new editor from scratch or providing a lighter adapter pattern)?

[BDisp]

@copilot TextViewEditor should not be a new project, just a new View-derived class in ./Views.

Sensible decision. That makes much more sense.

[tig]

@copilot keep separte project.

I do not want a new scenario; I wanted you to ugprade the existing Notepad scenario.

[Copilot]

@copilot keep separte project.

I do not want a new scenario; I wanted you to ugprade the existing Notepad scenario.
...

Done in 430b0de. Removed the NotepadEditor scenario and upgraded the existing Notepad scenario to use TextViewEditor instead of TextView. The separate project is kept as-is since Terminal.Gui.Editor depends on Terminal.Gui, creating a circular dependency if merged into ./Views.

[tig]

@copilot What would it take to just have TextView wrap Editor?

[Copilot]

@copilot What would it take to just have TextView wrap Editor?

The main blocker is the circular dependency: Terminal.Gui.Editor (NuGet) already depends on Terminal.Gui, so Terminal.Gui can't reference it back. To make TextView wrap Editor, you'd need to:

1. Bring Editor source into the repo (as a git submodule or vendored source) instead of consuming it as a NuGet package. Then TextView could delegate to Editor internally with no circular reference.
2. Replace ~5,100 lines of TextView implementation (15 partial-class files: Commands, Drawing, Files, Find, History, Keyboard, Mouse, Movement, Scrolling, Selection, Text, WordWrap, etc.) with delegation calls to Editor's API.
3. Maintain the full public API surface — all existing TextView properties, methods, and events would need to map to Editor equivalents. Some may not have 1:1 mappings (e.g. WordWrap, TabKeyAddsTab, the undo/redo HistoryText model).
4. Update all ~1,500+ test assertions that depend on TextView internals (cursor math, selection model, line tracking).

The most practical path: vendor the Editor source into Terminal.Gui/Views/TextInput/Editor/ (or a submodule), then incrementally replace TextView's internals with Editor delegation while keeping the public API stable. This avoids the NuGet cycle entirely and lets you deprecate the old implementation file-by-file.

[tig]

@copilot study all uses of TextView in the codebase. Identify specific places where simply renaming TextView to TextViewEditor would break something. IOW, how far off is TextViewEditor from TextView.

[Copilot]

@copilot study all uses of TextView in the codebase. Identify specific places where simply renaming TextView to TextViewEditor would break something. IOW, how far off is TextViewEditor from TextView.

Here's the full gap analysis. TextViewEditor currently exposes ~13 of TextView's ~75 public members.

✅ Safe to rename (already in TextViewEditor):

• Text, CurrentRow, CurrentColumn, InsertionPoint, Lines
• ReadOnly, TabWidth
• IsSelecting, SelectedText, SelectedLength, SelectAll(), ClearSelection()
• IsDirty
• Load(string), Load(Stream)
• ContentsChanged ⚠️ (signature differs: EventHandler vs EventHandler<ContentsChangedEventArgs>)
• CaretChanged, SelectionChanged

❌ Would break — 62+ missing members grouped by category:

Category	Missing Members	Usage Sites
Text behavior	Multiline, EnterKeyAddsLine, TabKeyAddsTab, WordWrap, ScrollBars	TextInputControls, Editor.Menu, SyntaxHighlighting (5+ scenarios)
Clipboard ops	Copy(), Cut(), Paste(), DeleteCharLeft(), DeleteCharRight(), DeleteAll()	87+ command test usages
Undo/Redo	Undo(), Redo(), HasHistoryChanges, ClearHistoryChanges()	TextView.CommandTests
Find/Replace	FindNextText(), FindPreviousText(), ReplaceAllText(), FindTextChanged()	Editor.FindReplace scenario, tests
Cell-based APIs	GetLine(int), GetCurrentLine(), GetAllLines(), GetColumnsWidth(), Load(List<Cell>), Load(List<List<Cell>>)	SyntaxHighlighting, Editor scenarios
Selection details	SelectionStartRow, SelectionStartColumn, SelectedCellsList	Autocomplete tests (20+ uses)
Navigation	MoveEnd(), MoveHome(), PositionCursor(), ScrollTo()	20+ test usages
Text insertion	InsertText(string)	Autocomplete tests
Autocomplete	Autocomplete property (IAutocomplete)	20+ test usages, TextViewAutocompletePopup scenario
Drawing customization	DrawNormalColor, DrawReadOnlyColor, DrawSelectionColor, DrawUsedColor events + On*Color() virtuals	SyntaxHighlighting scenario
Advanced	InheritsPreviousAttribute, Used, UseSameRuneTypeForWords, SelectWordOnlyOnDoubleClick, DefaultCursorStyle, DefaultKeyBindings, ContextMenu	Editor.Menu scenario
Design	EnableForDesign(), CloseFile(), PromptForColors()	NativeAot, tests

Specific scenario breakage if you renamed today:

• Editor.FindReplace.cs — relies on FindNextText, FindPreviousText, SelectedText (mixed)
• SyntaxHighlighting.cs — relies on GetLine(), GetAllLines(), InheritsPreviousAttribute, DrawNormalColor
• TextInputControls.cs — relies on WordWrap, Multiline, TabKeyAddsTab, EnterKeyAddsLine, ScrollBars
• ConfigurationEditor.cs — ContentsChanged signature mismatch (EventHandler<ContentsChangedEventArgs> vs EventHandler)
• TextViewAutocompletePopup.cs — relies on Autocomplete, Multiline
• All 15+ TextView test files — extensive use of clipboard, navigation, cell-based, and autocomplete APIs

Bottom line: TextViewEditor covers the basics (text get/set, cursor position, dirty tracking, file I/O). It's ~17% of the public surface. The remaining 83% falls into Editor's own API accessible via UnderlyingEditor, but a mechanical rename of TextView → TextViewEditor across the codebase would break every scenario and test file except Notepad (which was explicitly ported).

[tig]

Closing as a bad idea. See #5322 instead.