Summary
Terminal.Gui.TextView can be reused as a one-line (or fixed-height) input field via Multiline (false ⇒ single-line; disables word-wrap, constrains navigation), EnterKeyAddsLine (false ⇒ Enter raises Accepting instead of inserting a newline — form submit), and TabKeyAddsTab (false ⇒ Tab traverses focus instead of inserting). Editor is multi-line only.
Direction: Editor is intended to functionally replace TextView (not API/UI-compatible). A syntax-highlighted single-/few-line code or expression input (REPL line, search/expression field) is a real product want TextView serves poorly. This resolves the prior non-goal tension (specs/decisions.md OPEN-006): single-line/embeddable-input is a target, not ceded to TextView. Most of it is key-binding-level — Enter/Tab semantics + an Accepting event + a height/scroll constraint.
Not replicable by a consumer: changes core key semantics and the layout/scroll contract; not reachable via current API.
Scope
Multiline (bool, default true) on Editor: when false, suppress newline insertion, disable WordWrap, constrain vertical nav/scroll to one row, remove Command.NewLine key binding.
- Interactions: multi-caret / vertical-multi-caret disabled (or no-op) when
Multiline == false; selection still works.
Not in Scope
EnterKeyAddsLine (default true): when false, Enter raises an Accepting event (TG Accepting/HandledEventArgs convention) instead of Command.NewLine.
TabKeyAddsTab (default true): when false, Tab/Shift+Tab fall through to focus traversal instead of indent/insert. Users can remove the keybindgns for tab if they wan this fn.
- All three wired through commands + the configurable
[ConfigurationProperty] Editor.DefaultKeyBindings where they are binding-shaped; no inline if.
Definition of done
Refs: specs/textview-parity-gap/spec.md Gap 3, specs/decisions.md OPEN-006.
Summary
Terminal.Gui.TextViewcan be reused as a one-line (or fixed-height) input field viaMultiline(false ⇒ single-line; disables word-wrap, constrains navigation),EnterKeyAddsLine(false ⇒ Enter raisesAcceptinginstead of inserting a newline — form submit), andTabKeyAddsTab(false ⇒ Tab traverses focus instead of inserting).Editoris multi-line only.Direction:
Editoris intended to functionally replaceTextView(not API/UI-compatible). A syntax-highlighted single-/few-line code or expression input (REPL line, search/expression field) is a real product wantTextViewserves poorly. This resolves the prior non-goal tension (specs/decisions.mdOPEN-006): single-line/embeddable-input is a target, not ceded toTextView. Most of it is key-binding-level — Enter/Tab semantics + anAcceptingevent + a height/scroll constraint.Not replicable by a consumer: changes core key semantics and the layout/scroll contract; not reachable via current API.
Scope
Multiline(bool, defaulttrue) onEditor: when false, suppress newline insertion, disableWordWrap, constrain vertical nav/scroll to one row, remove Command.NewLine key binding.Multiline == false; selection still works.Not in Scope
EnterKeyAddsLine(defaulttrue): when false, Enter raises anAcceptingevent (TGAccepting/HandledEventArgsconvention) instead ofCommand.NewLine.TabKeyAddsTab(defaulttrue): when false, Tab/Shift+Tab fall through to focus traversal instead of indent/insert. Users can remove the keybindgns for tab if they wan this fn.[ConfigurationProperty] Editor.DefaultKeyBindingswhere they are binding-shaped; no inlineif.Definition of done
specs/decisions.mdOPEN-006 → resolved (DEC-008): single-line/embeddable-input is a target; rationale = Editor functionally replaces TextView.Multilinespecs/single-line-mode/spec.md;specs/public-api.mdupdated (R8).dotnet format+jbclean.Refs:
specs/textview-parity-gap/spec.mdGap 3,specs/decisions.mdOPEN-006.