2016-03-06 12:50:00 +00:00
|
|
|
|
# dotfiles
|
2016-05-13 12:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
Here’s my dotfiles, inspired by people like Mathias. See his dotfiles at
|
2016-05-13 12:55:30 +01:00
|
|
|
|
[`https://github.com/mathias/dotfiles`](https://github.com/mathias/dotfiles).
|
2016-05-13 12:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
The idea I’m currently going down is to create a symlink from `$HOME` to this
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
directory. There is one exception to this, the `.gitconfig` file. I don’t want
|
|
|
|
|
|
actual commiter details committed into this repo, and they differ per machine
|
|
|
|
|
|
anyway — this Mac signs with my work address, the iMac with my personal one.
|
|
|
|
|
|
|
|
|
|
|
|
So identity and signing live in an untracked `$HOME/.gitconfig.local`, which the
|
|
|
|
|
|
tracked `gitconfig` pulls in with an `[include]` as its **last** directive. Last
|
|
|
|
|
|
matters: git applies config in file order, so anything after the include would
|
|
|
|
|
|
override it.
|
|
|
|
|
|
|
|
|
|
|
|
`$HOME/.gitconfig` is copied rather than symlinked, so that an ad-hoc
|
|
|
|
|
|
`git config --global` writes into `$HOME` instead of dirtying this repo. The
|
|
|
|
|
|
trade-off is that `git pull` alone does not update it — re-run `./bootstrap.sh`,
|
|
|
|
|
|
or `cp gitconfig ~/.gitconfig`, after changing the tracked copy.
|
2016-05-13 12:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
2016-05-13 13:00:05 +01:00
|
|
|
|
First clone the repo.
|
|
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
Run `./bootstrap.sh`, this will create all the necessary symlinks, then source
|
2024-06-25 19:42:33 +01:00
|
|
|
|
`.zshrc`.
|
|
|
|
|
|
|
|
|
|
|
|
> [!WARNING]
|
|
|
|
|
|
> This is a **destructive** process, so backup your dotfiles first.
|
2024-03-22 16:04:02 +00:00
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
As mentioned above, git identity lives in an untracked `$HOME/.gitconfig.local`.
|
|
|
|
|
|
`bootstrap.sh` seeds it from `gitconfig.local.template` if it does not already
|
|
|
|
|
|
exist, and never overwrites an existing one. Fill it in:
|
2024-03-22 16:04:02 +00:00
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
```
|
|
|
|
|
|
[user]
|
|
|
|
|
|
name = Jonny Barnes
|
|
|
|
|
|
email = jonny@jonnybarnes.uk
|
|
|
|
|
|
signingkey = ssh-ed25519 AAAA...
|
2024-03-22 16:04:02 +00:00
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
[commit]
|
|
|
|
|
|
gpgsign = true
|
2024-03-22 16:04:02 +00:00
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
[gpg "ssh"]
|
|
|
|
|
|
program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign
|
2024-03-22 16:04:02 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
Do not skip this. Git will not prompt you — with no identity it quietly derives
|
|
|
|
|
|
one from your username and hostname, warns once, and signs nothing.
|
|
|
|
|
|
|
|
|
|
|
|
`$HOME/.extra` is a separate untracked file for other machine-local environment
|
|
|
|
|
|
variables, sourced from `.zshrc`. Keep git out of it:
|
|
|
|
|
|
|
|
|
|
|
|
> [!IMPORTANT]
|
|
|
|
|
|
> Never put `git config --global` in `.extra`. It is re-sourced on every
|
|
|
|
|
|
> `SIGUSR1`, so with several tmux panes the concurrent writes race on
|
|
|
|
|
|
> `~/.gitconfig.lock` and spew `error: could not lock config file`. Put git
|
|
|
|
|
|
> settings in `.gitconfig.local` instead.
|
|
|
|
|
|
|
|
|
|
|
|
## Light and dark mode
|
|
|
|
|
|
|
|
|
|
|
|
Most of this is now handled natively and needs no configuration:
|
|
|
|
|
|
|
|
|
|
|
|
- **ghostty** follows the system appearance itself via
|
|
|
|
|
|
`theme = light:tangere-light.conf,dark:tangere-dark.conf`.
|
|
|
|
|
|
- **tmux** 3.6+ learns the terminal’s theme over OSC 2031 and exposes it as
|
|
|
|
|
|
`#{client_theme}`.
|
|
|
|
|
|
- **bat** picks a theme per invocation from `BAT_THEME_LIGHT` / `BAT_THEME_DARK`.
|
|
|
|
|
|
- **delta** and **nvim** detect the terminal background themselves.
|
|
|
|
|
|
|
Follow light/dark appearance in the tmux status bar
The status bar was five hardcoded tangere-dark colours, so in light mode the
pale #fdfdd9 text landed on a white background and became unreadable. That was
the real reason Auto appearance "never worked with the terminal setup" — ghostty
was switching correctly all along.
Split the colours into tmux-light.conf and tmux-dark.conf. The dark file is
extracted byte-exact from the previous config; the light file is the same layout
with each colour swapped for the tangere-light palette entry at the same index,
so roles are preserved (text on an accent uses the theme background, which
inverts from #1a2938 to #fdfdfa).
tmux 3.6+ learns the terminal's theme over OSC 2031, so this keys off the
appearance change itself rather than a schedule, and behaves identically whether
that came from Auto at sunrise/sunset or a manual toggle. Three hooks: the two
theme hooks react to a change, and client-attached covers a client attaching
mid-way, since those two only fire on a change. Sourcing is idempotent so the
overlap is harmless.
This replaces the dark-mode-notify launchd agent removed in 59d5622, which could
not have worked: it re-sourced .zshrc inside each shell, but the status bar
belongs to the tmux server.
Verified by round trip: flipping to Light switched #{client_theme} and applied
the light palette, and returning to Dark restored it. A running nvim does not
follow a live change (docs: the TUI sets 'background' on startup); noted in the
README.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 12:38:16 +01:00
|
|
|
|
The tmux status bar needs help, because its colours are set explicitly. They live
|
|
|
|
|
|
in `tmux-light.conf` and `tmux-dark.conf` — the same layout, with each colour
|
|
|
|
|
|
taken from the matching tangere palette index — and `tmux` sources one of them
|
|
|
|
|
|
from three hooks:
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
|
Follow light/dark appearance in the tmux status bar
The status bar was five hardcoded tangere-dark colours, so in light mode the
pale #fdfdd9 text landed on a white background and became unreadable. That was
the real reason Auto appearance "never worked with the terminal setup" — ghostty
was switching correctly all along.
Split the colours into tmux-light.conf and tmux-dark.conf. The dark file is
extracted byte-exact from the previous config; the light file is the same layout
with each colour swapped for the tangere-light palette entry at the same index,
so roles are preserved (text on an accent uses the theme background, which
inverts from #1a2938 to #fdfdfa).
tmux 3.6+ learns the terminal's theme over OSC 2031, so this keys off the
appearance change itself rather than a schedule, and behaves identically whether
that came from Auto at sunrise/sunset or a manual toggle. Three hooks: the two
theme hooks react to a change, and client-attached covers a client attaching
mid-way, since those two only fire on a change. Sourcing is idempotent so the
overlap is harmless.
This replaces the dark-mode-notify launchd agent removed in 59d5622, which could
not have worked: it re-sourced .zshrc inside each shell, but the status bar
belongs to the tmux server.
Verified by round trip: flipping to Light switched #{client_theme} and applied
the light palette, and returning to Dark restored it. A running nvim does not
follow a live change (docs: the TUI sets 'background' on startup); noted in the
README.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 12:38:16 +01:00
|
|
|
|
- `client-light-theme` / `client-dark-theme` react to a change,
|
|
|
|
|
|
- `client-attached` picks the right one for a client that attaches mid-way, since
|
|
|
|
|
|
the two above only fire on a change.
|
|
|
|
|
|
|
|
|
|
|
|
Because this keys off the terminal's reported theme rather than a schedule, it
|
|
|
|
|
|
behaves identically whether the change came from Auto at sunrise/sunset or from
|
|
|
|
|
|
toggling Light/Dark by hand — nothing in the chain knows why it changed.
|
|
|
|
|
|
|
|
|
|
|
|
> [!NOTE]
|
|
|
|
|
|
> A running nvim will not follow a live change: the docs are explicit that the
|
|
|
|
|
|
> TUI sets `background` *on startup* if it can detect it. New instances are
|
|
|
|
|
|
> fine; existing ones need `:set background=light` or a restart. delta is
|
|
|
|
|
|
> per-invocation so should be fine, but that is untested here.
|
Remove dark-mode-notify, document the native approach
The launchd agent ran `pkill -usr1 zsh` on every appearance change, which made
every shell re-source .zshrc. That could never have achieved its goal: the tmux
status bar belongs to the tmux server and colours to a running nvim, so
re-sourcing a shell rc cannot retheme either. The one variable it set,
MACOS_APPEARANCE, was read by nothing. Its only real effect was firing on each
unlock — 5253 times on this machine, 3437 on the iMac — which is what drove the
~/.gitconfig.lock contention fixed in 583bbaa.
The agent and plist are removed from both machines; this drops the script.
ghostty, bat, delta and nvim all handle appearance natively, and tmux 3.6+
detects it over OSC 2031 (#{client_theme} already reports correctly). Wiring the
tmux client-light-theme/client-dark-theme hooks is left as the next step.
Also refreshes the stale parts of the README: the intro still explained
~/.gitconfig as a copy because .extra edited it, and the .extra example still
showed the `git config --global` calls that caused the lock errors, plus the
misspelled GIT_COMMITER_* vars. Following it would have reinstated the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 11:37:24 +01:00
|
|
|
|
|
|
|
|
|
|
> [!NOTE]
|
|
|
|
|
|
> This previously used [`dark-mode-notify`](https://github.com/bouk/dark-mode-notify)
|
|
|
|
|
|
> as a `launchd` agent that ran `pkill -usr1 zsh` on every appearance change.
|
|
|
|
|
|
> That has been removed. It could never have worked: re-sourcing `.zshrc` runs
|
|
|
|
|
|
> inside each *shell*, but the status bar belongs to the tmux *server* and
|
|
|
|
|
|
> colours to a running nvim, so it could not retheme either. The one variable it
|
|
|
|
|
|
> set was read by nothing. Meanwhile it fired on every unlock, re-running
|
|
|
|
|
|
> `.zshrc` in every pane. Don’t bring it back.
|
2024-03-22 16:04:02 +00:00
|
|
|
|
|