Instead of installing a pre-built RPM, we can build it ourselves on the
spot instead. This is less maintenance for me and makes it easier to
verify the package being installed.
This should work, but it hasn't been tested yet. In the future I'd like
to use branches before pushing large updates to master. This would also
give me the chance to see how symlinks behave when a different branch is
checked out.
Here is the spec file I use to set up Fedora machines. It is located in
the PKGBUILDs directory since both my Arch and Fedora setups share the
same source files.
Here are the source files I package with my PKGBUILDs. The tari-scripts
directory features some color scripts from around the web. tari-urxvt
contains patches for urxvt, tari-util houses launch.c, and tari-web is
where my mozilla.cfg is located.
Instead of having one big PKGBUILD, I have opted instead to split my
Arch configuration into multiple PKGBUILDs.
Of course, splitting the packages *too much* has diminishing returns,
but some separation makes it easier for both myself and others to pick
and choose any wanted functionality.
These scripts can be manually updated by running the `make update`
command. When you do so, visually compare the diffs. This is to
ensure that nothing particularly naughty happened upstream.
Note that this is not a fool-proof solution since one can simply
modify the content returned by any other location a script requests.
This hasn't been tested yet, but it *should* work.
Most of the software I install is handled by the RPM, with the
exception of software not present in the official repositories.
The install scripts for these software are stored locally in this
repository since I want an easy way to keep track of the diffs. Of
course, you should run the `make update` command yourself to get the
latest updates and visually compare any differences from upstream.
I've gone through a lot of terminal emulators by now, and have always
switched between URxvt and Termite (due to the features they support).
For URxvt, this is particularly cumbersome since the version in the
official repositories does not have the patches required for practical
use. Even with patches applied, URxvt supports neither true color nor
emoji. Termite worked well, but it lacked image support.
Kitty features all of the following:
- True color support
- Image support
- Emoji support
- Icon fonts support
- Transparency support
Additionally, projects like Ranger and Neofetch have already taken the
initiative to support the Kitty image protocol (which, luckily for me,
are the only programs I use with images in the terminal).
Why not Alacritty, the other GPU-based terminal?
---
Although Alacritty is also very performant, there are several things
that keep me away from this terminal emulator.
Alacritty, as of this writing, renders neither images nor emoji.
Although it is certainly possible to use a terminal emulator without
either of these, the lack of these features limits what you can do with
the program you (presumably) spend the most time with on your computer.
The current config setup is "all or nothing"; I cannot remove defaults
from my alacritty.yml and expect those same defaults to carry over.
Even common terminal escape sequences are hard-coded into the config
file, which cannot be removed without breaking things.
Some other benefits of kitty:
- Full image support in transparent terminals
- w3m hack + loop is no longer necessary for persistent images
- No weird artifacts around the image
- Can highlight text without affecting the image
- Images aren't lost after switching between desktops
It turns out that even if your terminal supports true color, it won't be
used in tmux unless you set the option explicitly. Now it is possible to
enjoy the benefits of true color inside tmux.
Since tmux is only a problem when using neofetch with the w3m image
backend, I have instead added a new keybind to handle this use case,
which floats the terminal by default as well.
After a considerable amount of research, I finally understand how to use
chmod and what file permissions in linux actually mean.
It turns out that git can commit both regular files (644 permission) and
executable files (755 permission). This is great since changing file
permissions manually after a git clone is no longer needed.
This useful feature is enabled by default, however, it seems like I
disabled it a long time ago. If this is you, simply re-enable it by
setting `filemode` to true in your .git/config.
This commit makes it possible to toggle any terminal you want with
super + backslash. If the terminal doesn't exist already, it will
be created for you.
Made dependency lists a bit more consistent and reverted some of the
Arch Linux wording since it felt a bit off. Even the official website
refers to Arch Linux as Arch from time to time.
Instead of having a separate repository for each rice, I can instead put
them in this repository (prefixed with ., so that they're not indexed by
the stow Makefile).
Realistically, you won't need my wal config if you are not using my
bspwm setup, since wal does a good job at otherwise changing most other
color schemes that you may find in, e.g., a GNOME or Plasma setup.
Realistically, you'll be using neither termite nor urxvt if you have
access to a desktop environment since those usually include their own
terminal emulator that works out of the box anyway.
Additionally, many of the benefits from termite and urxvt are not a
necessity in other desktop environments.
Now that all the READMEs have been added, all that's left is to polish
them as time goes on. It may be useful to add images to each of the
package directories to show visually what each contain.
Also, after some testing, it turns out that my previous assumption about
systemd was wrong. Placing a service in default.target.wants directly
will cause the service to instead not be recognized by systemd.
Note that systemd usage information needs to be revised since systemd
user units appear to be enabled by default, and may be started by
default when placed in the default.target.wants directory.
Since I'd like other people to try my dotfiles, I will be writing
READMEs for each package directory, which should hopefully cover
anything a user needs to do in order to use the package.
