If early-init.el is loaded by another doomscript that uses
--init-directory or --profile for its own purposes, then they could
unintentionally alter user-emacs-directory. Lets only respect the
envvars in noninteractive sessions.
- Adds $DOOMPROFILELOADFILE: Controls where to read and write the
profile loader. Changing this may be helpful for users on nix/guix,
who have deployed Doom to a read-only location. This sets
`doom-profile-load-file`.
- Changed profile load file's default location (used to be
$EMACSDIR/profiles/init.el, is now $EMACSDIR/profiles/load.el). The
gitignore was updated to reflect this.
- Adds $DOOMPROFILELOADPATH: A colon-delimited list of profile config
files and directories (semi-colon on Windows) which dictate what Doom
reads in order to discover your profiles. Config files are required to
have an *.el extension. This sets `doom-profile-load-path`.
- Changes the nomenclature around this loader script. I used to refer to
it as the profile bootstrapper. I'll now refer to it as the profile
load file, and I've renamed `doom-profiles-bootstrap-file` to
`doom-profile-load-file` to reflect this.
- The variables `doom-profile-dirs` and `doom-profile-config-files` were
merged into doom-profile-load-path.
- Both envvars have also been documented in `doom help` (and
$DOOMPROFILE's has been updated).
Ref: #6794
Particularly DOOMPROFILE, without which the --profile switch wasn't
actually doing anything, and profile sessions would (silently) use the
default user-emacs-directory and doom-user-dir.
- Swap out the funcall+alist lookup for a pcase (which is expanded to a
cond, which is is faster and easier to read).
- Wrap bootstrap file to $EMACSDIR/profiles/init.el, but byte-compile it
to $EMACSDIR/profiles/init.X.el where X is emacs-major-version.
- Make doom-profiles-save's second argument optional (defaults to
doom-profiles-bootstrap-file).
- Make doom-profiles-save throw a error if byte-compilation fails for
some reason.
- Rename the tempvars to include 'doom' in their name, so debuggers know
where they originate.
In this commit I start using doom-profile-*-dir vars, though it will
make no difference to the default Doom install (only to profiles, and in
the future, in v3, where we'll drop $EMACSDIR/.local entirely).
The profile bootstrap file's first form is the doom-version it was
generated with. If this has changed, it should be considered outdated,
even if the user's profiles haven't changed.
I misunderstood the issue in 1081588. `user-emacs-directory` is never
nil, even in batch sessions. Instead, it is simply set to the wrong path
in cases where Doom is deployed to a non-standard location. It's needed
to change it there, but never in interactive sessions.
Fix: #6777
Amend: 108158876c
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.
