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
In the interest of slimming down Doom's core (as we near v3), I've
deprecated these macros. They doesn't really need to exist. Sure, the
alternatives aren't as ergonomic or elegant, but they're good enough
that we don't need these trivial wrappers. Their local uses have been
refactored out as well.
Assuming GPG is present and set up by default can be surprising for
beginners, so this commit makes GPG integration opt-in, behind a new
+gnupg flag in the :config default module. There'll be more added to
this later.
Error occurs on Emacs 30.0.92 or newer, because this variable (what it's
aliased to, at least) was moved to comp-run.el, upstream.
Ref: emacsmirror/emacs@e6a955d242
The lexical bindings for the load suffix variables in early-init.el does
this work already, so affecting the global state of these variables is
redundant and overkill.
It seems either Emacs' warning library and/or debugger relies on
custom.el functionality at load time to properly function. If
`custom-dont-initialize` is non-nil when a warning or error occurs,
Emacs fails to fully load the `warning` or `backtrace` libraries,
causing this error to obscure the true warning/error with:
Error in delayed-warnings-hook (display-delayed-warnings): (void-variable
warning-minimum-log-level)
`doom-module-load-path` will be removed in the next big refactor commit,
so as a stop gap, I simply move it to doom.el to resolve the reference
error.
This also removes the obsolete alias `doom-modules-dirs`, since it's
been deprecated long enough (and `doom-module-load-path` itself won't be
around much longer anyway).
Ref: #8147
Amend: 8cafbe4408
Seems these two macros were marked obsolete very recently on Emacs 31.1
in favor of (if|when)-let*. Since the change seems premature (judging
from the mailing list discussion), and because I disagree with the
change (and will redefine (if|when)-let if they actually go through with
removing them), I simply silence the warnings altogether. They're not
helpful for the end user and end up only spamming them with unactionable
warnings.
I'll wait until upstream figures it out before I make any decisions.
Ref: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00637.html
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.
Eventually, Emacs will process any files passed to it via the command
line, and will do so *really* early in the startup process. These might
contain special file paths like TRAMP paths (e.g.
/sudo://etc/ssh/ssh_config), so restore `file-name-handler-alist' just
for this small portion of startup.
There are still a few edge cases where inhibit-redisplay is never
reset (usually involving errors at startup), leaving Emacs as a blank
screen until the user performs an action that forces it to redraw (e.g.
pressing M-x). This tries to address more of those.
