vs-wal has some issues such as illegible text and no live reloading,
however, it is (from what I know) the easiest way to use a color scheme
consistent with your setup.
Code will use the default dark theme if vs-wal is not found.
Since my dotfiles are now sorted by individual programs instead of in
groups, I'm trying a new README format. This format should provide more
useful information and be easier to read as well.
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.
