Closed shot-codes closed 2 months ago
you've got your kitty config in a read only filesystem, naturally changing it, which is what's needed, is not going to work.
Has this always been the case though? this worked just fine before updating. I've always managed kitty config with home manager which stores the kitty config in a read only filesystem
Reloading a color theme requires changing the color theme. The color theme is defined in the conf file. It has always been so. If you want to reload colors without changing the conf file use the remote control facility for that, but then any new kitty instances you start will naturally use the old colors.
Okay thank you. however the fact the newly opened windows do receive the new color theme suggests that the change is taking place, suggesting an issue with the live-reload
Read the error message you yourself posted: Error: open /nix/store/snznb8z8dfvx826gxb2035x2c3bxz6zm-hm_kittykitty.conf.atomic-write-3560583081: read-only file system
Sorry for the premature comment, and ultimately premature issue. The error message in my original post is actually unrelated and is only encountered in my attempt to make a minimal reproduction. My full setup is as follows:
.config/kitty/
├── current-theme.conf
├── theme.conf
├── kitty.conf -> /nix/store/<hash>-home-manager-files/.config/kitty/kitty.conf
├── theme.conf
└── themes/
├── light.conf
└── dark.conf
Since kitty.conf
is indeed in a read-only filesystem, I work around this by including theme.conf
in kitty.conf
with include /home/shot/.config/kitty/theme.conf
. The contents of theme.conf
are:
# BEGIN_KITTY_THEME
# Alabaster Custom
include current-theme.conf
# END_KITTY_THEME
I attempt to change themes by calling kitten themes --reload-in=all --cache-age=-1 --config-file-name /home/shot/.config/kitty/theme.conf Alabaster Dark Custom
This doesn't report the error above, as it only changes the contents of theme.conf
. The file is written to successfully, and subsequently opened windows reflect the change. However, currently open windows do not change theme.
I dont really see how that's possible. existing kitty processes are sent the SIGUSR1 signal and reload their config on receipt of that signal. If you can come up with a minimal, non-nix based reproducer for it, I will take a look. I'm afraid setting up nix is way too much overhead for debugging this for me.
I'm afraid setting up nix is way too much overhead for debugging this for me.
Totally understandable, I wouldn't expect you to. I will see if I can reproduce outside of nix.
existing kitty processes are sent the SIGUSR1 signal
FYI: I am able to trigger the theme update by manually issuing a SIGUSR1 signal with kill -SIGUSR1 <pid>
to any already open kitty window, so I can create a workaround for this. I will see if there is a way for me to debug any further to see what is potentially going wrong with the signal.
Thank you for your help, its much appreciated. Kitty is fantastic
I also have this issue on NixOS. It did not manifest on nixos-24.05. Even the current kitty window does not change. Sending SIGUSR1 to windows does the trick.
Describe the bug When I issue a
kitten themes --reload-in=all
command, I receive the following error:The theme does not change for open windows but windows created after issuing the command have reflect the theme change.
I'm not sure when this was introduced as I hadn't updated my system in ~2 months. I do think it was a regression though as live changing themes of existing windows worked before the update. I use nix home manager to manage my kitty config and AFAIK there hasn't been any major changes that would change this behavior.
To Reproduce Steps to reproduce the behavior:
kitten themes
command with optionreload-in=all
Environment details
Additional context The problem is present with instances run with
kitty --config NONE