It's possible for the debugger to be invoked from inside code wrapped in
a (quiet! ...) call. The debugger pauses Emacs in a broken state where
the functions locally rebound by quiet! (e.g. message, load-file,
write-region, etc) are never returned to their original definitions.
This attempts to reduce that probabilityby changing how quiet! silences
code. Rather than silencing them completely, they will be logged
to *Messages* but not displayed in the echo area.
Also, quiet! is now used less, where it isn't strictly needed (or where
inhibit-message is sufficient).
It is easier to spot real problems if the code is warning-free.
Replacing `gensym` with `make-symbol` is an idea taken from here:
b44c08dd45
In defer-until!:
core-lib.el:150:19:Warning: function ‘gensym’ from cl package called at
runtime
In add-transient-hook!:
core-lib.el:216:16:Warning: function ‘gensym’ from cl package called at
runtime
In toplevel form:
autoload/message.el:35:1:Warning: Unused lexical variable ‘spec’
In toplevel form:
autoload/line-numbers.el:31:1:Warning: defcustom for
‘display-line-numbers-type’ fails to specify containing group
autoload/line-numbers.el:31:1:Warning: defcustom for
‘display-line-numbers-type’ fails to specify containing group
autoload/line-numbers.el:39:1:Warning: defcustom for
‘display-line-numbers-grow-only’ fails to specify containing group
autoload/line-numbers.el:39:1:Warning: defcustom for
‘display-line-numbers-grow-only’ fails to specify containing group
autoload/line-numbers.el:44:1:Warning: defcustom for
‘display-line-numbers-width-start’ fails to specify containing group
autoload/line-numbers.el:44:1:Warning: defcustom for
‘display-line-numbers-width-start’ fails to specify containing group
In toplevel form:
cli/autoloads.el:137:1:Warning: Unused lexical variable ‘type’
Preserve name of unused lexical var _type
Makes it obvious what is stored there.
We would need to use `'equal` for comparison, but Emacs 25 only allows `'eq`.
Using `advice-add` to override `alist-get` does not work, because `setf`
has special handling for `alist-get`.
`repl.el`: Switch to a hash table which already supports multiple comparison
functions, and changing of elements even in Emacs 25.
`eshell/autoload/settings.el`: use conditional set-or-push.
Drop `doom*alist-get`, it is unused now.
Thanks to @hlissner for the reimplementation.
+ Removes redundant/unhelpful comments
+ Renames functions, hooks and variables to be self-documenting
+ Use add-to-list to ensure idempotency (and is more performant)
After some profiling, it turns out map-put and map-delete are 5-7x
slower (more on Emacs 25) than delq, setf/alist-get and add-to-list for
small lists (under 250 items), which is exactly how I've been using
them.
The only caveat is alist-get's signature is different on Emacs 25, thus
a polyfill is necessary in core-lib.
The way Doom was using eval-after-load ensured its form were never
byte-compiled or even checked by the byte-compiler, because they were
treated as quoted forms (data), and thus eval'ed.
Friends don't let friends use eval.
Another refactor, again to improve the locality of doom errors and make
the data that accompanies them more useful in determining the origin and
source of issues. Also, bin/doom is now a little more informative about
how to debug errors.
This lets you delay a body of code until an arbitrary condition is
met (which is checked whenever a file is loaded).
Also refactors set-file-template! to wait until +file-templates-alist is
defined.
+ Move doom-initialize et co into core.el
+ Lazy load core-packages
+ load! has been moved into core-lib
+ Added FILE! and DIR! macros
+ Fix package! not returning correct value when package is disabled
+ Remove :disabled support for def-package-hook! officially
When appending multiple functions to a hook(s) with add-hook!, insertion
order was not preserved. e.g.
=> (add-hook! :append 'some-mode-hook #'(hook-1 hook-2))
=> some-mode-hook
(hook-2 hook-1)
Due to changes under the hood, the :files FORM property requires FORM to
either be a nested form of and/or sexps, or a single string. This is
inconsistent with the plurality of ":files", so it has been fixed to
accept a list of strings (with an implicit (and ...)).
