...that are always enabled. This way, the module API treats them as any
other module.
This also changes doom-module-load-path. If supplied directories,
doom-user-dir will not be the CAR of its return value. If no dirs are
supplied, then doom-core-dir and doom-user-dir are included (and will
always be the first two items in the returned list).
For small amounts of data, symbol plists are the most efficient (space
and time wise) as data access gets in Emacs. Hash tables, though O(1),
impose a minimum threshold of overhead before it becomes the efficient
option, but this benefit won't be obvious for datasets of at least 60 or
less.
Since modulep! is used *a lot*, and used to determine a module's
state (and state of its flags), there is a benefit to caching it.
Still, this is only a read-only cache, and does not replace the
`doom-modules` hash-table, which will always be the preferred interface
for the rest of the module API.
- Rename doom-module-path -> doom-module-expand-path, to better reflect
its purpose.
- Optimize doom-module-locate-path to try caches and
locate-file-internal, before looping through doom-modules-dirs.
- Rely on file-name-concat to join paths, rather than string
concatenation. file-name-concat is more robust for the purpose and
has lower overhead than expand-file-name.
- Add a 27.x check, recommending that users upgrade to 28.1.
- Removed the check for <27. Loading doom.el with sub-27 will already
fail with a detailed error about supported versions.
- Now detects development (.50) and pre-release (.9x) builds of Emacs,
and warns the user of their dangers.
- Revises the warning for 29+ or .50|.9x users.
This refactors how Doom captures and redirects its output (to stdout and
stderr) into a more general with-output-to! macro, and:
- Simplifies the "print level" system. The various doom-print-*-level
variables have been removed.
- Adds a new print level: notice, which will be the default level for
all standard output (from print!, doom-print, prin[ct1], etc).
- Adds a with-output-to! macro for capturing and redirecting
output to multiple streams (without suppressing it from stdout). It
can also be nested.
- Changes the following about doom-print:
- Default :format changed to nil (was t)
- Default :level changed to t (was `doom-print-level`)
- No longer no-ops if OUTPUT is only whitespace
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.
BREAKING CHANGE: If anyone is using Doom's CLI framework and are
defining their own CLIs with any of the following macros, they'll need
to be updated to their new names:
- defautoload! -> defcli-autoload!
- defgroup! -> defcli-group!
- defstub! -> defcli-stub!
- defalias! -> defcli-alias!
- defobsolete! -> defcli-obsolete!
These were renamed to make their relationship with CLIs more obvious;
they were too ambiguous otherwise.
Otherwise, doom-module-from-path (and modulep!) would fail to detect the
module they're in, or at least, modulep! would incorrectly return nil,
even for enabled modules.
This issue is what would've caused the package list or the doctor to
include/consider packages in disabled modules or behind disabled flags.
Occurs when a site-file fails to be natively compiled, and Doom attempts
to write an error file in the same directory. On some systems, the
site-lisp directory is in a read-only tree/mount (like nix and guix).
This should suppress those attempts.
BREAKING CHANGE: This finally removes 'doom refresh'. It was first
deprecated in 8a77633 and disabled in 8c37928, and has long since been
replaced with 'doom sync'.
Ref: 8c37928de2
Ref: 8a7763337d
- 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'.
To reduce redundancy, remove the maintenance hassle that version
constants would impose later on, and rely on built-in
facilities (featurep) more over global variables or doomisms, these
global constants have been deprecated in favor of Emacs "features":
- EMACS28+ -- replace with (> emacs-major-version 27)
- EMACS29+ -- replace with (> emacs-major-version 28)
- NATIVECOMP -- replace with (featurep 'native-compile)
- MODULES -- replace with (featurep 'dynamic-modules)
(These constants will be formally removed when v3 is released. The IS-*
constants are likely next, but I haven't decided on their substitutes
yet)
I also decided to follow native-compile's example and provide features
for Emacs' system features (since system-configuration-features' docs
outs itself as a poor method to detect features):
- dynamic-modules
- jansson
- native-compile -- this one already exists, but will instead be removed
if it's non-functional; i.e. (native-comp-available-p) returns nil.
These are now detectable using featurep, which is fast and built-in.
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
If you've moved $EMACSDIR, comp-el-to-eln-filename will throw errors
about missing directories/files, rendering 'doom sync' ineffective and
forcing the user to delete $EMACSDIR and reinstall Doom.
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: Before, 'doom ci' would load
$GIT_WORKING_TREE/.github/ci.el, to give users/projects an opportunity
to provide project-local configuration for bin/doom (mainly for CI/CD).
Now, this ci.el file is no longer loaded and instead, *all* bin/doom
sessions will walk up the file tree and load the first .doomrc it finds.
This gives bin/doom users a more general place configure all of its
commands, and not just 'doom ci' commands.
Extras:
- Adds .doomrc to auto-mode-alist (so that it starts in
emacs-lisp-mode).
- Adds -o/--file option,
- If -o/--file is passed a dash, print codeowners to stdout,
- Adds --dryrun option,
- Will accept literal string entries in doom-make-codeowners as
standalone lines (useful for comments).
doom-enlist is now a deprecated alias for ensure-list, which is built
into Emacs 28.1+ and is its drop-in replacement. We've already
backported it for 27.x users in doom-lib (in 4bf4978).
Ref: 4bf49785fd
In the future, should doom-core-dir or {doom-core-dir}/packages.el
change, 'doom upgrade' won't leave the repo in a broken state.
Unfortunately, this cannot retroactively prevent the issue; users will
experience this as soon as they update to b9933e6 or beyond, so users
will have to upgrade manually to overcome it:
cd ~/.emacs.d
git reset --hard 35a89bdfa6
git pull origin master
doom sync -u
Fix: #6598
Amend: b9933e6637
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
