Reduces the amount of "noise" included in bin/doom's output.
Also fixes an issue where warnings during autoloads generation would
sneak into Doom's autoloads file, producing weird void-variable errors,
like
(void-variable . rainbow-delimiters:)
(void-variable . diredfl:)
(void-variable . company:)
We only need this magic in CLI sessions. It's better to only use half
the CPUs in interactive sessions (if the user has enabled
comp-deferred-compilation for some reason).
Fixes#5042
Still a long way to go, but this introduces a few niceties for
debugging CLI failures:
+ The (extended) output of the last bin/doom command is now logged to
~/.emacs.d/.local/doom.log
+ If an error occurs, short backtraces are displayed whether or not you
have debug mode on. The full backtrace is written to
~/.emacs.d/.local/doom.error.log.
+ bin/doom now aborts with a warning if:
- The script itself or its parent directory is a symlink. It's fine if
~/.emacs.d is symlinked though.
- Running bin/doom as root when your DOOMDIR isn't in /root/.
- If you're sporting Emacs 26.1 (now handled in the elisp side rather
than the /bin/sh shebang preamble).
+ If a 'doom sync' was aborted prematurely, you'll be warned that Doom
was left in an inconsistent state and that you must run `doom sync`
again.
May address #3746
Some doom commands will generate a temporary script at
~/.emacs.d/.local/.doom.sh so that it can run an arbitrary shell command
after the current invocation of bin/doom ends. Very useful for, say,
restarting the currently running doom command after a destructive
operation, like updating Doom's source code, tangling your literate
config, or for launching arbitrary programs, like a new instance of
Emacs. This is necessary because elisp lacks an execv implementation.
However, for some folks, .doom.sh wasn't executing at all. This meant:
1. Some `doom upgrade`s would upgrade Doom itself but never move on to
the second step of the process: updating its packages.
2. Literate config users could tangle their configs on `doom sync`, but
the actual syncing process would never happen (#3746).
3. `doom run` would do nothing.
I hadn't realized /bin/sh runs bash in POSIX mode (at least, on systems
where /bin/sh = bash, like nixOS or macOS). In POSIX mode the script
will abort the if a builtin command (like export) returns a non-zero
exit code. Since .doom.sh is basically a bunch of exports followed by an
arbitrary command, and there are some environment variables
that can trigger validation errors (like UID triggering a "read-only
variable" error), we have a problem.
Hopefully addresses #3746
Tangling would load org libraries. If org hasn't been installed yet,
this means the older version is loaded, later interfering with the
installation and byte-compilation of the new package, causing down the
road.
- Tangling no longer adds temp files to recentf (#3685)
- If :tangle yes is used, the result is no longer tangled to
/tmp/config.org.*.el
- In interactive sessions the org buffer is no longer interfered with
when tangling (by scrolling up to the top of the page, or undoing
overlays/markers).
- Tangling no longer triggers formatters (or any save/write hooks).
- Appease byte-compiler sama, complaining about free variables.
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.
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.
We no longer need two separate autoloads files, so I merged them and
optimized its generation logic.
Other changes
- Doom will refuse to start up (with a helpful error) if it's in an
incomplete state. This should hopefully reduce the number of bug
reports from folks that have done something weird, e.g.
1. You've changed Emacs versions without running 'doom sync -b'.
2. You've updated Doom outside of `doom upgrade` and didn't run `doom
sync -u`.
3. You've forgotten to run 'doom sync' in the first place!
4. If a previous 'doom ...' command was aborted midway without running
'doom sync' afterwards.
- 'doom sync' will emit reminders that you need to reload/restart Emacs
- Autoloads API now uses the `doom-autoloads-` prefix, intead of
'doom-cli-autoloads-', as will be the new convention in the coming
rewrite.
- Errors from within the package autoloads should be easier to invoke
the debugger on.
- `doom-modules` is now stored in your autoloads file. Your module list
will soon be frozen between calls to 'doom sync' to allow for our new,
atomic CLI I'm working on. This will also means the `doom!` block
won't cost anything in interactive sessions.
`format` isn't an appropriate for this library, considering it (and
future additions to it) will be mainly concerned with printing or
capturing output.
Doom now looks for cli.el files in your private directory or modules,
giving them an opportunity to customize the CLI (add commands or
reconfigure existing ones) to suit their purposes.
For prompts like these
> In repository "org-roam", remote "origin" has URL
"https://github.com/jethrokuan/org-roam.git"
but recipe specifies a URL of
"https://github.com/org-roam/org-roam.git"
1) Abort
2) Rename remote "origin" to "origin-1", re-create "origin" with correct URL, and fetch
3) Rename remote "origin" manually, re-create it with correct URL, and fetch (Recommended)
4) Delete remote "origin", re-create it with correct URL, and fetch
5) Delete remote "origin", re-create it with manually set URL, and fetch
How to proceed? (1, 2, 3, 4, 5)
4 should be recommended, not 3.
When you're being prompted, these regexps control what option is
highlighted as the recommended option, and two of them were definitely
wrong, and another two *might've* been wrong.
The rewrite for Doom's CLI is taking a while, so I've backported a few
important changes in order to ease the transition and fix a couple bugs
sooner.
Fixes#2802, #2737, #2386
The big highlights are:
- Fix#2802: We now update recipe repos *before* updating/installing any
new packages. No more "Could not find package X in recipe repositories".
- Fix#2737: An edge case where straight couldn't reach a pinned
commit (particularly with agda).
- Doom is now smarter about what option it recommends when straight
prompts you to make a choice.
- Introduces a new init path for Doom. The old way:
- Launch in "minimal" CLI mode in non-interactive sessions
- Launch a "full" interactive mode otherwise.
The new way
- Launch in "minimal" CLI mode *only* for bin/doom
- Launch is a simple mode for non-interactive sessions that still need
access to your interactive config (like async org export/babel).
- Launch a "full" interactive mode otherwise.
This should fix compatibility issues with plugins that use the
async.el library or spawn child Emacs processes to fake
parallelization (like org's async export and babel functionality).
- Your private init.el is now loaded more reliably when running any
bin/doom command. This gives you an opportunity to configure its
settings.
- Added doom-first-{input,buffer,file}-hook hooks, which we use to queue
deferred activation of a number of packages. Users can remove these
modes from these hooks; altogether preventing them from loading,
rather than waiting for them to load to then disable them,
e.g. (after! smartparens (smartparens-global-mode -1)) -> (remove-hook
'doom-first-buffer #'smartparens-global-mode)
Hooks added to doom-first-*-hook variables will be removed once they
run.
This should also indirectly fix#2386, by preventing interactive modes
from running in non-interactive session.
- Added `doom/bump-*` commands to make bumping modules and packages
easier, and `doom/bumpify-*` commands for converting package!
statements into user/repo@sha1hash format for bump commits.
- straight.el is now commit-pinned, like all other packages. We also
more reliably install straight.el by cloning it ourselves, rather than
relying on its bootstrap.el.
This should prevent infinite "straight has diverged from master"
prompts whenever we change branches (though, you might have to put up
with it one more after this update -- see #2937 for workaround).
All the other minor changes:
- Moved core/autoload/cli.el to core/autoload/process.el
- The package manager will log attempts to check out pinned commits
- If package state is incomplete while rebuilding packages, emit a
simpler error message instead of an obscure one!
- Added -u switch to 'doom sync' to make it run 'doom update' afterwards
- Added -p switch to 'doom sync' to make it run 'doom purge' afterwards
- Replace doom-modules function with doom-modules-list
- The `with-plist!` macro was removed, since `cl-destructuring-bind`
already serves that purpose well enough.
- core/autoload/packages.el was moved into core-packages.el
- bin/doom will no longer die if DOOMDIR or DOOMLOCALDIR don't have a
trailing slash
- Introduces doom-debug-variables; a list of variables to toggle on
doom/toggle-debug-mode.
- The sandbox has been updated to reflect the above changes, also:
1. Child instances will no longer inherit the process environment of
the host instance,
2. It will no longer produce an auto-save-list directory in ~/.emacs.d
