There really isn't a reason to use pug or ecr in 2024 when the
development experience with JSX/TSX is so great, and sticking to
what's popular makes it easier for other people to contribute.
I haven't used Vue in years and have much more expertise in vanilla
JavaScript/TypeScript with React and JSX/TSX, so there's really no
reason for me to keep it here.
As much as I love reading the Crystal programming language, it's clear
that there are more opportunities to be had with prioritizing Rust
instead. The ecosystem for Rust is vastly superior with higher quality
libraries and an LSP that's actually feature-complete, and I'd rather
deal with the known problems I'm aware of with Rust than the problems
I'm aware of with Crystal.
Rust won. Joking aside, the ecosystem for Rust is vastly superior, even
if the language is more difficult.
Having to change the package list in two places was a bit redundant. We
can also use `with` patterns now since nixd warns if there are escaping
variables being used.
Note that variables used in multiple places are kept to make it easier
to recognize that those variables must be changed together. Also note
that inherit (pkgs) inside of mkMerge are currently kept to reduce the
diff.
Prevents the desktop entry from showing in applications like Thunar.
Long-term this isn't a viable solution since it prevents the hidden
applications from being used by Thunar.
- kanjidraw: Online alternatives with radicals etc. are better
- dmenu-wayland: Breaks with multiple monitors
- obs: Easier to use wf-recorder
- wallust: Easier to use stylix
Seems to fix an issue where WebRTC was previously broken in
ungoogled-chromium. Note that `default_public_interface_only`
is used instead of `default` to prevent local IP address leaks.
Might be able to use swaync after all if I avoid using the mpris module
with it. This has the advantage of being supported by ironbar, which
would make missing notifications less likely.
Alacritty has vastly superior touch support compared to kitty, which
doesn't feature touch support at all. The simplicity of Alacritty also
makes it faster and overall cleaner to use than GNOME Console (kgx).
This *shouldn't* have changed anything anyway since `man git-web--browse`
suggests that only a subset of browsers are supported anyway, which
doesn't include librewolf.
This was my attempt at using the volume module, however I'd rather not
have to deal with using the small sliders that are extremely difficult
to see with the GTK theme I'm using.
I tried changing the colors with color, background, and border-color,
however I wasn't able to achieve the appearance I wanted, and disabling
the built-in popup results in a buggy left-clicking experience.
Will stop trying to make Hyprland work on mobile devices due to all the
issues with it for now.
For future reference, some issues include:
- Touch events not registering as touches, thus breaking applications
that have touch support like LibreWolf with FriendlyFox.
- OSK support in general being not there yet with the best keyboard
Squeekboard not working and wvkbd not being comfy enough to use.
- Screen size in general being small already so having multiple apps
side-by-side is mostly useless, especially when the OSK interferes
with this as well.
This worked but broke when changing the display from e.g. 200% scaling
to 100% scaling. Since being able to easily change the scaling of
Hyprland was one of the main reasons I wanted to try Hyprland over
Phosh, I don't really have a use case for Hyprland on touch devices at
this moment, especially with all the drawbacks of using it on such a
small screen and without hardware acceleration.
Squeekboard was misbehaving so I thought I'd have better luck with
wvkbd, but it turns out that this isn't the case. For some reason,
nothing can be typed at all which is even worse than Squeekboard.
Shouldn't be needed anymore now that we're using the latest stylix
commit. Note that I don't care enough about this to use 0.3 highlight
transparency instead of 0.5.
This was significantly increasing start time and I didn't use it too
much. There should be lighter alternatives out there that aren't
packaged in nixpkgs.
Avoids having a separate home module just for packages and makes
essential tooling accessible in all shells.
Note that the legacy `texlive.combined.scheme-full` was replaced with
`texliveFull` in this commit.
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.
