Emacs requires '-*- lexical-binding: t -*-' to be prefixed with an elisp
line comment (two semicolons), but due to our shebang shenanigans (which
are, unfortunately, necessary) starting this line with a :;, Emacs
ignores the `lexical-binding: t` at the top, thereby executing bin/doom
without lexical binding.
Until a better workaround is found, our CLI framework will have to
adapt. Fortunately, this only affects bin/doom and not any arbitrary
doomscript.
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
This prevents edge cases where these directories are created with
permissions that prevent Emacs from writing to them. This can happy
either due to an overly-restrictive default umask,
`set-default-file-modes` call, or if `doom-profiles-save` is instructed
to write a file whose parent doesn't exist yet.
Fix: #8134
Eventually, I want to autoload some of this stuff, so that users in
interactive sessions can safely load it without side effects (useful
when writing their own CLIs or editing Doom's source).
Doom loaded subdirs.el's in `load-path`, but doesn't need to. This
normally wasn't an issue because subdirs.el files are typically
idempotent, but there is one case where it isn't: on nixpkgs, with
certain configurations on top of programs.emacs (see
NixOS/nixpkgs#267548), which will cause file-missing errors trying to
load the user's site-lisp afterwards (see #7681).
Ref: NixOS/nixpkgs#267548Fix: #7681
Amend: 6c0b7e1530
The motivations for delaying the site-lisp files are different between
interactive and non-interactive sessions. I've revised these comments to
reflect that.
The auto-generated script has bom characters on my mac. if bin/doom
exits with code 254, it gives me the below error:
`.../doom.123.0.sh: line 1: #!/usr/bin/env: No such file or directory`
Some site files will forcibly undo `inhibit-message` or set
`force-load-messages`. This ensures site lisp files don't make
unnecessary noise at startup.
If $DOOMPATH is malformed or set to a value that does not contain a
valid path to Doom's CLI library in $EMACSDIR/lisp/cli (see #7608),
bin/doom no longer functions, emitting "a subcommand is required"
errors.
This change ensures that the CLI library is always the last (implicit)
element in doom-cli-load-path, and ensures $DOOMPATH is never written to
the user's envvar file (in case they try to use bin/doom from inside a
terminal within a Doom Emacs session), which should ensure users -- at
least -- never find themselves stranded without the Doom CLI.
Fix: #7608
Co-authored-by: bpizzi <bpizzi@users.noreply.github.com>
Emacs can unpredictably prompt the user to "Select coding
system (default utf-8):" in some cases. The exact cause is a little
different for every user, but it can be suppressed by explicitly setting
a default language environment. This is not desirable in interactive
sessions, however.
Ref: #3042Close: #7330
Co-authored-by: bennyip <bennyip@users.noreply.github.com>
Some shells (like ksh on SDF) may complain about $((...)) arithmetic
expansion syntax. Rather than wrestle with old shells, I'll offload this
trivial operation to elisp instead.
Close: #6970
* lisp/cli/help.el (doom help): move to lisp/cli/meta.el, and add :dump
definition.
* lisp/doom-cli.el:
- (doom-before-init-hook): trigger hook after the file is done
loading.
- (doom-cli-backtrace-depth, doom-cli-straight-error-lines,
doom-cli-benchmark-threshold): rename these variables' prefix from
`doom-cli-` to `doom-cli-log-`.
- (doom-cli--plist): rename to doom-cli--group-plist, to better clue
in what changes it.
- (doom-cli-context-parse): remove unused letbind (argsleft).
- (doom-cli-create-context-functions, doom-cli-before-run-functions,
doom-cli-after-run-functions): define with defcustom instead of
defvar, to indicate that they are (especially) intended for end-user
configuration.
$EMACSLOADPATH is read to pre-fill load-path. Empty entries therein are
substituted with the default value of load-path. I am mirroring this
behavior with the $DOOMPATH variable.
load! effectively loads (file-name-concat (dir!) PATH) which, in this
case, is concatenating two absolute file paths. Emacs does the right
thing and loads PATH, but I don't want to rely on this good fortune as
it could be broken in a future update.
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
* lisp/doom-cli.el:
- reference backport source commit.
- doom-cli--restart: a type check is all we need here. This is a
programmer error, not a user error.
* lisp/doom-editor.el (recentf): mention recentf-show-abbreviated (added in
emacs-mirror/emacs@32906819ad)
* lisp/doom-keybinds.el (doom-init-leader-keys-h): move to
doom-after-init-hook, in case the user customizes leader variables in
a previous hook (like emacs-startup-hook or after-init-hook).
* lisp/doom-start.el: use eval-when! to compile out the section on
non-macOS systems (when Doom gets around to compiling its core files,
later).
* modules/config/literate/autoload.el (+literate-config-file): use
file-name-concat instead of string concat. This relaxes the
requirement that doom-user-dir end in a /; a requirement I intend to
fully phase out.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-non-package): remove
empty map! macro in flycheck-emacs-lisp-check-form. The macro already
no-ops at compile-time/in noninteractive sessions since b480ed51a3.
* modules/ui/hl-todo/config.el (hl-todo-keyword-faces): revise
commentary for default hl-todo keywords.
Ref: emacs-mirror/emacs@32906819ad
Ref: b480ed51a3
Due to $DOOMPROFILE being set to an empty string when persisting Doom
CLI sessions, which would affect any case where a CLI command restarts
the session (e.g. when the :config literate module tangles a config or
'doom --debug ...' restarts to set DEBUG=1).
Particularly DOOMPROFILE, without which the --profile switch wasn't
actually doing anything, and profile sessions would (silently) use the
default user-emacs-directory and doom-user-dir.
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
doom-before-init-hook runs before $DOOMDIR/init.el is loaded.
doom-after-init-hook runs at the *very* end of the Emacs startup
process (after window-setup-hook).
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.
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.
This is a regression from 948f946, where a bunch of mkdir calls were
removed prematurely. In v3, other processes are responsible for creating
these directories, but those haven't been implemented yet.
Fix: #6756
Amend: 948f9461a7
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.
