How I use my terminal

Original Article ↗ Hacker News Discussion ↗

HN title mangling and expectations

  • Several comments note HN’s automatic removal of “How” from titles, turning “How I use my terminal” into “I use my terminal,” which misled readers about the article’s content.
  • Some see this auto-editing as pointless and inconsistently applied; others remind submitters they can manually fix titles shortly after posting.

tmux, scrollback, and workflow plugins

  • Many share tmux-centric workflows: regex-based jump-to-file, scrollback querying, fuzzy selectors (fzf), and plugins like tmux-copycat, fpp, fingers, urlview, resurrect, continuum, extrakto, tome.
  • A recurring theme: using terminal scrollback as a rich state to drive navigation (paths, logs, stack traces) rather than re-running tools.
  • Some point out these configs lean heavily on basic Unix primitives (pipes, files, pane scrollback), which helps with portability over SSH.

Vim / Neovim techniques and philosophy

  • Extensive tips around using ripgrep + Vim quickfix (rg --vimgrep | vim -c cb! -c copen -) and variants (vim -q, custom shell functions, vgrep wrappers).
  • Discussion of quickfix vs “just use buffers + gf,” and lightweight vimrcs vs plugin-heavy setups.
  • Debate over learning defaults vs rebinding keys (e.g., hjkl ergonomics); some argue old defaults are arbitrary, others say survivorship implies value.
  • Several ask to be “sold” on Vim; replies emphasize composable motion “grammar,” speed, and ubiquity, while acknowledging IDEs can be more feature-rich out of the box.

Emacs vs vim+tmux vs IDEs

  • Emacs advocates describe it as the “native” solution: TRAMP for remote files/containers, Eshell integration, pipes between buffers and commands, and deep inspectability via Elisp.
  • Counterpoint: vim+tmux is simpler, more transparent, and less bug-prone; Emacs setups can become more complex and fragile.
  • One comment summarizes: many vim+tmux setups are “half an Emacs,” while others argue that’s a feature, not a bug.

Terminal vs GUI editors and productivity

  • Strong pro-terminal sentiment: keyboard-centric workflows, reproducible environments via dotfiles, scripting/CI reuse, and dislike of GUI padding and mouse dependence.
  • Skeptics compare terminals to “horses vs cars,” arguing GUIs (and modern IDEs) are easier and often faster for many tasks.
  • Subthread debates whether mastering tools significantly impacts productivity vs higher-leverage activities (design, communication). Some say tool obsession yields diminishing returns; others view relentless tooling refinement as core to craftsmanship.

Stylistic choice: all-lowercase blog

  • The article’s all-lowercase prose draws mixed reactions; some find it distracting or unprofessional enough to skip reading, others see it as a long-standing online stylistic choice.
  • A few frame writing style in terms of “surprise budget”: deviating from norms makes form compete with content for attention.

Structured terminals, PowerShell, and future directions

  • Several wish terminals exposed structured metadata for scrollback (paths, types, errors) instead of raw ANSI text, enabling richer interactions without fragile regexes.
  • PowerShell is cited as “close” due to object pipelines, but criticized for binary blobs and ecosystem inertia.
  • There’s interest in new standards (extra structured-output streams) and “strangler” migration strategies rather than a single flag-day rewrite.

Nix and environment management

  • Some praise Nix/NixOS for reproducible, pinned environments and easy ad-hoc nix run usage.
  • Others avoid Nix due to perceived brittleness and the cost of packaging arbitrary binaries just to run them “at runtime.”

AI-assisted coding and terminals

  • Several note VS Code/Cursor + Copilot/agents as the main pull away from terminal workflows.
  • Others report success staying in the terminal with tools like aider, Claude Code, Neovim plugins, and MCP-based setups, claiming parity or superiority to GUI-based AI flows.