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.
"Desktop" was a really generic package name that didn't describe the
contents of what it contained. Since we already have a catch-all
directory (extras), I separated "desktop" into what it actually was:
settings for urxvt/termite and settings for xmodmap.
Some other programs may also use xrdb. The only reason the term files
are not in the bspwm directory instead is because it may be useful to
use urxvt or termite in non-bspwm environments.
It is now possible to install only a specific set of dotfiles instead
of everything at once. To do this, simply run make and set the "package"
variable from the shell. For example, to only stow my vim config, use
`make package=vim`.
The desktop directory is used for desktop-related things that may be
useful outside of bspwm (such as caps lock functioning as ctrl +
escape). Whether or not this is needed is questionable, but it is an
option for now.
It may be better to further split these directories and avoid the
generic word "desktop" altogether.
Previously I wanted to stow everything at once, but now that I know how
to use Makefiles a bit more, I can still stow everything at once with
multiple directories. Additionally, this allows people (myself included)
to only stow the dotfiles they want, such as only vim or only fish.
Instead of separating *every* file into its own directory, I've opted
instead to group common configs together and only use separate
directories where they make sense (e.g. a vim config).
Since padding-left and padding-right will always be the same in this
case, I've gone ahead and made it simply "padding".
Since keys can use the values from other keys, some duplication in the
module sections can be avoided.
Having a monocle-like layout on a tiled desktop layout is more
confusing than it needs to be. If single_monocle is ever needed,
it can be manually set on-demand instead.
Setting the file type of a file is different than simply changing its
syntax. In this case, the rofi config was treated as a real .java file.
By setting syntax explicitly, we avoid re-declaring the filetype.
Since urxvt and termite now look very similar to each other (except for
transparency), and since images do not play nicely in tmux / transparent
windows, it makes sense to separate tasks between the two.
Sometimes you may want to use an editor that is Not Vim. Although such
an editor may be feasible for the majority of users, an editor that is
Not Vim will not behave exactly like Vim, even with plugins.
Existing Vim users should not try to use Code as an editor. It is
instead a useful editor for when someone needs to use a Non Vim editor
on your machine (although you certainly should *not* condone this).
Code does, however, feature a useful file explorer that requires no
configuration nor maintenance to use. It just works.
Since launch.sh calculates all the bar values for us (as well as bspwm
settings), we can simply store the top_padding value in the user's cache
directory, then reference that number within sxhkd.
This way, if the top_padding value is changed through launch.sh, editing
sxhkdrc manually isn't needed, and the config file doesn't need to be
reloaded.
Although width can also be found through xrandr, it felt a bit messy to
parse output that wasn't meant to be parsed by other programs.
Since I can guarantee that the user will have bspwm (and not xrandr)
installed, I decided to use bspc instead. The current setup only works
for one monitor, but it should be relatively painless to setup multiple
monitors in the future (assuming they share the same dpi).
Since polybar supports include files, we can generate part of the bar
config with launch.sh and store it in $HOME/.cache. Since launch.sh is
a shell script, and since bspc is an interface to bspwm, we can also
change the necessary window manager settings required for different
bars, or even configure the settings for no bar at all.
A future implementation of launch.sh may allow us to change polybar
dimensions based on current resolution and whether the screen is HiDPI
or not, although it probably won't be *too* fancy since I don't need to
support every potential DPI a user may have.
Alternatively, someone could submit a patch for polybar to make it
DPI-aware. This is the ideal solution since the bar would be scaled
naturally based on dpi, instead of having to manually halve things
ourselves.
I used to not know much about shell scripting, but now that I do,
polybar-specific bspc commands can be handled through the launch.sh
shell script instead of directly from bspwmrc.
This lets us launch different bar styles with different bspc options, or
even set styles for no bar at all.
