State of the Terminal
Terminal-based interfaces are seen as more capable and pleasant to use than ever, thanks to modern emulators like Windows Terminal and powerful editors and TUI frameworks, yet they remain constrained by 1970s-era assumptions such as ANSI escape codes and the TERM/terminfo maze. Commenters weigh the benefits of this stable, text-stream model—portability, low overhead, and composability—against its usability pain points, from awkward keybindings and poor discoverability to brittle color and input handling. Various “next‑gen” ideas surface, including structured-data shells (à la PowerShell), richer graphics and folding in terminals, and HTML- or GUI-like hybrids, but most acknowledge that deep compatibility requirements make radical change hard to adopt.
Overall sentiment on terminals in 2024
- Many see terminals as more powerful and pleasant than ever, especially with modern emulators and editors (e.g., Neovim with prebuilt configs).
- Others are baffled that 50-year-old constraints still dominate and wish for a “modern textual interface” unconstrained by teletype-era assumptions.
Windows Terminal and Windows CLI ecosystem
- Microsoft’s terminal is praised as a high‑quality, cross‑platform baseline; people like that terminal rendering libraries now mostly “just work” on Windows.
- Criticisms: TERM reuse as
xtermcauses compatibility ambiguity; performance issues when scrolling lots of output; PowerShell startup latency vs Unix shells; persistent pain around code pages and reliable UTF‑8 unless using WSL or alternative shells.
Keybinding, modifiers, and usability
- Modifier handling (Ctrl/Alt, Ctrl+arrows) is seen as a major source of complexity; some terminals and toolkits are improving but it remains fragile.
- Tension between “mouse-friendly, GUI-like editing” in the shell vs traditional keyboard-centric workflows; some want clicking and selection to behave like text editors, while others find such behavior disastrous inside tools like Vim.
- Conflicts over Ctrl‑C/Ctrl‑V: many want familiar copy/paste; others emphasize the need for process control and existing conventions.
Calls for “next‑gen” terminals and structured CLIs
- Several proposals: terminals that handle structured data instead of plain text streams; richer UI primitives (folding, widgets, tables, graphics); more discoverable, IDE-like completion and help.
- Powershell and alternative shells (nushell, elvish, others) are cited as partial examples of structured pipelines.
- Skeptics argue changing the byte‑stream model or ANSI escapes would require “boiling the ocean” and rewriting or abandoning decades of tools.
Backwards compatibility, standards, and terminfo
- Heavy criticism of TERM proliferation,
xterm-*dependence, and lack of strong standardization for escape sequences and capabilities. - Debate over terminfo vs runtime feature queries: some new TUI libraries avoid terminfo and probe terminals directly; others highlight terminfo portability problems across ncurses versions and OSes.
- Some adopt alternative curses implementations (e.g., NetBSD curses) and custom terminfo bundles to sidestep system ncurses issues.
Graphics, TUIs, and richer output
- Interest in sixels, inline images, and Tektronix‑style or overprinting capabilities to get more than two colors per cell and richer shapes.
- Text folding and graphics proposals exist (including DomTerm), but integration with SSH/mosh/tmux and existing workflows is a major blocker.
- Many TUIs rely on libraries (ncurses, charm.sh, etc.) that try to abstract away terminal quirks, but graceful degradation and consistent standards remain open problems.
CLI usability, learning curve, and culture
- Some value the Lindy effect and stability: old skills (pipes, classic tools) stay useful for decades.
- Others see poor UX, inconsistent flags, and cryptic man pages (tar, ip, etc.) as unnecessary friction, especially for newcomers.
- Disagreement over whether Linux desktops should hide terminals for mainstream users or embrace them while improving ergonomics.