In v3, 'doom run' will have a different purpose (for launching project
or CI/CD tasks), so it now emits a warning that it's moved to a new
'doom emacs' command.
I refrain from updating documentation because a rewrite of our docs will
be coming up soon.
- cmd.exe chokes on the space in "C:\Program Files\...", but more
importantly, doom.ps1 should be invoked with powershell, not cmd.exe.
- Windows has pwsh.exe and powershell.exe, which, while not identical,
are close enough for our purposes, but needed to be accounted for.
Fix: #8098
A regression introduced in bac90c0. The extra --eval isn't necessary in
bin/doomscript because it loads early-init.el (and thus, lisp/doom.el)
sooner than bin/doom does.
Fix: #8362
Amend: def4579a9f
As of recent commits of Emacs 31, elisp files missing a
"lexical-binding: t" cookie will emit this warning:
Warning (files): Missing ‘lexical-binding’ cookie in "path/to/elisp/file".
You can add one with ‘M-x elisp-enable-lexical-binding RET’.
See ‘(elisp)Selecting Lisp Dialect’ and ‘(elisp)Converting to Lexical Binding’
for more information.
You can look forward to many of these if you use any old and
unmaintained elisp packages, or if you have elisp shell scripts with
shebang lines (which make this warning unavoidable).
This commit silences these warnings because it's poorly implemented.
It's obnoxious to users and they aren't the ones that should be told
this. It ought to be emitted during byte-compilation or by linters (e.g.
`M-x checkdoc`) at the folks actually in a position to do something
about the warning (i.e. the developers).
Ref: https://lists.gnu.org/r/emacs-devel/2024-05/msg00283.html
Freeing this up to use for a future command (doom init), and because
'doom install' ought to be used very rarely and deliberately, so it
shouldn't have a convenient alias anyway.
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
BREAKING CHANGE: This backports some architectural choices from v3.0.
This changes Doom's module API, renaming some functions and removing
others, in order to facilitate some new features, prepare to move Doom's
modules into separate repos, and make way for two, much larger breaking
commits coming in the next few days.
This commit won't break anything for users unless they're tinkering with
Doom's internals/using its `doom-module-*` API directly. I am avoiding
broader backwards incompatibilities until the 3.0 release.
What's new:
- Negated flags. (modulep! :editor evil -everywhere) will return non-nil
if :editor evil is active without its +everywhere flag.
- `modulep!` now takes multiple flags to simplify AND checks. E.g.
(and (modulep! +foo)
(modulep! +bar)
(not (modulep! +baz)))
Can now be expressed with:
(modulep! +foo +bar -baz)
- Adds pcase matchers for `doom-module-context` and `doom-module`
structs, making the following destructuring binds possible:
(pcase-dolist ((doom-module group name flags features)
(hash-table-values doom-modules))
...)
This will be used more in v3.0.
- Adds file cookie support to module init.el and config.el files.
Here's a summary of breaking changes made in this commit:
- `doom-module-context` was changed from a vector to a struct (record).
- `doom-modules` is now a table of `doom-module` structs, rather than
free-form plists.
- The following macros have been renamed:
- `doom-context-with` -> `with-doom-context`
- `doom-module-context-with` -> `with-doom-module`
- The followings functions have been replaced/removed:
- `doom-module-context`+`doom-module-context-get` -> `doom-module`
- `doom-module-set` -> `doom-module--put`
- `doom-module-p` -> `doom-module-active-p`
- `doom-module-context-key` (is now a getter with the same name)
- `doom-module-put` (removed)
- `doom-module--context-field` (removed)
- The signatures for these functions have changed:
- `doom-module-get CATEGORY &optional MODULE PROP` ->
`doom-module-get (GROUP . MODULE) &optional PROP`
- `doom-module-locate-path CATEGORY &optional MODULE FILE` ->
`doom-module-locate-path (GROUP . MODULE) &optional FILE`
- `doom-module-expand-path CATEGORY MODULE &optional FILE` ->
`doom-module-expand-path (GROUP . MODULE) &optional FILE`
- Adds the following functions
- `doom-module-exists-p`
- `doom-module-key`
- `doom-module->context`
- `doom-module<-context`
- Removes the following variables
- `doom-module--empty-context`
This commit results in a little redundancy, which I will address in
parts 2/3 and/or v3.0.
In 4989661, I reduced the init time for bin/doom by eliminating the
extra `emacs` call in its shebang. This does the same for
bin/doomscript.
Ref: 498966179f
Even `emacs --batch -f kill-emacs` can take a non-trivial amount of time
to start up (0.661s on my system). This makes the two `emacs` calls in
bin/doom's shebang amount to >1s of startup time for Doom scripts (~1.5s
on my system). This change removes the second call (or at least defers
it until the after-script; at least, if $TMPDIR or $TEMP aren't set),
bringing down that time to a more bearable 0.9s.
This sacrifices the more descriptive "Can't find Emacs in your $PATH"
error message should the user set their own $EMACS, but the alternative
bash error is good enough:
$ EMACS=foo doom version
/home/$USER/.config/emacs/bin/doom: line 12: foo: command not found
I'm not doing more sophisticated checks on $EMACS, because it could be a
command (like `flatpak run org.gnu.emacs`), rather than an executable or
path, and the boilerplate to handle that, within what small space we get
in bin/doom's shebang, would be too much maintenance headache just for a
slightly better error message.
c9acdb7 removes doom.cmd because it was broken in most cases. This adds
doom.ps1; an alternative script for Windows+Powershell users, which
properly initializes the state it needs. Naturally, it requires
Powershell 3+ be installed on your systems, but it can be invoked from
either cmd.exe or PowerShell.exe.
This is the first powershell script I've ever written, so I expect edge
cases (for one, shell commands passed to `exit!` will need to be guarded
against the environment).
This also requires emacs.exe be your $PATH, however, unless you set
$EMACS to its path first. E.g.
$env:EMACS = "C:\Program Files\Emacs\emacs-29.4\bin\emacs.exe"
That said, if you use WSL2, you're still far better off using the bash
script (bin/doom).
Ref: c9acdb72a4
This batch script hasn't worked for some time. For v3, I'm working on a
Emacs TUI porcelain for the bin/doom script that will serve as a
replacement/alternative for folks on Windows (or who simply don't
want/need the CLI).
'doom purge' is now deprecated.
Also changes 'doom sync's -p option to --gc. Since GCing causes the loss
of historical data, I'd rather it be a long option to make it a little
harder to do accidentally.
This changes 'doom sync' to be smarter about responding to changed
package recipes/pins, changes in Emacs version, or instances where the user
has copied a config to a new system.
In all these cases, the user would formerly have to know about a
specific combination of 'doom sync -u' and 'doom build' to ensure Doom
is in a good state. With this change, 'doom sync' handles all these
cases.
Also, 'doom build' is now deprecated (and 'doom sync' now has a
--rebuild option to mimic its old behavior).
Also also, sometimes, a package may silently fail when cloned (which
used to result in an empty repo). Now, if this is detected, cloning will
be re-attempted up to 3 times before aborting with much more visible
error.
Note: these are stopgap solutions, until v3 is finished.
BREAKING CHANGE: This removes the 'doom compile' and 'doom clean'
commands, and offers no immediate replacement for them (and no plan to
include one). In the future, byte-compilation of Doom's internals will
be baked into 'doom sync', but until then, Doom is not optimized to take
advantage of byte-compilation, and forcing it provides no benefit.
LC_ALL must be set to a locale that exists on the current system, and
there is no locale I can safely expect all systems to have (see #7361).
Fortunately, c8070f1 seems to have addressed the underlying issue, so
this fix can be reverted.
Fix: #7361
Revert: #7331
Revert: 150ccd6305
Ref: c8070f11a4
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
From now on, our documentation will assume your Emacs config lives in
~/.config/emacs, by default, rather than ~/.emacs.d. Support for the
latter is not going away, it will simply be mentioned less in the
literature, as all supported versions of Emacs going forward (and future
versions of Doom) will support (and prefer) XDG conventions.
The user manual will be updated separately.
Close: #6965
Co-authored-by: gagbo <gagbo@users.noreply.github.com>
Sync definition of __DOOMGEOM in bin/doomscript with corresponding
variable of bin/doom.
* bin/doomscript (__DOOMGEOM): split tput call into two separate calls
Ref: beef0aef02
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.
This introduces a depth field for modules so that they may dictate their
load order explicitly, it also treats depths <= -100 or >= 100 as
special depths, which will be loaded early, before their respective
doom-{before,after}-module-{init,config}-hook. This permits psuedo
modules like :core and :user modules to be treated as normal modules
without too many special cases.
This also fixes a module load order issue on Emacs 29 (#6813), caused by
emacs-mirror/emacs@4311bd0bd7, which changed the return value order of
hash-table-{keys,values} causing modules to be loaded in reverse order;
resulting in the loss of evil keybinds, among other things.
Other notable changes:
- Changes the data structure for module data caches from a list to a
vector. Uses less memory and permits faster lookups. Also adds two
depth fields to the front of it.
- Changes the signature of doom-module-list and doom-package-list.
- Renames doom--read-packages -> doom-packages--read for consistency
with naming convention.
- Add doom-module-depth function.
- Adds a temporary doom-core-dir/init.el file, which is responsible for
loading doom-*.el.
Fix: #6813
Ref: emacs-mirror/emacs@4311bd0bd7
- Adds $DOOMPROFILELOADFILE: Controls where to read and write the
profile loader. Changing this may be helpful for users on nix/guix,
who have deployed Doom to a read-only location. This sets
`doom-profile-load-file`.
- Changed profile load file's default location (used to be
$EMACSDIR/profiles/init.el, is now $EMACSDIR/profiles/load.el). The
gitignore was updated to reflect this.
- Adds $DOOMPROFILELOADPATH: A colon-delimited list of profile config
files and directories (semi-colon on Windows) which dictate what Doom
reads in order to discover your profiles. Config files are required to
have an *.el extension. This sets `doom-profile-load-path`.
- Changes the nomenclature around this loader script. I used to refer to
it as the profile bootstrapper. I'll now refer to it as the profile
load file, and I've renamed `doom-profiles-bootstrap-file` to
`doom-profile-load-file` to reflect this.
- The variables `doom-profile-dirs` and `doom-profile-config-files` were
merged into doom-profile-load-path.
- Both envvars have also been documented in `doom help` (and
$DOOMPROFILE's has been updated).
Ref: #6794
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.
