Bloated projectile caches can cause freezing and delays. This is
especially so if you accidentally index $HOME or /, which will bloat
them into the hundreds of MBs.
+ Adds purging of blacklisted, over-sized and non-projects from
projectile's cache when Emacs is killed.
+ Projectile's project file cache will now expire after a week.
+ Corrects file paths in core/doctor's filesize checks.
+ Fixes config.org buffer being killed when tangled
+ Tangle files in same session if ob-tangle is loaded (and in
noninteractive sessions). i.e. only tangle quietly when starting up
interactive Emacs.
org-babel-tangle-file has reportedly killed config.org buffers, despite
them being visited. Since we're not doing anything with the return
value, may as well keep it in a separate process.
+ Now recompiles literate config if you modify org files in DOOMDIR
+ Replaced +literate/compile with +literate/reload
+ Calls org-babel-tangle-file directly if org package is loaded
+ Change mtime check mechanism for literate tangling at startup
IMPORTANT: This is a breaking update for Mac users, as your shell
environment will no longer be inherited correctly (with the removal of
exec-path-from-shell). The quick fix is: 'bin/doom env refresh'. Also,
the set-env! autodef now does nothing (and is deprecated), be sure to
remove calls to it in your config.
Smaller changes:
+ This update also adds --no-* switches to doom quickstart
+ Includes general improvements to the documentation of several bin/doom
commands.
+ Moves doom/reload* commands to core/autoload/config.el
+ doom/reload-project has been removed (it didn't actually do anything)
The breaking change:
This update adds an "envvar file" to Doom Emacs. This file is generated
by `doom env refresh`, populated with variables scraped from your shell
environment (from both non-interactive and interactive sessions). This
file is then (inexpensively) loaded at startup, if it exists.
+ The file is manually generated with `doom env refresh`.
+ It can be regenerated automatically whenever `doom refresh` is run by
running `doom env enable` (`doom env clear` will reverse this and
delete the env file).
+ `doom quickstart` will ask if you want to auto-generate this envvar
file. You won't need it if you're confident Emacs will always be
started from the correct environment, however.
+ Your env file can be reloaded from a running Emacs session with `M-x
doom/reload-env`. Note: this won't work if the Emacs session you're
running it in doesn't have a correct SHELL set. i.e. don't use this to
create your first env file!
The idea isn't mine -- it's borrowed from Spacemacs -- and was
introduced to me in #1053 by @yurimx. I was impressed with it. Prior to
this, I was unhappy with exec-path-from-shell (no hate to the dev, I
understand its necessity), and 'doom patch-macos' wasn't ideal for mac
users (needed to be reapplied every time you update Emacs). What's more,
many users (even Linux users) had to install exec-path-from-shell
anyway.
This solution suffers from none of their shortcomings. More reliable
than patch-macos, more performant and complete than
exec-path-from-shell, and easily handled by bin/doom.
helm-projectile-find-file misbehaves as a workspace project-switch
handler (likely because it runs asynchronously and misses the lexical
value of `default-directory`), so we avoid it and use
projectile-find-file directly (which still uses helm, just not the
helm-projectile package).
Fix modeline icons in daemon-spawned graphical frames. We have our own
mechanism for disabling all-the-icons, so we don't need doom-modeline to
do it for us. However, this may cause unwanted padding in the modeline
in daemon-spawned terminal frames. If it bothers you, you may prefer
`doom-modeline-icon' set to `nil'.
