If you have a private module with the same name as a built-in module,
doom-module-load-path returns two entries for that module, causing our
autoloads scanner to scan it twice.
I am not sure what the setting + removing hook code in use-package!
winner was trying to accomplish, but it was breaking winner-redo
functionality. This patch fixes the issue.
This directory is used when server-use-tcp is non-nil (which is the case
on Windows). With this changed from its default, users have to manually
specify its location when using emacsclientw.exe to connect to daemons.
This means a little more noise in `~/.emacs.d`, but Windows users have
worse things to put up with.
Fixes#3324
Evaluating custom-set-faces! calls would add setter functions to
doom-load-theme-hook indefinitely, which could add up each time you M-x
doom/reload. Now it adds them to a subhook, which is reset whenever Doom
is reloaded.
It's kind of silly that our command lambda macros (λ! and λ!!) need a
snippet, special key sequence or copy-paste to insert, so in the spirit
of fn! -- and to make sure they take up less space than `lambda!` --
I've added `cmd!` and `cmd!!` aliases. `lambda!` and `lambda!!` are now
deprecated. λ! and λ!! will remain.
I've also added `cmds!` as a convenience wrapper around
general-predicate-dispatch.
- Update comments & docstrings
- Remove unnecessary compile-time evaluation (we're not using any of
that config at compile time within that file anyway).
Affects doom/browse-in-other-project, doom/find-file-in-other-project,
+default/search-other-project and
+default/search-project-for-symbol-at-point.
When performing a text or file search in "another project", prior to
this update the current project would be the first highlighted
candidate, which doesn't make much sense when you're invoking a command
for searching *other* projects.
elisp lacks an execv implementation (or mature subprocess library), so
we exploit some splenderiffic hackery to get Emacs to execute arbitrary
shell commands after a 'doom ...' command completes. This allows us to
daisy chain doom commands in distinct sessions (wonderful for reloading
doom after a 'doom upgrade', which we do). This minimizes errors when a
'doom upgrade' pulls in breaking changes to Doom's CLI.
We also bring 'doom run' into elisp, since this new functionality
enables us to.
The coming CLI rewrite makes bin/doom atomic, but also "freezes" more of
your config in between 'doom sync's and 'doom upgrade's. This is
necessary to implement a robust rollback system. However, that also
means that `doom!` shouldn't do anything when read in an interactive
session (and should only be read when running `doom sync`).
Indirectly fixes#2612
That 'doom refresh' and 'doom sync' do the same thing has been a point
of confusion for a while. By phasing out 'doom refresh' we can finally
put that to rest.
