Although alacritty is an amazing terminal emulator, I am not interested
in maintaining configuration files for it at this time.
The current config works and is an excellent replica of the current
kitty config. If you have a desire to use alacritty, you can use the
files in this commit to get amazing support for things like pywal.
The reason alacritty is being removed is because it doesn't fully
support fcitx. Currently "inline input" doesn't work in Xorg, and it's
impossible to see input under GNOME Wayland.
For simplicity, only the terminal emulator that works the best for me
will be officially supported, since I've never had a reason to use
alacritty anyway.
Source: https://github.com/alacritty/alacritty/issues/1613
This likely fixes an issue I had earlier, although I don't remember what
it was. In any case, this change is a positive one since toggling the
bar is now instantaneous as well.
Although recoloring documents is great for rice screenshots, most of the
time we want to see a pdf in its original form before deciding to
recolor it. Most of the time recolors occur when a "dark mode" is
necessary, which zathura does a good job with.
Previously ale would show an error message when dealing with JavaScript
files without an .eslintrc. That has now been fixed and standardjs works
as intended.
This is no longer needed since I plan to focus fully on bspwm instead.
Note that I may still use GNOME on multi-monitor setups and other
devices where having the convenience of bspwm and sxhkd isn't necessary.
Since I've decided to ditch sway, I no longer have to deal with waybar
either, which is nice. Although waybar is nice-looking, there isn't much
of a difference between it and polybar in day-to-day usage, and other
factors such as ease of maintenance are far more important.
Although using a Wayland window manager was cute, Sway always felt like
a gimped version of bspwm to me. This is likely due to many of the bspwm
features I use, as well as certain X applications not working well under
Wayland (such as feh).
I am also not interested in maintaining the config for Sway, and prefer
bspwm's approach where it's configured through bspc and shell scripting.
In summary, "after all these years", Sway is still more trouble than
it's worth for me personally, and I'd rather invest that time focusing
on my existing bspwm setup, which has always been pleasant to use.
Similar to bspwm, all keybinds are now handled with super to avoid
conflicts with other applications. In the future it may be useful to
replicate the rest of the bspwm environment under sway.
I've been trying to like vscode for years, especially since it was
widely regarded as one of the best editors of all time. As cool as VS
Code is, however, I always ended up using neovim and a terminal since
it's simply easier for me to get things done that way.
Although using mpd was a cute experience, I am not interested in
maintaining mpd on my systems anymore since navidrome does the job just
as well and has more useful features.
Although using ncmpcpp was an interesting experience, I now value the
convenience of software like navidrome more than the minimalist traits
of ncmpcpp. Realistically I should never encounter a time where
listening to music within a terminal interface is mandatory, and simply
using a web interface with optional apps drastically simplifies things.
9 months later and I am no longer interested in maintaining lunarvim. My
current neovim config does everything that I need it to do and I don't
see myself using anything else anytime soon.
I am not performing tasks that require constant knowledge of the CPU and
RAM being used, and if I am, I can use a tool like htop instead, which
would avoid the distraction of the bar numbers constantly changing.
This fixes an issue where the previous keybinds would conflict with
other applications, and reinforces the idea that all system-wide
keybinds use Super.
I've used fcitx for a while but never committed my actual config for it.
Note that this config is relatively old, and I'll be updating it with a
new commit to make seeing the changes easier relatively soon.
Having gnome settings was cute, but realistically the desktop
environment should automatically choose the best settings for the target
computer. Manually change anti-aliasing goes against the idea of wanting
the stock GNOME experience.
