My User Home Directory Configuration

As used for my personal laptop.

Noteworthy Aspects

• Some configuration for tools, and some unique abilities, some of which (but not all) are described below.

---

• Substantial Emacs configuration with workarounds for prominent bugs in TRAMP, LSP, and Magit.

• Custom Bash history handling that archives each session's separately while still starting each session with its initial history being the combined histories of all sessions. The grouping of each session's history is preserved in the combined. Removal of duplicates and of user-specified ignores is done in the combined. Extra effort is made to be robust with multiple concurrent sessions and with other aspects.

• Custom Bash prompt.

  

• Partitioning of SSH multiplexing, so that particular functionalities benefit from connection sharing within a specific functionality, but so that sharing is not done across separate functionalities in order to avoid one's accidentally crashing another's connections. This is configured for Emacs for TRAMP's /ssh: and /vagrant: methods, and for my-deploy-setup, and for optional general use.

• Setup to analyze and browse the source-code of The Rust Programming Language itself from Emacs. This is especially useful for studying or debugging The Rust Standard Libraries (either directly or when stepping into a custom toolchain's used by a project). This requires special configuration of lsp-mode and rust-analyzer (similar to what is done for VS Code to do this). This works best with a few tweaks to a rust-lang/rust directory.

• GDB commands for generating LLVM (Clang, Rust, etc.) code-coverage reports multiple times before a process exits, which is useful to see the current coverage of a program before something else happens to it, and which is useful when injecting function calls (and other alterations) via GDB to conduct spontaneous tests and iteratively exploring the coverage effects.

• Automatic setup of GDB to find debug-info and source-code in dedicated per-user or system-wide temporary directories, including for non-Home-Manager non-NixOS platforms.

---

• Can deploy itself to a remote user's home directory, in various POSIX OSs, by invoking a single command that automates bootstrapping this. Desirable for easily having my personal setup in different hosts. This command is automatically invoked for my Vagrant VMs, and is also intended to be invoked for remote machines (e.g. manually when working with preexisting machines of a company, or automatically (or manually) when provisioning a new machine).

• Platform-specific detection that installs packages and configures things to be the same or similar in different OSs. Based on a pathname scheme for uniformly and hierarchically locating platform-specific and architecture-specific parts, based on a scheme for identifying different platforms.

• Currently supports: FreeBSD, Linux/Alpine, Linux/Debian, Linux/NixOS, Linux/Ubuntu, NetBSD, and SunOS/OpenIndiana. Further support for other POSIX OSs can be added in the future.

• Works when a home directory is simultaneously shared across multiple machines of different OSs and different CPU architectures. The installation and configuration of some tools is also setup to work for this, e.g. GDB's, Cargo's, Emacs', and some others.

---

• When in NixOS, incorporates Home Manager, with configuration for MATE Desktop, Firefox, Emacs, Rust, and more.

• When in NixOS, integrates with, and uses some of the options of, my NixOS configuration. Provides the "skeleton" for new user's home directories, giving reproducible consistent user environments that can be tailored per-user.

• When in NixOS, uses KeePassXC for automatic entry of: website passwords; SSH key passphrases and adding to ssh-agent; and as the Secret Service (D-Bus API) (instead of GNOME Keyring or KDE Wallet) which is further used for: Git credentials; NetworkManager (wifi, VPN) passwords; GnuPG key passphrases (via the pinentry program); etc. Premade template DB and browser settings, to help a new user get started with this consistently.

• When in NixOS, provides extra support for debugging of binaries (executables & libraries) installed by Nix packages (pre-built w/o rebuilding or locally-built) according to your choice. Options for Home Manager to configure all this.

---

• When in OpenIndiana (and potentially Oracle Solaris), has tools installed, enabled via building with my patches, that are not usually available for this platform.

---

• This repository enables both: sharing changes between multiple users (via the main branch), and tracking private per-user dot-files (in private per-user branches).

• Companion support script for easily setting this up for new users, with hidden ~/.git so that home directories normally do not appear as repositories (which is normally undesirable). The dot-files remain a working-tree checkout of each user's repository.

• Companion command for temporarily unhiding ~/.git, for working on dot-files changes.

How to Try

If you'd like to try my setup (which, beyond having the "dot" files, also installs some packages and also records the preexisting contents of the home directory):

From a checkout of this repository:

REPO_DIR=de-dotfiles
git clone --branch=main https://github.com/DerickEddington/dotfiles.git $REPO_DIR

To a remote user's home:

#VERBOSE=5                                                          \
MY_DEPLOY_SETUP_DOTFILES_FROM_REPO=$REPO_DIR                        \
XDG_DATA_HOME=$REPO_DIR/.local/share                                \
  $REPO_DIR/.local/bin/my-deploy-setup ssh://[USER@]HOSTNAME[:PORT]

The target remote host should be a fresh VM (see the previous section above for which OSs are supported), and the host that clones the repo and runs my-deploy-setup could also be another fresh VM, so that you don't mess with your own hosts and users' homes, and so that you don't have to trust my code.

Or, you can do all the above cloning and deploying commands in only a single host (which could be a fresh VM), by placing the clone outside of the target home dir (so it's not captured), and by replacing the ssh://... with dir:$HOME (so it targets the home dir in the same host).

You can see that my-deploy-setup prepared a branch for the user's future changes to the home dir configs and that the preexisting contents of the home dir were recorded as a tagged commit in the history and then the new contents were merged with that:

user@target ~
▸ with-unhidden-gitdir  git log --all --graph --oneline

From a user's home that already has my setup installed, it's easier to deploy the main branch (or the user's branch) to some other host:

user@target1 ~
▸ my-deploy-setup $TARGET2_URL