Some doom commands will generate a temporary script at
~/.emacs.d/.local/.doom.sh so that it can run an arbitrary shell command
after the current invocation of bin/doom ends. Very useful for, say,
restarting the currently running doom command after a destructive
operation, like updating Doom's source code, tangling your literate
config, or for launching arbitrary programs, like a new instance of
Emacs. This is necessary because elisp lacks an execv implementation.
However, for some folks, .doom.sh wasn't executing at all. This meant:
1. Some `doom upgrade`s would upgrade Doom itself but never move on to
the second step of the process: updating its packages.
2. Literate config users could tangle their configs on `doom sync`, but
the actual syncing process would never happen (#3746).
3. `doom run` would do nothing.
I hadn't realized /bin/sh runs bash in POSIX mode (at least, on systems
where /bin/sh = bash, like nixOS or macOS). In POSIX mode the script
will abort the if a builtin command (like export) returns a non-zero
exit code. Since .doom.sh is basically a bunch of exports followed by an
arbitrary command, and there are some environment variables
that can trigger validation errors (like UID triggering a "read-only
variable" error), we have a problem.
Hopefully addresses #3746
The user's private packages.el is read first, to ensure disabled
packages are recorded as soon as possible, however, this means private
packages are recorded early into `doom-packages`, and so are built
first (and thus, before org-mode, which is later registered by the
lang/org module).
This compilation order can cause lots of issues with org packages
loading the older, built-in version of org included with Emacs, instead
of the newer org-mode.
May address #3172
To add support for "update 11", see:
http://akrl.sdf.org/gccemacs.html#org4b11ea1
Also:
+ Move eln files to ~/.emacs.d/.local/cache/eln
+ Disable comp-deferred-compilation by default (now that it is
enabled-by-default upstream).
As Ubuntu does not include mu4e with the mu package I added a step to
tell the use to install mu4e and add it to their load-path. I have also
added a find command to find the directories likely to have mu4e in them
On closer inspection it isn't necessary to expand the gitk and perl
executable paths, since a) gitk is a GUI application that doesn't get
called often enough (only once at a time) to warrant being optimized,
and b) magit uses it to set an envvar for git (so git itself handles
locating the executable internally -- much faster than Emacs can (esp
over TRAMP), so it only benefits us to expand magit-git-executable.
This allows users to jump to treemacs with ace-window, but when opening
files from treemacs with treemacs-visit-node-ace-* commands (e.g. on
oaa) it doesn't make sense to open files in the treemacs window.
