# gf3/dotfiles: a fish and Emacs configuration kept with yadm > gf3/dotfiles is one developer's day-to-day configuration, built around the fish shell and Emacs, and installed with yadm. The tool list is the argument: bat, delta, fd, fzf, glow, jq, lazygit, lsd, ripgrep and WezTerm, plus a JetBrains Mono font. **gf3/dotfiles** — Configurations for the tools I use every day - Repository: https://github.com/gf3/dotfiles - Stars: 1,126 · Forks: 112 - Language: Emacs Lisp - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/gf3-dotfiles ## One person's machine, published for reuse gf3/dotfiles is described in one line as configurations for the tools the author uses every day, and the primary language is recorded as Emacs Lisp, which is the most direct signal of what dominates the setup. The repository is a home directory, more or less. The top level tree is unusually short: `.authinfo.gpg`, `.config/`, `.gitconfig`, `LICENSE` and `README.md`. That is the shape of a yadm-managed dotfiles repository, where the git repository is the home directory itself and the `.config/` directory holds the tool configuration in the standard XDG layout. The screenshots in the README live under `.config/yadm/`, which confirms the yadm arrangement, since that is where yadm keeps its own administrative files. The licence is MIT, and the repository is not archived with the last push on 2026-09-22. There are no GitHub releases and, given the nature of the project, there never should be. A dotfiles repository is a snapshot of a working setup, not a versioned library, and the git history of the home directory is the versioning mechanism. What a reader gets is a working combination rather than an isolated artifact. The value is in seeing a toolchain that has been tuned together, in the knowledge that the fzf keybindings assume the ripgrep and fd that sit next to them in the list. ## fish and Emacs only, with the old versions in a branch The README carries a note that saves you time: these dotfiles are now for the fish shell and Emacs only. If you are looking for the bash, zsh, vim or neovim versions, the pointer is to version 2.2.0, which lives in the v2.2.0 branch of the same repository. That branch split is the interesting part of the project's history, and it is worth understanding before you clone anything. A dotfiles repository that supported four shells and two editors had grown into a configuration where the shell-specific parts were tangled together. Splitting into a v2 branch that keeps the old multi-shell setup and a main branch that is fish and Emacs only is a way of letting go of a maintenance burden rather than a feature. So there are two audiences for this repository, and they are different. If you use fish and Emacs, main is the one you want. If you use bash or zsh, the v2.2.0 tree is the relevant starting point, and it will not receive the same work. The configuration is described as designed to work out of the box on both macOS and Arch Linux, and as easily adaptable to other distributions. That is the promise of the design, and it is also the constraint to check: a setup tuned on two distributions will still contain absolute paths and platform-specific assumptions that only show up on a third one. ## Installing with yadm, or not The author manages these files with yadm, a tool that keeps a git repository in your home directory so version control applies to your dotfiles without a second directory to sync. The README is careful to say it is not required, and the fallback is simply to copy over individual files and directories as needed. If you do want yadm, the sequence is three commands: ```sh yadm clone https://github.com/gf3/dotfiles.git yadm status yadm bootstrap ``` `yadm clone` puts the repository in your home directory, `yadm status` shows what changed there, and `yadm bootstrap` runs the bootstrap process that the configuration defines, which is where the tool configuration gets applied to your shell and editor. The middle command is the one not to skip. Because the repository is your home directory, a clone brings in a `.gitconfig` that will replace or merge with yours, and an `.authinfo.gpg` file that is an encrypted credentials file for netrc-style authentication. Running `yadm status` right after the clone shows exactly what it changed in your home directory, and lets you review anything you would rather not keep. The README does not explain that file, so if you keep authentication material in your home directory, look at it before you start. Requirements are modest. NodeJS is not mentioned, because the toolchain in use is native binaries rather than a JavaScript runtime. ## The tool list is the real specification The README's tool list reads as a curated stack, and each entry says what it replaces, which is the more useful half of the description. For reading files, `bat` is described as a cat(1) clone with wings. For diffs, `delta` is a viewer for git and diff output. `fd` is a simple, fast and user-friendly alternative to find, and `ripgrep` recursively searches directories for a regex pattern, so the two cover file finding and file content respectively. `lsd` is the next generation ls command, which means the directory listing and the file search are separate tools rather than one. For the interactive parts, `fzf` is a command-line fuzzy finder and `lazygit` is a terminal UI for git commands. `jq` is a command-line JSON processor, and `glow` renders markdown on the CLI. `Qute` is a keyboard-driven, vim-like browser based on PyQt5, which is the one entry that pulls in a GUI toolkit rather than staying in the terminal, and `WezTerm` is a GPU-accelerated cross-platform terminal emulator and multiplexer. The pattern is consistent: replace a core Unix utility with a variant that is friendlier, and give the hard-to-script things a terminal UI. `fzf` and `lazygit` in particular are the tools that make the rest worth learning, because they turn the shell into an interactive application. `Fish` itself is listed as the user-friendly command line shell, and it is the shell the configuration targets. ## The font choice and the Emacs configuration The README names a single font: JetBrains Mono, described as a font designed for developers, with ligatures and powerline symbols. That choice is not cosmetic in a setup like this. Powerline symbols are what make the segmented status lines in a terminal multiplexer and in Emacs legible, and ligatures are what make the code samples in a `delta` diff view readable. A configuration built around tools that render inline status information depends on a monospaced font that has the right glyphs, and JetBrains Mono is a common answer precisely because it ships them. The Emacs side is where the repository's Emacs Lisp content lives, given that the primary language is recorded as Emacs Lisp, and the `.config/` directory is the place to look. The README does not describe the Emacs configuration in detail, which is the main gap in the documentation: it tells you Emacs is included, and it tells you the tool list around it, but not what the Emacs setup actually does. The same applies to the fish configuration. The README says the configuration is designed to work out of the box on macOS and Arch Linux, but it does not enumerate the key bindings, the functions or the plugin set that the fish and Emacs parts define. Reading those files is the only way to know what you are taking on, and it is also the fastest way to decide whether the setup is worth adopting at all or whether you would rather take the tool list and write your own configuration. ## Why this is a reference and not a dependency A dotfiles repository occupies an unusual position in the adoption landscape, and it is worth being clear about what kind of thing this is. It is not a library. There is no API, no version constraint, no semantic versioning and no changelog. It is not a tool either, since nothing here is executed for its own sake beyond the bootstrap process that applies the configuration. And it is not a curated distribution, because there is no selection process and no review of what goes in beyond one person's habits. What it is, is a worked example. A working fish and Emacs setup, with a coherent set of terminal tools, that a reader can clone, run and then modify. The `bootstrap` process is the interesting mechanism, because it is how the configuration claims to install the pieces it depends on, and that is what turns a pile of config files into something reproducible on a second machine. The limitation follows from the nature of the thing. Because it is a snapshot of one workflow, the parts of it that encode personal preference are indistinguishable from the parts that are necessary. The README's own list of tools is a good guide to the second category, since a `fzf` and a `ripgrep` configuration has reasons to exist, while a particular colour scheme does not. The MIT licence means you can take any of it into your own setup as long as you keep the copyright and licence notice, which is the right licence for this kind of project. Just do not expect the upstream to be a place you file issues about your dotfiles. ## Conclusion gf3/dotfiles works as a reference for a fish and Emacs setup rather than as a product to adopt, since it is one person's machine configuration with no releases, no changelog and no support commitments. It suits a developer who wants a working baseline for these tools and is willing to adapt it, and it does not suit a team that needs a maintained, versioned configuration, or a bash, zsh, vim or neovim user, since the earlier versions live in a separate v2.2.0 branch. Before copying anything, clone it with `yadm clone` and `yadm status` to see the untracked state of your own home directory first, and read the fish and Emacs configuration under `.config/` rather than assuming the tool list tells you what is configured. ## FAQ ### What is gf3/dotfiles? It is one developer's day-to-day tool configuration, a home-directory repository covering the fish shell and Emacs, published under the MIT licence with no releases. The tool list covers bat, delta, fd, fzf, glow, jq, lazygit, lsd, ripgrep, Qute and WezTerm. ### How do I install gf3/dotfiles? Using yadm it is three commands: `yadm clone https://github.com/gf3/dotfiles.git`, then `yadm status` to review what the clone changes in your home directory, then `yadm bootstrap` to apply the configuration. yadm is not required, since you can also copy individual files and directories over. ### Does gf3/dotfiles support bash or zsh? No. The current main branch is for the fish shell and Emacs only, and the bash, zsh, vim and neovim versions are in version 2.2.0 on a separate branch of the same repository. ### Which platforms does gf3/dotfiles support? The configuration is described as designed to work out of the box on both macOS and Arch Linux, and as easily adaptable to other distributions. The last push was on 2026-09-22 and the repository is not archived. ### What does the bootstrap process do in gf3/dotfiles? The README documents `yadm bootstrap` as the step that applies the configuration after cloning, but it does not describe the bootstrap script itself in detail, so reading the files under `.config/` is the way to see what the setup actually installs and configures. ## Sources - [gf3/dotfiles on GitHub](https://github.com/gf3/dotfiles) - [Issues](https://github.com/gf3/dotfiles/issues) - [License: MIT](https://github.com/gf3/dotfiles/blob/main/LICENSE) - [README](https://github.com/gf3/dotfiles/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gf3-dotfiles