Video summary

you can just use the same dev setup forever

Main summary

Key takeaways

Technology

Overview / main theme

The speaker shares a “dev setup” workflow they’ve used for years, centered on:

  • Terminal emulator configuration
  • Keyboard remapping
  • Neovim setup
  • Shell choice
  • Small utility tools

The focus is speed, muscle-memory consistency, and avoiding complexity—especially by keeping the terminal layer plugin-free and being cautious about heavy plugin suites.

Hardware / OS context

  • Current OS: macOS
  • Previous experience: x86 and Linux for most of their life
  • Machine: ThinkPad T480 (purchased locally for about $150)
  • Notable specs: 32 GB RAM
  • Procurement note: mentions no delivery fees

Terminal + keybinding philosophy

Terminal emulator

  • Kitty is the terminal of choice
  • Reasons cited:
    • GPU-accelerated
    • Supports rich fonts/images
    • “Best fonts” claim
    • Strong on Linux as well (though the current setup is macOS)

Key remapping philosophy

  • Strong recommendation: don’t use plugins for the terminal environment
    • It’s easier to set up and maintain
  • On macOS, they use Karabiner Elements to remap:
    • Caps Lock → Left Control
  • Kitty is credited for deeper remapping capabilities:
    • remapping at a kernel-level key interception/transformation level
    • rather than only window-manager-level remapping

Shell + editor workflow

Shell: fish

  • Uses fish
  • Prompt/theme: Lemon(y) prompt (“lemmy prompt” in subtitles)

Text editor: Neovim

  • Uses Neovim
  • Mentions earlier terminal editors:
    • nano → micro → helix → Neovim
  • Critiques Neovim’s default experience:
    • “Neovim sucks by default”
    • implies you must “pump hours into it”
  • Core philosophy:
    • rely on muscle memory
    • avoid “having to remember” through extra layers or UI complexity

File browsing tool: “horse”

  • Tool: horse (described as a terminal file navigator/search tool)
  • How it fits the workflow:
    • bindings approximate readline-like movement/search
    • Tab is used for autocomplete/editing items like go.mod and for navigating directories
    • reduces friction when jumping between parts of projects
  • Notes:
    • they plan to link it in the description
    • it’s described as small (about one file, ~720 lines)

Neovim configuration details / plugin guidance

Plugin manager / style

  • Plugin manager: lazy.nvim
  • Mentions migrating toward a lazy-style configuration

Approach to plugins

  • Prefers smaller components over big plugin bundles
  • Advice against Snacks:
    • claims Snacks can be slow, especially while editing config
    • example claim: config editing becomes “4x slower”
    • recommends installing only the needed parts rather than using Snacks wholesale

mini.nvim ecosystem preference

  • Prefers mini.nvim-style tools and functionality
  • Mentions:
    • considering mini.files, but using netrw instead
    • favoring normal buffer-based editing over some file-explorer approaches
  • Mentions mini.pick-like functionality:
    • prefers it over telescope
    • highlights “tab to preview” as a key advantage

Loader/config migration

  • Mentions migrating between features involving:
    • vim.loader/lazy
    • and other approaches

Custom Neovim “micro-tools” and keymaps

The speaker emphasizes small custom utilities and strong keymap instincts:

  • A ~70-line tool that runs commands inside a floating window
    • e.g., running lazy git in a float
  • Custom behaviors:
    • opening help/info windows via custom logic
    • a window-close key like Q to close non-editable windows (useful for popups)
  • Persisted state:
    • “jump to last” / buffer marks
    • reopening returns you to the same character position
  • General editing instinct:
    • surrounding text (e.g., parentheses), replacing characters, alignment, etc.
    • becomes “instinctive” rather than something they consciously remember each time

Portability and configuration fallbacks

Fallback aliases

  • Recommends adding fallback aliases in config scripts
  • Example idea:
    • if hx (Helix) exists, alias hx to helix
    • otherwise point hx somewhere safe
    • goal: avoid empty/unsafe aliases

Dotfiles workflow

  • Dotfiles stored under a directory like ~/dotfiles
  • Synced to GitHub via push/pull
  • Uses manual symlinking/links rather than GNU stow
    • reasoning: stow adds special-casing effort

Terminal universality vs GUI critique

  • Argues terminal workflows are universal and stable
    • references long-standing terminal standards like ncurses / VT100 sequences
  • Claims terminals avoid “bad software” patterns due to:
    • simpler
    • more constrained environments than GUIs/frameworks
  • Contrasts with GUI apps:
    • inconsistent keybind systems
    • no universal clipboard/selection behavior

Code aesthetics: “banner writer” macros

  • Mentions a banner writer implemented as Lua macros (not a plugin)
  • Example usage:
    • inserts multi-line comment banners via a key (e.g., Ctrl+G)
    • updates existing banners if they’re already present
  • Preference:
    • keeping visual structure in one file
    • aligning with how they like idiomatic Zig
    • avoiding spreading logic across many small files

Main speakers / sources

  • Main speaker: Unnamed individual (narrating their own setup and workflow)
  • Tools/systems referenced:
    • Kitty
    • Karabiner Elements
    • fish shell (with “Lemmy/Lemon(y) prompt”)
    • Neovim
    • lazy.nvim
    • mini.nvim
    • horse
    • netrw

Original video