If Doom doesn't live in ~/.emacs.d or ~/.config/emacs, then it cannot
play the role of bootloader, so opt out of generating the profile
bootstrappper in this case.
That said, don't disable the profile system entirely; it can still be
useful for internal, noninteractive, and sandbox use.
So that the resulting file expands to less code and doesn't apply too
magic to file paths (it may be unwanted).
And don't try to unintern a lexical binding.
Fixes two issues with implicit profiles:
1. Where user-emacs-directory (and sometimes doom-user-dir) would be
unexpanded in the profile init file (generated by 'doom profiles
sync'), which would be ineffective at runtime.
2. Where an implicit profile with a .doomprofile that lacks a
user-emacs-directory setting would not have any user-emacs-directory
set for it at all. Instead, it should fall back to that profile's
location.
The sudden spike in CPU and memory utilization alarms people, so I've
reduced how many cores native-comp will use. In non-interactive
sessions, it will use all of them, however (that is, when I later
introduce an AOT switch).
You can still override this by setting native-comp-async-jobs-number or
comp-num-cpus yourself.
I use advice instead of setting comp-num-cpus so that users to avoid
trampling on default behavior, or attempts by the user to change them.
It really isn't important if this function succeeds or not, but it seems
its stability is highly variable, dependent on your specific build and
version of Emacs. Since there are a lot of 29 Doom users, best to be
more permissive and simply fall back to byte-compilation if native-comp
fails.
consult--grep-lookahead-p throws an error if argv[0] can't be found, and
so will require if consult isn't installed (which would be redundant
with the package checks the doctor already does). To prevent misleading
backtraces here, I've suppressed the latter issue, but the former will
need attention later.
Causing the envvar file to be generated to wrong place, and thus never
be updated/properly loaded at runtime.
This new setting is for later, where I'll integrate the envvar generate
into the profile generator proper.
user-emacs-directory is nil in batch sessions, which early-init.el
wasn't expecting, which caused bin/doom to refuse to run out of a
non-standard location.
Fix: #6777
Doom replaces `org-insert-heading`, but its replacement does not respect
`org-insert-heading-hook`. This commit fixes that, enabling folks to
customize their insert-heading behavior, e.g. adding a time stamp:
(defun my/org-set-creation-date-heading-property ()
(save-excursion
(org-back-to-heading)
(org-set-property "CREATED" (format-time-string "[%Y-%m-%d %T]"))))
(add-hook 'org-insert-heading-hook #'my/org-set-creation-date-heading-property)
Ref: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n6187
Ref: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n1615
This setting (along with load-file-rep-suffixes) is simplified at
startup to optimize file IO at startup, but it was supposed to be undone
at the end of doom-start (in doom-before-init-hook). Unfortunately, the
restoration hook was not reaching their top-level bindings, causing
dynamic modules (like vterm-modules.so) to fail to load.
Where they will be further generalized, later.
This also prevents an issue where org was loaded while the profile init
files are generated, which caused a warning about org-loaddefs which
introduces a noticable delay.
I forgot to add the definitions for the 'doom profile{s,}' commands in
b914830, which causes "unrecognized command 'profiles sync'" errors on
'doom {sync,upgrade}'.
My unparalleled brilliance is 4 parallel universes ahead of me, clearly.
Amend: b914830403
Overriding `ivy--flx-featurep` here would always prevent flx from being
loaded and enabled---even if it were `t`---because ivy `require`s it in
`ivy--flx-featurep`'s initvalue. So instead, this sets the variable if
and only if it should be disabled. Because flx isn't installed when
+prescient is enabled, I've included that in the condition for disabling
ivy--flx-featurep as well
Fix: https://github.com/doomemacs/doomemacs/issues/6034
Amend: bae7ab0d8d
The doom-modules table should reflect the user's intentions, not the
actual state of its modules (e.g. by omitting modules that couldn't be
found at activation time).
