Tools & practice

Developer tools

Terminals, shells and everyday development tools.

Start reading
0 / 6 read

Topics & articlesContents

1 topics

A terminal displays output and forwards input. A shell interprets commands. A multiplexer manages sessions and panes. An editor works with text and code. Understanding these boundaries makes it easier to connect shortcuts, clipboards and configuration without making every tool depend on every other tool.

This series assumes basic command-line experience. Linux examples primarily use Zsh and Wayland; Windows terminal setup has its own chapter. Install software through the appropriate system package manager, then follow the configuration and verification steps here.

The layers behind one window

Ghostty running Zellij, Zsh and Neovim looks like one window but contains several cooperating layers.

LayerResponsibilityTypical symptom
CompositorWindows, outputs, global shortcutsA window cannot move to another screen
TerminalFonts, colours, input encoding, protocolsCharacters or keys behave incorrectly
ZellijSessions, tabs, panes, scrollbackThe previous workspace cannot be reattached
ZshCommands, environment, completionA command or completion candidate is missing
NeovimEditing, navigation, language servicesCompletion or definition lookup fails

An outer layer can intercept Ctrl+h before Neovim receives it. An editor navigation problem may therefore originate in the terminal or multiplexer.

Read by task

TaskChapterExpected result
Configure a Linux/macOS terminalGhosttyValidate configuration and distinguish font, opacity and theme issues
Set up a Windows terminalWezTermStart PowerShell and understand WSL boundaries
Keep a project workspaceZellijCreate, detach and reattach a named session
Make completion predictableZshUnderstand loading order and preview failures
Find files and review changesCLI toolboxChoose search scope and inspect results
Maintain configuration across machineschezmoiReview target differences before applying
Complete a code changeNeovimNavigate, edit, test and review
Organise a Wayland desktopHyprlandConnect compositor, shell, themes and services

For a new environment, proceed through terminal, shell, CLI tools, sessions and editor. Verify the previous layer after adding the next. With an established setup, go directly to the relevant task.

Connect the tools through one project

Choose a project with locally runnable tests and start at its root:

  1. Confirm location with pwd and inspect existing changes with git status --short.
  2. Find paths with rg --files and relevant text with rg -n.
  3. Open a named Zellij session with an editor and a test terminal in separate panes.
  4. Make a small change in Neovim, save it and run the project's test command.
  5. Inspect git diff and check whitespace with git diff --check.
  6. Detach and reattach by name; verify the directory and layout.

This checks whether the environment supports real work. Theme and animation adjustments can follow once the task path is reliable.

Decide what configuration should preserve

Handwritten configuration, generated files, runtime state and credentials need different treatment. A Ghostty configuration can belong in Git; a generated theme should be reproducible; session state belongs to a running machine; private keys and tokens must not accidentally enter a public dotfiles repository.

The examples draw on a Gentoo/Hyprland setup without requiring the entire combination. The configuration reviewed on 2026-09-15 uses Caelestia and a Matugen application-theme hook. Earlier illogical-impulse and dual-hypridle arrangements are historical examples, as explained in the desktop series.

Know when the environment is sufficient

You should be able to identify the command's working directory, the layer receiving a key, and the file or log to inspect when a setting fails. Clear answers make even a small toolset maintainable.

For complete commit and remote-connection procedures, continue with the Git handbook and SSH handbook.