Rather than reimplement its face lookup (and have two versions of
doom-print-ansi-alist -- one for 27.x and one for 28+), let's just rely
on ansi-color.
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.
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.
Writing a debugger for Elisp is too much hassle. `debug` itself isn't
very customizable without a *lot* of boilerplate, so instead of writing
my own, it's more effective to advise debug instead. Certainly, I don't
do anything with it yet, but I will soon.
This allows us to load them via doom-require. Why not use normal
features? Because Doom's libraries are designed to be loaded as part of
Doom, and will openly rely on Doom state if needed; this is a contract I
want to enforce by ensuring their only entry points are through
`doom-require` or autoloading.
I will add them to the rest of the libraries later.
Site-node: this also adds Commentary+Code to the comment headings, as I
want a space to use that space to describe the library, when I get
around to it.
If doom-emacs-dir contains a "~", attempting to call `git -C` will fail
with an error like:
fatal: cannot change to '~/.config/emacs/': No such file or directory
Fix this by canonicalizing the filename.
I prefer to be more explicit about these variables' defaults, then to
rely on proper load order and unverified global state to ensure they're
properly set.
This was done to purge superfluous files from Doom's project structure
and simplify its entry points. And with early-init.el now acting as
Doom's universal bootstrapper (see c05e615), we don't have enough
bootstrap logic to warrant being its own file.
Also removes the redundant version check, given doom.el is assured to be
loaded before doom-cli, and performs its own check.
Ref: c05e61536e
A concise alternative to the file IO elisp idioms we're used to,
involving some combination of with-temp-file, with-temp-buffer,
insert-file-contents, coding-system-for-{read,write}, write-region, read
loops, print-to-current-buffer loops, etc.
These were engineered to make reading/writing text and lisp data from/to
files simpler, and will be used extensively in the v3 CLI.
Consecutive expand-file-name and recursive apply's can be expensive, so
the function has been simplified to rely more on file-name-concat. This
does change one trait about it, however: absolute paths in SEGMENTS no
long reroot the whole path, and are concatenated as ordinary file
segments.
The performance benefit is more pronounced on Emacs 28+, and will be
even more so when Doom later starts byte-compiling its libraries.
This was brought over from `doom-info` in f33d8e7, but one of the
lexical function calls wasn't refactored out.
Ref: a5c80fcb4b/lisp/lib/debug.el (L216-L219)Fix: #6698
Amend: c5e3f4d632
Co-authored-by: ivanbrennan <ivanbrennan@users.noreply.github.com>
doom-etc-dir will be renamed to doom-data-dir, to better reflect its
purpose, and align it with XDG_DATA_HOME (where it will be moved to in
v3, where Doom will begin to obey XDG directory conventions more
closely).
- 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'.
featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
- Rename doom-docs--display-header-h -> doom-docs--display-menu-h to
better represent what it does.
- Add comments to describe the purpose of lib/docs, and TODO annotations
to hint at its future and remind me later.
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
I've omitted docs/*.org from this merge, as there is still work left to
do there, but I am pushing the module docs early so folks can benefit
from the new docs sooner.
In some edge cases, an early call to doom-log will cause an autoload
error because of one or more of the following is true:
- The autoloads file hasn't been generated or loaded,
- The autoloads file is out of date (especially relevant after
b9933e6),
- doom-cli hasn't loaded lib/files eagerly yet.
To avoid this, and due to how prolific doom-log's uses are, and how
trivial the dependency is, I simply remove the dependency.
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
