173 lines
8.9 KiB
Text
173 lines
8.9 KiB
Text
---
|
|
title: "auto-theme.nvim"
|
|
slug: "auto-theme.nvim"
|
|
date: "28/11/2025"
|
|
---
|
|
|
|
# the problem
|
|
|
|
I toggle between light and dark mode at at around 17:00 every day. Resetting my environment and theme across all my applications was a pain. I built auto-theme.nvim to update my neovim theme automatically.
|
|
|
|
## the solution
|
|
|
|
I spawn a OS-specific watcher to listen, in a non-polling manner, for theme updates:
|
|
|
|
- linux: I integrate with D-Bus, parsing and filtering messages for settings changes to the system appearance.
|
|
- macOS: I integrate with the Apple toolkit AppKit to do the same thing--wait for a theme changed notification to be pushed out to the running app object and print accordingly.
|
|
|
|
Stdout is continually parsed from the job and the appropriate theme is set.
|
|
|
|
# the interesting problem
|
|
|
|
OK, cool. Now, how can I implement automatic theme-switching for _all_ programs I use?
|
|
|
|
> Note: I use my color scheme [midnight.nvim](/git/midnight.nvim.html)
|
|
|
|
I most commonly use the following applications:
|
|
|
|
1. [neovim](https://neovim.io/)
|
|
2. [ghostty](https://ghostty.org/)
|
|
3. [sioyek](https://sioyek.info/)
|
|
4. [ungoogled-chromium](https://github.com/ungoogled-software/ungoogled-chromium)
|
|
5. [swaywm](https://swaywm.org/)
|
|
6. [rofi](https://github.com/davatorium/rofi)
|
|
7. [tmux](https://github.com/tmux/tmux/wiki)
|
|
8. [fzf](https://github.com/junegunn/fzf)
|
|
9. [ripgrep](https://github.com/BurntSushi/ripgrep)
|
|
10. [zsh](https://www.zsh.org/)
|
|
|
|
All of the code can be found in my [dotfiles](https://github.com/barrettruth/dots). The implementations are scattered and I provide no guarantee that files will not be moved
|
|
|
|
## success criteria
|
|
|
|
I run or trigger _one command_--every application updates automatically.
|
|
|
|
The feasability of this depends on the underlying support software has for dynamic reloading of configuration. In many cases this is not possible.
|
|
|
|
## the solution
|
|
|
|
As of November 28, 2025, I've created [this script](https://github.com/barrettruth/dots/blob/main/scripts/theme) which is bound by a [karabiner](https://karabiner-elements.pqrs.org/) and [keyd](https://github.com/rvaiya/keyd) binding for macOS and linux, respectively, for quick access.
|
|
|
|
### successes
|
|
|
|
1. neovim: [auto-theme.nvim](https://github.com/barrettruth/auto-theme.nvim)
|
|
2. ghostty: Ghostty supports [light and dark themes based on the system appearance](https://github.com/tmux/tmux/wiki)--easy.
|
|
3. sioyek: Any changes to user configuration are automatically reloaded--my script updates the program's settings file `prefs_user.config` in-place
|
|
4. ungoogled-chromium: I folded and used the default system theme which automatically reads and updates according to the system environment
|
|
5. swaywm (linux): sway reads from a symlink'ed theme file updated by the scripts; `swaymsg reload` triggers an instant window-manager-wide reload
|
|
6. rofi: the config file, `config.rasi`, derives its theme from a symlink'ed file updated and reloaded by the script
|
|
7. tmux: similarly to rofi, the config `tmux.conf` reads from symlink'ed theme files that are automatically reloaded with `source-file`. I also refresh the UI with `refresh-client`:
|
|
|
|
```sh
|
|
ln -sf ~/.config/tmux/themes/$theme.tmux ~/.config/tmux/themes/theme.tmux
|
|
tmux source-file ~/.config/tmux/themes/$theme.tmux
|
|
tmux refresh-client -S
|
|
```
|
|
|
|
### failures
|
|
|
|
Unfortunately, the following programs I've found nearly impossible to dynamically reload:
|
|
|
|
8. fzf: Overwriting fzf's themes, from the interactive shell `fzf` binary to `fzf-{cd,file}-widget` to integration with [fzf-lua](https://github.com/ibhagwan/fzf-lua/), I found this potentially doable but just _way too complex_. Feel free to investigate yourself--I'm going with the default theme.
|
|
9. ripgrep: I use the default theme. The ripgrep global configuration file does not support environment variables, exterminating the option to provide a `${THEME}`-based path in the global configuration file.
|
|
10. zsh: it's impossible to update `$THEME` across all existing shells (simply a limit of posix). However, all affected _programs_ will read the proper `$THEME`--I'm fine compromising here.
|
|
|
|
### upd: fzf, ripgrep, fzf-lua, and shell improvements <span class="date">30/11/2025</span>
|
|
|
|
After some _extreme_ amounts of finagling I'm now able to automatically update fzf and ripgrep themes both in the shell (after re-rendering the prompt\*) and in new fzf-lua instances. I consider this a 99% win.
|
|
|
|
I do it with the following strategy for:
|
|
|
|
a) cli programs
|
|
|
|
Since, according to \#10 above, it is impossible to update all running shells, one way I can come to auto-updating program themes is in between terminal prompts. To get around this, I added a zsh precmd hook to my `zshrc` for both programs which checks if a symlink has been updated:
|
|
|
|
- fzf: If `~/.config/fzf/themes/theme` is updated, re-export `$FZF_DEFAULT_OPTS` to include the new colors:
|
|
|
|
```zsh
|
|
_fzf_theme_precmd() {
|
|
local theme_file=~/.config/fzf/themes/theme
|
|
local theme_target=$(readlink "$theme_file" 2>/dev/null) || return
|
|
typeset -g _FZF_THEME_TARGET
|
|
test "$theme_target" = "$_FZF_THEME_TARGET" && return
|
|
_FZF_THEME_TARGET="$theme_target"
|
|
test -r "$theme_file" && export FZF_DEFAULT_OPTS="$(<"$theme_file") $FZF_OPTS"
|
|
}
|
|
add-zsh-hook precmd _fzf_theme_precmd
|
|
```
|
|
|
|
- ripgrep: If `~/.config/rg/themes/theme` is updated, re-build the `$RIPGREP_CONFIG_PATH` file as a concatentation of the _new_ theme and a separete _base_ configuration file and re-export the environment variable.
|
|
|
|
Any and all shells, after re-rendering their terminal prompts, will see proper colors for all fzf and ripgrep commands.
|
|
|
|
b) neovim
|
|
|
|
This is a bit trickier. How can a running neovim process automatically update its internal colors used by fzf-lua? There are two aspects of this problem:
|
|
|
|
1. Finding and interacting with all existing Neovim instances: RPCs with remote neovim features provide the ability to remotely probe neovim instances.
|
|
|
|
I use an RPC to trigger the update (see \#2 below). Of course, this requires automatically configuring a socket for each neovim instance to listen on. I use the process id, unique to the neovim instance--any 1:1 mapping from neovim instance to socket identifier will do:
|
|
|
|
```lua
|
|
local socket_path = ('/tmp/nvim-%d.sock'):format(vim.fn.getpid())
|
|
vim.fn.serverstart(socket_path)
|
|
```
|
|
|
|
Then send a a command like so (see `:h remote`):
|
|
|
|
```sh
|
|
nvim --server "$socket" --remote-send "<c-o><cmd>lua require('fzf_reload').reload()<cr>" 2>/dev/null || true
|
|
```
|
|
|
|
Neovim instances can be found by just listing `/tmp/nvim-*.sock`.
|
|
|
|
2. Re-configuring fzf-lua: fzf-lua does not support "dynamic" reconfiguration but you can re-initialize the plugin with `require('fzf-lua').setup(opts)`.
|
|
|
|
- fzf: I expose a function for RPC calls `fzf_theme.reload_colors()` which re-initializes the fzf environment. Special care must be taken to store and pass down the _initial_ fzf-lua configuration and update it with the new environments colors.
|
|
- ripgrep: automatically re-reads from `$RIPGREP_CONFIG_PATH`, a symlink updated by my theme script
|
|
|
|
I confess that this solution is not perfect. For example, existing pickers cannot have their theme dynamically re-loaded ([I'm looking into this](https://github.com/ibhagwan/fzf-lua/discussions/2448)) as `FzFLua resume` cannot build theme context. I'm close enough (for now! >:)).
|
|
|
|
### upd: neovim, tmux improvements <span class="date">2/23/2025</span>
|
|
|
|
Apparently, neovim [already supports auto-switching the `vim.o.background`](https://github.com/neovim/neovim/commit/d460928263d0ff53283f301dfcb85f5b6e17d2ac) as of November, 26, 2024. So, technically, auto-theme.nvim is defunct. Welp, who cares... it was fun to make! I use the following config to auto-toggle the theme when the aforementioned option is set:
|
|
|
|
```lua
|
|
vim.api.nvim_create_autocmd({ 'OptionSet' }, {
|
|
pattern = 'background',
|
|
callback = function()
|
|
vim.cmd.colorscheme(
|
|
vim.o.background == 'dark' and 'midnight' or 'daylight'
|
|
)
|
|
end,
|
|
group = vim.api.nvim_create_augroup(
|
|
'Midnight',
|
|
{ clear = true }
|
|
),
|
|
})
|
|
```
|
|
|
|
tmux 3.6 also supports this too as of 3.6--see [here](https://github.com/tmux/tmux/issues/4699). I updated my tmux.conf, conveniently removing my `~/.config/tmux/themes/*` symlink hackiness:
|
|
|
|
```mux
|
|
if -F '#{==:#{client_theme},dark}' {
|
|
# set dark mode
|
|
}
|
|
|
|
if -F '#{==:#{client_theme},light}' {
|
|
# set light mode
|
|
}
|
|
```
|
|
|
|
## upd: improve tmux theme updating <span class="date">14/12/2025</span>
|
|
|
|
The above config does not always update the tmux theme in tandem with the system theme. For example, on system startup, the tmux theme is not set. I could only get around this by manually reloading the configuration _inside_ of tmux.
|
|
|
|
It is simpler (and more correct) to set the theme as a function of when tmux itself detects changes to the system theme. This is possible by leveraging the exposed hooks `client-{light,dark}-theme` as follows:
|
|
|
|
```tmux
|
|
set-hook -g client-light-theme 'source $XDG_CONFIG_HOME/tmux/themes/daylight.conf'
|
|
set-hook -g client-dark-theme 'source $XDG_CONFIG_HOME/tmux/themes/midnight.conf'
|
|
```
|
|
|
|
where the configuration files house the individual theme logic.
|