Fixes an issue where newer versions of zathura changed how colors were
specified. Should eventually be fixed upstream in stylix, but we're
using the Kvantum fork for theming support in Qt applications.
Based on the upstream pull request with a preference for 0.3 highlight
transparency over 0.5.
`deno add` is now preferred over `deno install`. Additionally, `deno
compile` doesn't work on NixOS, and creating a derivation should be
preferred instead.
This actually isn't that useful and has some bugs where errors are shown
and the neovim tree window is used instead of the active window with the
CSV file.
This is part of migrating scripts from ~/.local/bin to the nix-config.
Note that this also lets us use packages that aren't available in a
user's $PATH.
This guarantees that auxiliary files won't be present in the current
directory from latexmk, and encourages reproducible pdfs with the usage
of tectonic.
Although typst is an interesting project, TeX has vastly superior
typesetting and a significantly larger repository of existing packages
and knowledge to extend upon.
I faced auto-updating issues with typst that weren't present with
vimtex, and TeX in general has better support for auto-completions due
to its \backslash usage.
It turns out that I'd rather have a battery indicator than having to
`cat /sys/class/power_supply/BAT0/capacity` all the time.
Depends on upower and results in the battery indicator always being
shown even when virtualized.
Will be focusing on npm instead since tooling is excellent and I'd
rather have a package manager that's old, reliable, and just works
than a newer one that might be missing a feature I need.
This is a part of having separate flake.nix files for each project
and using devShells for the dependencies needed.
Note that using Crystal as a language seems less likely overall due to
the difficulty of building Crystal packages for nixpkgs and the lack of
tooling and library support compared to other languages like TypeScript
and Rust.
I originally thought I was going to use bun, but it turns out that there
are simply too many inconveniences compared to using npm itself, which
includes built-in nixpkgs support with buildNpmPackage and vastly
superior shell completions among other things.
Rust programs are easy enough to install The Nix Way so there's no real
reason to put .cargo in $PATH, especially when programs that have
dependencies like openssl won't work this way.
It turns out I don't use deno nearly as much as I thought I would,
especially when the current node ecosystem works so, so well in
comparison.
I also haven't encountered any deno-specific programs that would be
worth installing globally.
Shouldn't be needed since I'm no longer interested in long-term Go
development. For when I *do* need to use Go, those packages can be
built as Nix derivations.
vim-prisma currently has an issue where the syntax highlighting gets
messed up as one scrolls. The treesitter version doesn't have this
issue, which makes it more pleasing to work with.
Note that Vue tooling is seemingly subpar compared to React + TypeScript
so despite learning Vue first (and Angular.js before that), I don't
think I'd ever want to work with Vue again after getting familiar with
functional programming and React.
I never used this and it seems to cause more issues than it's worth.
It's easier to simply hide the tree on the left and manually adjust the
size of the kitty window.
This fixes an issue where syntax highlighting was fixed upstream, which
broke my workflow since I was using the changing colors of the plugin
to determine when the LSP was loaded in. I also liked how it syntax
highlighted valid identifiers a different color than invalid ones.
See: https://github.com/RRethy/base16-nvim/pull/96
I'll still use pnpm when I *need* to, however the lack of support for
pnpm in nixpkgs is a show-stopper I'd rather not have to deal with when
npm works out of the box.
pnpm was originally used for faster install times and pnpm workspaces,
however npm now has its own workspaces and I'm okay with slower install
times if it means that everything works without fragile workarounds.
Yarn has been outdated for a while now, especially with the failure for
new projects to switch to "berry" among other things. I should never
need to use it again, but if I do, I don't need the abbreviations.
Yarn was originally used for yarn workspaces and faster install times.
Nowadays, however, other package managers are able to do both in more
efficient ways.
Apparently dropping "Yet Another TypeScript Syntax" makes the startup
time of Neovim about twice as fast. This was originally added to fix an
issue with "type" annotations in imports being incorrect, although this
appears to have been fixed now.
From a cursory glance, there seems to be no difference between yats-vim
and the treesitter syntax highlighting I use, so it should be fine to
drop this for the massive performance gains.
The latest treesitter changes actually make using it better than the old
vim-nix-rummik solution. Syntax highlighting works quite well for the
/* lang */ code blocks.
I am no longer interested in developing Dockerfiles or
docker-compose.yml files since I am fully committed to Nix.
By sticking with one technology that gets the job done, it should be
more efficient for me to solve problems with that one domain of
expertise than having mediocre knowledge of several similar tools.
The hype has died down and React has emerged victorious, as expected, in
a battle that never started.
Joking aside, I don't remember the last time I've seen a svelte app
and even if I *did* come across one, I'd much rather work with standard
file types like TypeScript and TSX, of which this neovim config has
first-class support for.
hycov is being updated again, which is cool, but I couldn't make the
latest version work with the hyprland overlay I'm currently using, and
I'd rather not have to worry about all the additional inputs from the
hyprland flake.
Overall I recall using it a lot at first, but then rarely if ever as
time went on. Once 0.39.1 gets merged into nixos-unstable, it will be
interesting to see how hyprexpo compares to hycov.
Not sure why I added this but it seems like I have pretty great support
for markdown files without this, and I'd rather leverage my existing
toolkit of tools that do one thing and do it well.
Not needed since we can just reference the background directly instead.
Note that the linking actually occurs in the modules for the DEs that
add backgrounds since it isn't part of the defaults.
