The potential for breakage is too high, and I am working on an
alternative solution that will be better long term.
Prewarming is still used for kittens launched via keybindings
Will come in handy for various things in the future, so lets just setup
the API now. No new dependencies are needed since Python already depends
on OpenSSL.
Add more text roles and links.
Fix typos.
Adjust the default shortcut order in overview.
Notes on the impact of kitty-open.desktop on the default open apps.
Document KITTY_DEVELOP_FROM in glossary.
Add Python type hints to the watcher example.
Mention clone-in-kitty in launch --copy-env.
Fix remote control ls example does not work, by escaping the backslash.
Distro packages and source builds will no longer do update checking.
Remove the packaging defaults instructions since they are not needed
any more. The shell integration scripts shouldnt be installed system
wide anyway.
I think I have things setup robustly so that the shell integration
is loaded transparently via env vars and the normal bash startup files
are sourced, in the same way that vanilla bash does it. Let's hope I
haven't overlooked something.
This makes it possible to execute `nix-shell` to create the correct environment to build kitty. Use `nix-shell --pure` to eliminate most of the influence of the outside system, e.g. globally installed packages.
This works on NixOS and any Linux or macOS system with the Nix package manager installed.
The build inputs are split into `buildInputs`, `nativeBuildInputs`, `propagatedBuildInputs` and `checkInputs` so it closely resembles 2bb3a9da24/pkgs/applications/terminal-emulators/kitty/default.nix. This makes it easy to port changes between the two files.
Now there is only one launcher. Which means it can be used to start
kitty with profiling and ASAN in the natural way. The recommended
way to run kitty from source is now:
./kitty/launcher/kitty
The launcher also automatically re-execs to resolve symlinks on macOS.
