Specializations basically double the build time for each one added, so
requiring users to explicitly enable it means quicker build times for
those that prefer Hyprland (which is easier to configure declaratively).
Now that I've figured out how to dynamically import modules and use
those modules as outputs, the next step is to ensure that these modules
work as intended when being used by end users.
NixOS offers a built-in testing solution that enables us to conveniently
spin up virtual machines with a given configuration, then verify their
correctness through python scripting.
The lib.nix file in particular is based on Jörg Thalheim's very useful
blog post that explains how to use the built-in testing functionality
with Nix flakes, which isn't covered in official documentation.
See: https://blog.thalheim.io/2023/01/08/how-to-use-nixos-testing-framework-with-flakes/
Rainbow parentheses were traditionally buggy with the plugins I used but
nowadays there are newer plugins available that use more flexible
technologies like treesitter.
See: https://github.com/hiphish/rainbow-delimiters.nvim
Useful when wanting to have a little fun with screenshots. Seems to
affect performance of fullscreen applications since those receive some
sort of priority when there are no other visible layers on the screen.
This makes the code base more portable by *only* depending on Nix as a
dependency.
Note that the code base hasn't been migrated to nixfmt-rfc-style yet.
Having a default.nix doesn't *really* make sense now that we're dealing
with multiple nixosConfigurations, some of which might not even be in
the same flake.
Now it's possible to use the specializations in arbitrary configs. Note
that specializations do slow things down a bit so they may be disabled
by default in the future.
Fixes an issue where the base16-schemes overlay wasn't being applied
presumably due to the separate nixosModule usage.
This removes Qt theming support, so it may be better to simply overlay
base16-schemes inside the module instead.
From a pragmatic perspective this never made sense since it would be
unlikely that we'd ever want to import multiple hardware configurations
at the same time.
An alternative solution would be to let users generate their own
hardware-configuration.nix that they can use with this nix-config, or
simply have them create their own nix-config that imports this flake and
uses the outputs they want.
The code for this is extremely messy right now however it works and I'd
rather not accidentally break it while refactoring, so this commit
serves as documenting the working code.
Now that I have more experience with nix, I know how to write an
expression that automatically outputs all the overlays in the
repository, as well as automatically import them inside the nixos
configuration.
This makes it possible to programmatically use all the outputs in a
flake without having to manually specify each one individually, useful
for having one main nix-config that can be used with other flakes and
system configurations.
I originally wrote default.nix files to "import all files in a given
directory" however this turns out to not be necessary when flakifying a
configuration and defining all modules, overlays, and packages as
outputs.
Instead of making these "default.nix" files the source of truth for all
imports, it should be more useful to make the flake.nix the source of
truth and programmatically use attribute values as needed.
After almost a year of using joshuto, I have decided to switch to yazi.
The latest joshuto update broke my image preview configuration, and it
didn't make sense trying to figure out the issue with yazi already
having built-in image support and more.
Other notable improvements from this change include:
- Simplified configuration since defaults no longer have to be
re-declared
- Faster directory loading, especially for /nix/store/ and symlinks to
/nix/store/
- Text files are more likely to show previews without manual
configuration
- Videos now have working previews again, similar to ranger
