Since kitty would automatically assume a fullscreen or half screen size
as the default, it's much easier to simply specify the size all floating
windows should start out as.
Since kitty allows specifying the size in cells instead of pixels, it
is easy to achieve the same "actual" terminal size regardless of which
DPI is being used.
It turns out that placing similar config files (i.e. bspwm-related) in
the same directory is not the way to go about handling dotfiles since
each config file (or dotfile) *should* manipulate only a single program.
This was not the case back when I used urxvt (which would require the
old method of .Xresources), but now that I understand more about how
*modern* dotfiles work (with $XDG_CONFIG_HOME), separating dotfiles by
program became the obvious choice.
Instead of running two systemctl commands (start and enable),
one can simply use `systemctl enable --now` instead.
The grub command was removed since I never used it and haven't
found a need to do so.
Now that I've learned kitty, other terminal emulators like termite and
urxvt are no longer necessary. Here I remove any config files that were
necessary for either termite or urxvt and change all terminal options
to kitty.
As an added bonus, a global gtk.css file is no longer necessary. This
contradicted a core idea of dotfiles (that every program should have
its own directory in $XDG_CONFIG_HOME) and was in general a weird hack
that also affected non-termite emulators.
It turns out that kitty has support to change all of its colors
independently from the current terminal with a simple command. This
was the only issue I had with making pywal and kitty work together,
so I'm glad I found it.
Additionally, kitty supports DPI changes immediately (at least with
xrdb). There is no need to detach a session and open a new terminal
since kitty will handle DPI changes automatically, compared to other
terminals like urxvt, which would require a new instance. Even then,
the border padding for urxvt is not adjusted to the new DPI; kitty
is simply the way to go if your monitor setup is non-trivial.
As a side note, the kitty documentation is very good. I highly
recommend reading it if you plan to use kitty (which you should).
Instead of "hiding" dotfiles in an extra group, it is easier to use
separate packages for each unique set of files. Since I'm working on
making my setup more modular, and since I can stow all my dotfiles with
a single command anyway, this configuration is more appealing now.
I removed termite before, but this time I shouldn't need to add it
again. The kitty terminal emulator supports image output and handles
fonts better than termite. Plus, true transparency can be used without
sacrificing images in the terminal.
Since the wal color scheme is not installed until PlugInstall is ran,
the colorscheme function will always throw an error that needs manual
intervention. This fixes that.
Since sudo times out after 5 minutes, and since we don't want to run
every command as root, we can instead create a "persistent sudo" by
invoking the sudo command at least once within 5 minute time frames.
This script does just that, and solves the problem of sudo timing out
after a long command.
It turns out that since tmux sessions will stay active after you close a
terminal window, it is easy to end up with a lot of empty sessions. This
makes it difficult to detach and re-attach the appropriate tmux sessions.
Additionally, some features of kitty (notably terminal images and
dynamic background opacity) will not work inside tmux. Since kitty has
its own window manager, this caveat can be easily circumvented. By
invoking tmux manually instead, we also avoid the problem of nested
tmux sessions.
Since changing the default shell to fish without breaking Fedora with
GNOME is non-trivial, I instead set the option from the terminal
emulator itself.
Although this won't carry over to ttys and other environments, it should
be simple enough to start fish manually when needed.
Since the community package doesn't include the fish completions found
upstream, we install them here instead. There is already a bug report
about the fish completions, and when it eventually gets fixed, these
steps can be removed from the PKGBUILD.
Bug report: https://bugs.archlinux.org/task/55786
Since dotfiles only change the functionality of existing programs, it is
reasonable to stow everything at once for consistency between operating
systems.
Although there's already a default terminal emulator, configuring it
through dotfiles is non-trivial. kitty works exceptionally well on
Fedora, and since I already use it on Arch Linux, I might as well
use it here too.
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.
