This commit reduces the debug log noise, makes it easier to
read/parse/search, and soft-introduces a convention for doom-log
messages, where they are prefixed with a unique identifier loosely named
after it's running context or calling function.
I haven't enforced it everywhere doom-log is used yet, but this is a
start.
- Deprecates the doom-private-dir variable in favor of doom-user-dir.
- Renames the pseudo category for the user's module: :private -> :user.
- Renames the doom-private-error error type to doom-user-error.
Emacs uses the term "user" to refer to the "things" in user space (e.g.
user-init-file, user-emacs-directory, user-mail-address, xdg-user-dirs,
package-user-dir, etc), and I'd like to be consistent with that. It also
has the nice side-effect of being slightly shorter. I also hope
'doom-user-error' will be less obtuse to beginners than
'doom-private-error'.
Some of our comments/docs can come off as disparaging or snide. They're
glimpses of unfiltered frustration or snarky rubber ducking gone too
far, something I can totally sympathize with, as a scatterbrained
tinkerer, unwittingly made responsible for a lot of work that isn't mine
because of Doom's position as a middleman. But now that Doom has a
veritable userbase, I'd like to hold it to a higher standard.
Light-hearted banter and aired grievances in our source code,
documentation, or community are fine if focused on the problem or the
personal/shared experiences of the community (things that offer value or
amusement to others), but it is never acceptable to attack people or
their efforts. Especially not the very people on whose shoulders Doom
stands.
I sincerely apologize if these have offended you.
Amend: b07614037f
A regression introduced in 1d8c61698b. Doom disables its
file-name-handler-alist optimization if in a daemon session or if debug
mode is active.
Fix: #6657
Amend: 1d8c61698b
See 6f1c0f7cc7 for part 1.
Turns out startup.elc likely exists on most Emacs installations (and,
since it's so integral to Emacs, it likely gets special treatment), so
it was a poor heuristic for this fix. Instead, a more variable target
would be calc-loaddefs.el.
On some systems, only calc-loaddefs.el.gz exists (in which case, we
should turn off the optimization). On others, calc-loaddefs.el
exists (so I'll assume it's safe to leave them on). I won't check for
calc-loaddefs.elc because it doesn't matter; calc.el explicitly
calls (load "calc-loaddefs.el") so it is never loaded.
Of course, you can sidestep the entire issue by building Emacs with
--without-compress-install, but it's not practical for users to
know/want to do that.
Amend: 6f1c0f7cc7
Some installs of Emacs do not come with byte-compiled versions of its
bundled elisp files, so when loading them, Emacs falls back to loading
its *.el.gz files. This would be fine if it were not for a startup
optimization Doom employs, where it sets file-name-handler-alist to
nil (and by doing so, robs Emacs of the ability to read compressed
elisp). This causes "symbol's value as variable is void: \213" errors at
startup.
With this commit, Doom now disables this optimization early if it
suspects this applies to your install. But time will tell if it's early
enough.
Ref: https://mail.gnu.org/archive/html/emacs-devel/2022-08/msg00234.html
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
