🚀 go-pugleaf

Basic:

Global replace "~/.emacs" with emacs-personal-startup-file, initialised by

(defvar emacs-personal-startup-file (or (getenv "EmacsInit") "~/.emacs")
  "Name of user's personal startup file, read in by Emacs between
site-start.el and startup.el and used as the root for names of all other
personal startup files for dependent applications of Emacs.  Initialised
from environment variable EmacsInit if set, otherwise taking the default
value ~/.emacs")

General:

In fact, replace every dependence on a file named ~/.something with
dependence on a file named in an elisp variable defined as above and,
where possible, initialised from an environment variable with default
~/.something if unset.

Document the environment variables and elisp variables in the same
places, or at least cross-reference them.

Make sure these things get used consistently; thus, the shell-specific
startup files would be (concat emacs-personal-startup-file "_" name)
where name is the shell-name.  If something could sensibly be named from
an environment variable but its default is ~/.emacs_something, then use
(or (getenv "EnvVar") (concat emacs-personal-startup-file "_something"))
as appropriate.

Reason:

I want to be the one who decides what goes where in my filespace.

Another user might find the way I lay things out counter-intuitive (in
fact, the first to come to mind _does_), but I have my own clear ideas
on how I want to organise things.  Given the opportunity to do so, I'd
organise my file-system on largely hierarchical lines which would make it
easier for me to find things.  There is a standard system for doing this.

The widely used Un*x convention of starting things up based on a
`hidden' file in the home directory implies a disgusting approach to
organising a file system -- namely, the monolithic flat `directory
structure'.  It gets round the primary defect of this system (the
relevant directory has so many files in it that listing it produces so
much output that it ceases to be possible to see files in the listing)
by making the crucial files `hidden'.  This then means that common users
don't know the files are there, which leads on to its own kinds of ills.

There is a (less) widely used Un*x convention of depending on
environment variables.  This produces the ghastly phenomenon of an
overloaded environment but at least gives the user choice.  In
particular, those of us who strive to have a tidy directory structure
(wherein each non-`leaf' directory contains a dozen or less files; and
wherein the way that files are arranged is based on some kind of logical
system, preferably at the whim of the soul whose filespace it is)
actually have the option of putting things where it makes sense (to the
warped sensibilities of each) to put them.

Aside from the init files for login shells and one or two equivalent
systems (eg .rlogin, .netrc ...), _no_ system has _any_ excuse for
insisting that I choke up my home directory with its datafiles.  In
fact, even the init files for login shells only have an excuse, not a
reason -- the originators of Un*x didn't think to put an init file into
the collection of things (like SHELL) that I can control in /etc/passwd
(which is, I think, the analogue of how DCL handles LOGIN.COM, which I
think it allowed me to move to where I wanted it ...).