2022-07-30 21:49:00 +02:00
|
|
|
;;; doom.el --- the heart of the beast -*- lexical-binding: t; -*-
|
2022-06-18 15:04:12 +02:00
|
|
|
;;
|
|
|
|
|
;; Author: Henrik Lissner <contact@henrik.io>
|
|
|
|
|
;; URL: https://github.com/doomemacs/doomemacs
|
|
|
|
|
;;
|
|
|
|
|
;; ================= =============== =============== ======== ========
|
|
|
|
|
;; \\ . . . . . . .\\ //. . . . . . .\\ //. . . . . . .\\ \\. . .\\// . . //
|
|
|
|
|
;; ||. . ._____. . .|| ||. . ._____. . .|| ||. . ._____. . .|| || . . .\/ . . .||
|
|
|
|
|
;; || . .|| ||. . || || . .|| ||. . || || . .|| ||. . || ||. . . . . . . ||
|
|
|
|
|
;; ||. . || || . .|| ||. . || || . .|| ||. . || || . .|| || . | . . . . .||
|
|
|
|
|
;; || . .|| ||. _-|| ||-_ .|| ||. . || || . .|| ||. _-|| ||-_.|\ . . . . ||
|
|
|
|
|
;; ||. . || ||-' || || `-|| || . .|| ||. . || ||-' || || `|\_ . .|. .||
|
|
|
|
|
;; || . _|| || || || || ||_ . || || . _|| || || || |\ `-_/| . ||
|
|
|
|
|
;; ||_-' || .|/ || || \|. || `-_|| ||_-' || .|/ || || | \ / |-_.||
|
|
|
|
|
;; || ||_-' || || `-_|| || || ||_-' || || | \ / | `||
|
|
|
|
|
;; || `' || || `' || || `' || || | \ / | ||
|
|
|
|
|
;; || .===' `===. .==='.`===. .===' /==. | \/ | ||
|
|
|
|
|
;; || .==' \_|-_ `===. .===' _|_ `===. .===' _-|/ `== \/ | ||
|
|
|
|
|
;; || .==' _-' `-_ `=' _-' `-_ `=' _-' `-_ /| \/ | ||
|
|
|
|
|
;; || .==' _-' '-__\._-' '-_./__-' `' |. /| | ||
|
|
|
|
|
;; ||.==' _-' `' | /==.||
|
|
|
|
|
;; ==' _-' \/ `==
|
|
|
|
|
;; \ _-' `-_ /
|
|
|
|
|
;; `'' ``'
|
|
|
|
|
;;
|
|
|
|
|
;; These demons are not part of GNU Emacs.
|
|
|
|
|
;;
|
|
|
|
|
;;; Commentary:
|
|
|
|
|
;;
|
|
|
|
|
;; This is Doom's heart, where I define all its major constants and variables,
|
|
|
|
|
;; set its saner global defaults, then prepare Emacs to bootstrap Doom.
|
|
|
|
|
;;
|
|
|
|
|
;; The overall load order of Doom is as follows:
|
|
|
|
|
;;
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
;; > $EMACSDIR/early-init.el
|
|
|
|
|
;; > $EMACSDIR/lisp/doom.el
|
|
|
|
|
;; - $EMACSDIR/lisp/doom-lib.el
|
|
|
|
|
;; > $EMACSDIR/lisp/doom-start.el
|
|
|
|
|
;; - hook: `doom-before-init-hook'
|
|
|
|
|
;; - $DOOMDIR/init.el
|
2022-09-23 22:12:25 +02:00
|
|
|
;; - hook: `before-init-hook'
|
fix: add :depth field to modules
This introduces a depth field for modules so that they may dictate their
load order explicitly, it also treats depths <= -100 or >= 100 as
special depths, which will be loaded early, before their respective
doom-{before,after}-module-{init,config}-hook. This permits psuedo
modules like :core and :user modules to be treated as normal modules
without too many special cases.
This also fixes a module load order issue on Emacs 29 (#6813), caused by
emacs-mirror/emacs@4311bd0bd73c, which changed the return value order of
hash-table-{keys,values} causing modules to be loaded in reverse order;
resulting in the loss of evil keybinds, among other things.
Other notable changes:
- Changes the data structure for module data caches from a list to a
vector. Uses less memory and permits faster lookups. Also adds two
depth fields to the front of it.
- Changes the signature of doom-module-list and doom-package-list.
- Renames doom--read-packages -> doom-packages--read for consistency
with naming convention.
- Add doom-module-depth function.
- Adds a temporary doom-core-dir/init.el file, which is responsible for
loading doom-*.el.
Fix: #6813
Ref: emacs-mirror/emacs@4311bd0bd73c
2022-09-23 18:55:20 +02:00
|
|
|
;; > $XDG_DATA_HOME/doom/$PROFILE/@/$VERSION/init.el (replaces $EMACSDIR/init.el)
|
|
|
|
|
;; - $EMACSDIR/doom-{keybinds,ui,projects,editor}.el
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
;; - hook: `doom-before-modules-init-hook'
|
|
|
|
|
;; - {$DOOMDIR,$EMACSDIR}/modules/*/*/init.el
|
|
|
|
|
;; - hook: `doom-after-modules-init-hook'
|
|
|
|
|
;; - hook: `doom-before-modules-config-hook'
|
|
|
|
|
;; - {$DOOMDIR,$EMACSDIR}/modules/*/*/config.el
|
|
|
|
|
;; - hook: `doom-after-modules-config-hook'
|
|
|
|
|
;; - $DOOMDIR/config.el
|
|
|
|
|
;; - `custom-file' or $DOOMDIR/custom.el
|
2022-09-23 22:12:25 +02:00
|
|
|
;; - hook: `after-init-hook'
|
|
|
|
|
;; - hook: `emacs-startup-hook'
|
|
|
|
|
;; - hook: `window-setup-hook'
|
|
|
|
|
;; - hook: `doom-init-ui-hook'
|
|
|
|
|
;; - hook: `doom-after-init-hook'
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
;; > After startup is complete:
|
|
|
|
|
;; - On first input: `doom-first-input-hook'
|
|
|
|
|
;; - On first switched-to buffer: `doom-first-buffer-hook'
|
|
|
|
|
;; - On first opened file: `doom-first-file-hook'
|
|
|
|
|
;;
|
2024-03-11 00:47:13 -04:00
|
|
|
;; This file is Doom's heart, where I define all its major constants and
|
|
|
|
|
;; variables, set only its sanest global defaults, employ its hackiest (and
|
|
|
|
|
;; least offensive) optimizations, and load the minimum needed for all Doom
|
|
|
|
|
;; sessions, interactive or otherwise.
|
|
|
|
|
;;
|
|
|
|
|
;; See doom-start.el for initialization intended solely for interactive
|
|
|
|
|
;; sessions, and doom-cli.el for non-interactive sessions.
|
2022-06-18 15:04:12 +02:00
|
|
|
;;
|
|
|
|
|
;;; Code:
|
2023-07-22 18:12:19 +02:00
|
|
|
|
|
|
|
|
;; For `when-let' and `if-let' on versions of Emacs before they were autoloaded.
|
2022-09-15 23:41:02 +02:00
|
|
|
(eval-when-compile (require 'subr-x))
|
2017-01-16 23:15:48 -05:00
|
|
|
|
2022-09-13 18:00:34 +02:00
|
|
|
(eval-and-compile ; Check version at both compile and runtime.
|
|
|
|
|
;; Doom's minimum supported version of Emacs is 27.1. Its my goal to support
|
|
|
|
|
;; one major version below the stable release, for about a year or until
|
|
|
|
|
;; stable is ubiquitous (or at least easily accessible) across Linux distros.
|
|
|
|
|
(when (< emacs-major-version 27)
|
|
|
|
|
(user-error
|
|
|
|
|
(concat
|
2024-06-28 16:54:08 -04:00
|
|
|
"Detected Emacs " emacs-version ", but Doom requires 27.1 or newer (29.4 is\n\n"
|
2022-09-15 23:28:01 +02:00
|
|
|
"recommended). The current Emacs executable in use is:\n\n " (car command-line-args)
|
|
|
|
|
"\n\nA guide for installing a newer version of Emacs can be found at:\n\n "
|
2022-09-13 18:00:34 +02:00
|
|
|
(format "https://docs.doomemacs.org/-/install/%s"
|
|
|
|
|
(cond ((eq system-type 'darwin) "on-macos")
|
|
|
|
|
((memq system-type '(cygwin windows-nt ms-dos)) "on-windows")
|
|
|
|
|
("on-linux")))
|
|
|
|
|
"\n\n"
|
2022-09-15 23:28:01 +02:00
|
|
|
(if noninteractive
|
|
|
|
|
(concat "Alternatively, either update your $PATH environment variable to include the\n"
|
|
|
|
|
"path of the desired Emacs executable OR alter the $EMACS environment variable\n"
|
|
|
|
|
"to specify the exact path or command needed to invoke Emacs."
|
2022-09-24 11:01:49 +02:00
|
|
|
(when-let ((script (cadr (member "--load" command-line-args)))
|
|
|
|
|
(command (file-name-nondirectory script)))
|
2022-09-15 23:28:01 +02:00
|
|
|
(concat " For example:\n\n"
|
|
|
|
|
" $ EMACS=/path/to/valid/emacs " command " ...\n"
|
|
|
|
|
" $ EMACS=\"/Applications/Emacs.app/Contents/MacOS/Emacs\" " command " ...\n"
|
|
|
|
|
" $ EMACS=\"snap run emacs\" " command " ..."))
|
|
|
|
|
"\n\nAborting...")
|
|
|
|
|
(concat "If you believe this error is a mistake, run 'doom doctor' on the command line\n"
|
|
|
|
|
"to diagnose common issues with your config and system."))))))
|
2022-09-06 22:28:52 +02:00
|
|
|
|
|
|
|
|
;; Doom needs to be synced/rebuilt if either Doom or Emacs has been
|
|
|
|
|
;; up/downgraded. This is because byte-code isn't backwards compatible, and many
|
2024-02-04 17:59:31 -05:00
|
|
|
;; packages (including Doom), bake in absolute paths into their caches that need
|
2022-09-06 22:28:52 +02:00
|
|
|
;; to be refreshed.
|
|
|
|
|
(let ((old-version (eval-when-compile emacs-version)))
|
|
|
|
|
(unless (equal emacs-version old-version)
|
|
|
|
|
(user-error (concat "Doom was compiled with Emacs %s, but was loaded with %s. Run 'doom sync' to"
|
|
|
|
|
"recompile it.")
|
|
|
|
|
emacs-version old-version)))
|
2021-10-09 19:31:21 +02:00
|
|
|
|
2023-12-05 17:05:13 -05:00
|
|
|
;;; Custom features & global constants
|
|
|
|
|
;; Doom has its own features that its modules, CLI, and user extensions can
|
|
|
|
|
;; announce, and don't belong in `features', so they are stored here, which can
|
2024-03-11 00:47:13 -04:00
|
|
|
;; include information about the external system environment. Module-specific
|
|
|
|
|
;; features are kept elsewhere, however.
|
2023-12-05 17:05:13 -05:00
|
|
|
(defconst doom-features
|
|
|
|
|
(pcase system-type
|
|
|
|
|
('darwin '(macos bsd))
|
|
|
|
|
((or 'cygwin 'windows-nt 'ms-dos) '(windows))
|
|
|
|
|
((or 'gnu 'gnu/linux) '(linux))
|
2024-09-07 00:53:20 -04:00
|
|
|
((or 'gnu/kfreebsd 'berkeley-unix) '(linux bsd))
|
|
|
|
|
('android '(android)))
|
2023-12-05 17:05:13 -05:00
|
|
|
"A list of symbols denoting available features in the active Doom profile.")
|
|
|
|
|
|
|
|
|
|
;; Convenience aliases for internal use only (may be removed later).
|
|
|
|
|
(defconst doom-system (car doom-features))
|
|
|
|
|
(defconst doom--system-windows-p (eq 'windows doom-system))
|
|
|
|
|
(defconst doom--system-macos-p (eq 'macos doom-system))
|
|
|
|
|
(defconst doom--system-linux-p (eq 'linux doom-system))
|
|
|
|
|
|
|
|
|
|
;; `system-type' is esoteric, so I create a pseudo feature as a stable and
|
|
|
|
|
;; consistent alternative, and all while using the same `featurep' interface
|
|
|
|
|
;; we're already familiar with.
|
|
|
|
|
(push :system features)
|
|
|
|
|
(put :system 'subfeatures doom-features)
|
|
|
|
|
|
2023-03-22 23:25:25 -04:00
|
|
|
;; Emacs needs a more consistent way to detect build features, and the docs
|
|
|
|
|
;; claim `system-configuration-features' is not da way. Some features (that
|
|
|
|
|
;; don't represent packages) can be found in `features' (which `featurep'
|
|
|
|
|
;; consults), but aren't consistent, so I'll impose some consistency:
|
2022-09-14 17:57:03 +02:00
|
|
|
(if (bound-and-true-p module-file-suffix)
|
|
|
|
|
(push 'dynamic-modules features))
|
|
|
|
|
(if (fboundp #'json-parse-string)
|
|
|
|
|
(push 'jansson features))
|
2023-12-05 17:09:36 -05:00
|
|
|
(if (string-match-p "HARFBUZZ" system-configuration-features) ; no alternative
|
|
|
|
|
(push 'harfbuzz features))
|
|
|
|
|
|
2023-12-02 11:25:54 -05:00
|
|
|
;; The `native-compile' feature exists whether or not it is functional (e.g.
|
2024-08-15 23:18:47 -04:00
|
|
|
;; libgcc is available or not). This seems silly, as some packages will blindly
|
|
|
|
|
;; use the native-comp API if it's present, whether or not it's functional. so
|
|
|
|
|
;; pretend it doesn't exist if that's the case.
|
2022-09-14 17:57:03 +02:00
|
|
|
(if (featurep 'native-compile)
|
|
|
|
|
(if (not (native-comp-available-p))
|
|
|
|
|
(delq 'native-compile features)))
|
|
|
|
|
|
|
|
|
|
;; DEPRECATED remove in v3
|
2023-12-05 17:05:13 -05:00
|
|
|
(with-no-warnings
|
|
|
|
|
(defconst IS-MAC doom--system-macos-p)
|
|
|
|
|
(defconst IS-LINUX doom--system-linux-p)
|
|
|
|
|
(defconst IS-WINDOWS doom--system-windows-p)
|
|
|
|
|
(defconst IS-BSD (memq 'bsd doom-features))
|
|
|
|
|
(defconst EMACS28+ (> emacs-major-version 27))
|
|
|
|
|
(defconst EMACS29+ (> emacs-major-version 28))
|
|
|
|
|
(defconst MODULES (featurep 'dynamic-modules))
|
|
|
|
|
(defconst NATIVECOMP (featurep 'native-compile))
|
|
|
|
|
|
|
|
|
|
(make-obsolete-variable 'IS-MAC "Use (featurep :system 'macos) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'IS-LINUX "Use (featurep :system 'linux) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'IS-WINDOWS "Use (featurep :system 'windows) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'IS-BSD "Use (featurep :system 'bsd) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'EMACS28+ "Use (>= emacs-major-version 28) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'EMACS29+ "Use (>= emacs-major-version 29) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'MODULES "Use (featurep 'dynamic-modules) instead" "3.0.0")
|
|
|
|
|
(make-obsolete-variable 'NATIVECOMP "Use (featurep 'native-compile) instead" "3.0.0"))
|
|
|
|
|
|
2022-09-13 14:06:56 +02:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Fix $HOME on Windows
|
|
|
|
|
;; $HOME isn't normally defined on Windows, but many unix tools expect it.
|
2023-12-05 17:05:13 -05:00
|
|
|
(when doom--system-windows-p
|
2022-09-14 17:57:03 +02:00
|
|
|
(when-let (realhome
|
|
|
|
|
(and (null (getenv-internal "HOME"))
|
|
|
|
|
(getenv "USERPROFILE")))
|
|
|
|
|
(setenv "HOME" realhome)
|
|
|
|
|
(setq abbreviated-home-dir nil)))
|
2022-09-13 14:06:56 +02:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Load Doom's stdlib
|
|
|
|
|
(add-to-list 'load-path (file-name-directory load-file-name))
|
|
|
|
|
(require 'doom-lib)
|
2022-06-18 15:04:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
;;
|
2022-09-13 13:08:37 +02:00
|
|
|
;;; Core globals
|
|
|
|
|
|
|
|
|
|
(defgroup doom nil
|
2024-08-15 23:24:56 -04:00
|
|
|
"A development framework for Emacs configurations and Emacs Lisp projects."
|
2023-07-22 18:12:19 +02:00
|
|
|
:link '(url-link "https://doomemacs.org")
|
|
|
|
|
:group 'emacs)
|
2022-09-13 13:08:37 +02:00
|
|
|
|
2022-09-15 03:19:48 +02:00
|
|
|
(defconst doom-version "3.0.0-pre"
|
2022-09-13 13:08:37 +02:00
|
|
|
"Current version of Doom Emacs core.")
|
|
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;; DEPRECATED: Remove these when the modules are moved out of core.
|
2024-08-31 21:39:56 -04:00
|
|
|
(defconst doom-modules-version "24.10.0-pre"
|
2022-09-13 13:08:37 +02:00
|
|
|
"Current version of Doom Emacs.")
|
|
|
|
|
|
2022-09-23 22:03:38 +02:00
|
|
|
(defvar doom-init-time nil
|
2024-08-15 23:24:56 -04:00
|
|
|
"The time it took, in seconds (as a float), for Doom Emacs to start up.")
|
2022-09-23 22:03:38 +02:00
|
|
|
|
2022-09-13 13:08:37 +02:00
|
|
|
(defconst doom-profile
|
|
|
|
|
(if-let (profile (getenv-internal "DOOMPROFILE"))
|
2022-09-14 17:57:03 +02:00
|
|
|
(save-match-data
|
|
|
|
|
(if (string-match "^\\([^@]+\\)@\\(.+\\)$" profile)
|
|
|
|
|
(cons (match-string 1 profile)
|
|
|
|
|
(match-string 2 profile))
|
|
|
|
|
(cons profile "0")))
|
|
|
|
|
;; TODO Restore this in 3.0
|
|
|
|
|
;; (cons "_" "0")
|
2022-09-13 13:08:37 +02:00
|
|
|
)
|
2022-09-14 17:57:03 +02:00
|
|
|
"The active profile as a cons cell (NAME . VERSION).")
|
2022-09-13 13:08:37 +02:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Data directory variables
|
2022-09-17 20:10:03 +02:00
|
|
|
(defvar doom-emacs-dir user-emacs-directory
|
2022-09-13 13:08:37 +02:00
|
|
|
"The path to the currently loaded .emacs.d directory. Must end with a slash.")
|
|
|
|
|
|
|
|
|
|
(defconst doom-core-dir (file-name-directory load-file-name)
|
|
|
|
|
"The root directory of Doom's core files. Must end with a slash.")
|
|
|
|
|
|
2022-09-17 20:10:03 +02:00
|
|
|
(defvar doom-modules-dir (expand-file-name "modules/" doom-emacs-dir)
|
2019-05-01 19:12:52 -04:00
|
|
|
"The root directory for Doom's modules. Must end with a slash.")
|
2018-02-16 02:02:58 -05:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
(define-obsolete-variable-alias 'doom-private-dir 'doom-user-dir "3.0.0")
|
2022-09-17 20:10:03 +02:00
|
|
|
(defvar doom-user-dir
|
2022-09-13 14:06:56 +02:00
|
|
|
(expand-file-name
|
|
|
|
|
(if-let (doomdir (getenv-internal "DOOMDIR"))
|
|
|
|
|
(file-name-as-directory doomdir)
|
|
|
|
|
(or (let ((xdgdir
|
|
|
|
|
(file-name-concat
|
|
|
|
|
(or (getenv-internal "XDG_CONFIG_HOME")
|
|
|
|
|
"~/.config")
|
|
|
|
|
"doom/")))
|
|
|
|
|
(if (file-directory-p xdgdir) xdgdir))
|
|
|
|
|
"~/.doom.d/")))
|
2022-07-27 22:25:08 +02:00
|
|
|
"Where your private configuration is placed.
|
|
|
|
|
|
|
|
|
|
Defaults to ~/.config/doom, ~/.doom.d or the value of the DOOMDIR envvar;
|
|
|
|
|
whichever is found first. Must end in a slash.")
|
|
|
|
|
|
2024-08-24 16:36:01 -04:00
|
|
|
(defvar doom-bin-dir (expand-file-name "bin/" doom-emacs-dir)
|
|
|
|
|
"Where Doom's executables are stored.
|
|
|
|
|
|
|
|
|
|
Defaults to $EMACSDIR/bin, where $EMACSDIR is `doom-emacs-dir'. Must end in a
|
|
|
|
|
slash.")
|
|
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
;; DEPRECATED: .local will be removed entirely in 3.0
|
|
|
|
|
(defvar doom-local-dir
|
2021-10-09 19:31:21 +02:00
|
|
|
(if-let (localdir (getenv-internal "DOOMLOCALDIR"))
|
|
|
|
|
(expand-file-name (file-name-as-directory localdir))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
(expand-file-name ".local/" doom-emacs-dir))
|
2019-05-01 19:12:52 -04:00
|
|
|
"Root directory for local storage.
|
|
|
|
|
|
|
|
|
|
Use this as a storage location for this system's installation of Doom Emacs.
|
2020-10-11 16:22:57 -04:00
|
|
|
|
2019-05-01 19:12:52 -04:00
|
|
|
These files should not be shared across systems. By default, it is used by
|
2022-08-14 18:10:01 +02:00
|
|
|
`doom-data-dir' and `doom-cache-dir'. Must end with a slash.")
|
2017-03-16 23:38:22 -04:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
(define-obsolete-variable-alias 'doom-etc-dir 'doom-data-dir "3.0.0")
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
(defvar doom-data-dir
|
2022-07-27 22:25:08 +02:00
|
|
|
(if doom-profile
|
2023-12-05 17:05:13 -05:00
|
|
|
(if doom--system-windows-p
|
2024-09-07 18:05:19 -04:00
|
|
|
(expand-file-name "doomemacs/data/" (getenv-internal "LOCALAPPDATA"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
(expand-file-name "doom/" (or (getenv-internal "XDG_DATA_HOME") "~/.local/share")))
|
|
|
|
|
;; DEPRECATED: .local will be removed entirely in 3.0
|
2022-09-17 11:00:08 +02:00
|
|
|
(file-name-concat doom-local-dir "etc/"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
"Where Doom stores its global data files.
|
|
|
|
|
|
|
|
|
|
Data files contain shared and long-lived data that Doom, Emacs, and their
|
|
|
|
|
packages require to function correctly or at all. Deleting them by hand will
|
2023-12-05 17:09:36 -05:00
|
|
|
cause breakage, and require user intervention (e.g. a `doom sync` or `doom env`)
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
to restore.
|
2017-12-22 14:48:07 -05:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
Use this for: server binaries, package source, pulled module libraries,
|
|
|
|
|
generated files for profiles, profiles themselves, autoloads/loaddefs, etc.
|
2017-06-11 23:50:50 +02:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
For profile-local data files, use `doom-profile-data-dir' instead.")
|
|
|
|
|
|
|
|
|
|
(defvar doom-cache-dir
|
2022-07-27 22:25:08 +02:00
|
|
|
(if doom-profile
|
2023-12-05 17:05:13 -05:00
|
|
|
(if doom--system-windows-p
|
2024-09-07 18:05:19 -04:00
|
|
|
(expand-file-name "doomemacs/cache/" (getenv-internal "LOCALAPPDATA"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
(expand-file-name "doom/" (or (getenv-internal "XDG_CACHE_HOME") "~/.cache")))
|
|
|
|
|
;; DEPRECATED: .local will be removed entirely in 3.0
|
2022-09-17 11:00:08 +02:00
|
|
|
(file-name-concat doom-local-dir "cache/"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
"Where Doom stores its global cache files.
|
|
|
|
|
|
2023-12-05 17:09:36 -05:00
|
|
|
Cache files represent unessential data that shouldn't be problematic when
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
deleted (besides, perhaps, a one-time performance hit), lack portability (and so
|
|
|
|
|
shouldn't be copied to other systems/configs), and are regenerated when needed,
|
2023-12-05 17:09:36 -05:00
|
|
|
without user input (e.g. a `doom sync`).
|
2017-01-16 23:15:48 -05:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
Some examples: images/data caches, elisp bytecode, natively compiled elisp,
|
|
|
|
|
session files, ELPA archives, authinfo files, org-persist, etc.
|
2017-04-16 20:36:15 -04:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
For profile-local cache files, use `doom-profile-cache-dir' instead.")
|
|
|
|
|
|
|
|
|
|
(defvar doom-state-dir
|
2022-07-27 22:25:08 +02:00
|
|
|
(if doom-profile
|
2023-12-05 17:05:13 -05:00
|
|
|
(if doom--system-windows-p
|
2024-09-07 18:05:19 -04:00
|
|
|
(expand-file-name "doomemacs/state/" (getenv-internal "LOCALAPPDATA"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
(expand-file-name "doom/" (or (getenv-internal "XDG_STATE_HOME") "~/.local/state")))
|
|
|
|
|
;; DEPRECATED: .local will be removed entirely in 3.0
|
2022-09-17 11:00:08 +02:00
|
|
|
(file-name-concat doom-local-dir "state/"))
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
"Where Doom stores its global state files.
|
|
|
|
|
|
2024-08-15 23:24:56 -04:00
|
|
|
State files contain unessential, non-portable, but persistent data which, if
|
|
|
|
|
lost won't cause breakage, but may be inconvenient as they cannot be
|
|
|
|
|
automatically regenerated or restored. For example, a recently-opened file list
|
|
|
|
|
is not essential, but losing it means losing this record, and restoring it
|
|
|
|
|
requires revisiting all those files.
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
|
|
|
|
|
Use this for: history, logs, user-saved data, autosaves/backup files, known
|
|
|
|
|
projects, recent files, bookmarks.
|
2019-05-01 19:12:52 -04:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
For profile-local state files, use `doom-profile-state-dir' instead.")
|
2018-06-11 23:18:15 +02:00
|
|
|
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
;;; Profile file/directory variables
|
|
|
|
|
(defvar doom-profile-cache-dir
|
|
|
|
|
(file-name-concat doom-cache-dir (car doom-profile))
|
|
|
|
|
"For profile-local cache files under `doom-cache-dir'.")
|
|
|
|
|
|
|
|
|
|
(defvar doom-profile-data-dir
|
|
|
|
|
(file-name-concat doom-data-dir (car doom-profile))
|
|
|
|
|
"For profile-local data files under `doom-data-dir'.")
|
|
|
|
|
|
|
|
|
|
(defvar doom-profile-state-dir
|
|
|
|
|
(file-name-concat doom-state-dir (car doom-profile))
|
|
|
|
|
"For profile-local state files under `doom-state-dir'.")
|
|
|
|
|
|
|
|
|
|
(defconst doom-profile-dir
|
|
|
|
|
(file-name-concat doom-profile-data-dir "@" (cdr doom-profile))
|
2024-08-15 23:24:56 -04:00
|
|
|
"Where generated files for the active profile (for Doom's core) are kept.")
|
refactor!: complete profile gen and init systems
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
2022-09-15 18:53:06 +02:00
|
|
|
|
|
|
|
|
;; DEPRECATED: Will be moved to cli/env
|
2022-07-27 22:25:08 +02:00
|
|
|
(defconst doom-env-file
|
2022-09-13 14:06:56 +02:00
|
|
|
(file-name-concat (if doom-profile
|
|
|
|
|
doom-profile-dir
|
|
|
|
|
doom-local-dir)
|
|
|
|
|
"env")
|
2020-02-19 23:34:16 -05:00
|
|
|
"The location of your envvar file, generated by `doom env`.
|
:boom: Replace exec-path-from-shell w/ 'bin/doom env'
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.
2019-03-28 00:06:10 -04:00
|
|
|
|
2019-05-01 19:12:52 -04:00
|
|
|
This file contains environment variables scraped from your shell environment,
|
|
|
|
|
which is loaded at startup (if it exists). This is helpful if Emacs can't
|
2019-05-02 21:54:47 -04:00
|
|
|
\(easily) be launched from the correct shell session (particularly for MacOS
|
2019-05-01 19:12:52 -04:00
|
|
|
users).")
|
:boom: Replace exec-path-from-shell w/ 'bin/doom env'
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.
2019-03-28 00:06:10 -04:00
|
|
|
|
2020-12-01 19:33:55 -05:00
|
|
|
|
2022-08-13 21:27:11 +02:00
|
|
|
;;
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Startup optimizations
|
2022-08-13 21:27:11 +02:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;; Here are Doom's hackiest (and least offensive) startup optimizations. They
|
2024-04-03 20:15:15 -04:00
|
|
|
;; exploit implementation details and unintended side-effects in Emacs' startup
|
|
|
|
|
;; process, and will change often between major Emacs releases. However, I
|
|
|
|
|
;; disable them if this is a daemon session (where startup time matters less).
|
2022-09-26 12:50:13 +02:00
|
|
|
;;
|
|
|
|
|
;; Most of these have been tested on Linux and on fairly fast machines (with
|
2024-04-03 20:15:15 -04:00
|
|
|
;; SSDs), so your mileage may vary depending on hardware and `window-system'.
|
2022-09-24 21:38:23 +02:00
|
|
|
(unless (daemonp)
|
2022-09-14 17:57:03 +02:00
|
|
|
;; PERF: `file-name-handler-alist' is consulted on each call to `require',
|
|
|
|
|
;; `load', or various file/io functions (like `expand-file-name' or
|
|
|
|
|
;; `file-remote-p'). You get a noteable boost to startup time by unsetting
|
|
|
|
|
;; or simplifying its value.
|
2022-09-14 19:01:57 +02:00
|
|
|
(let ((old-value (default-toplevel-value 'file-name-handler-alist)))
|
2023-12-05 17:20:34 -05:00
|
|
|
(set-default-toplevel-value
|
|
|
|
|
'file-name-handler-alist
|
2024-04-03 20:15:15 -04:00
|
|
|
;; HACK: The libraries bundled with Emacs can either be compiled,
|
|
|
|
|
;; compressed, or neither. We use calc-loaddefs.el as a heuristic to
|
|
|
|
|
;; guess what state all these libraries are in. If they're compressed, we
|
|
|
|
|
;; need to leave the gzip file handler in `file-name-handler-alist' so
|
|
|
|
|
;; Emacs knows how to load them. If they're compiled or neither, we can
|
|
|
|
|
;; omit the gzip handler altogether (at least during startup) for a boost
|
|
|
|
|
;; in startup and package load time.
|
2023-12-05 17:20:34 -05:00
|
|
|
(if (eval-when-compile
|
|
|
|
|
(locate-file-internal "calc-loaddefs.el" load-path))
|
|
|
|
|
nil
|
|
|
|
|
(list (rassq 'jka-compr-handler old-value))))
|
2022-09-26 12:41:00 +02:00
|
|
|
;; Remember it so it can be reset where needed.
|
|
|
|
|
(put 'file-name-handler-alist 'initial-value old-value)
|
2024-08-18 16:12:42 -04:00
|
|
|
;; COMPAT: Eventually, Emacs will process any files passed to it via the
|
|
|
|
|
;; command line, and will do so *really* early in the startup process.
|
|
|
|
|
;; These might contain special file paths like TRAMP paths, so restore
|
|
|
|
|
;; `file-name-handler-alist' just for this portion of startup.
|
|
|
|
|
(define-advice command-line-1 (:around (fn args-left) respect-file-handlers)
|
|
|
|
|
(let ((file-name-handler-alist (if args-left old-value file-name-handler-alist)))
|
|
|
|
|
(funcall fn args-left)))
|
2022-09-14 17:57:03 +02:00
|
|
|
;; COMPAT: ...but restore `file-name-handler-alist' later, because it is
|
|
|
|
|
;; needed for handling encrypted or compressed files, among other things.
|
|
|
|
|
(add-hook! 'emacs-startup-hook :depth 101
|
|
|
|
|
(defun doom--reset-file-handler-alist-h ()
|
2023-12-05 17:20:34 -05:00
|
|
|
(set-default-toplevel-value
|
|
|
|
|
'file-name-handler-alist
|
|
|
|
|
;; Merge instead of overwrite because there may have been changes to
|
|
|
|
|
;; `file-name-handler-alist' since startup we want to preserve.
|
|
|
|
|
(delete-dups (append file-name-handler-alist old-value))))))
|
2022-08-13 21:27:11 +02:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
(unless noninteractive
|
|
|
|
|
;; PERF: Resizing the Emacs frame (to accommodate fonts that are smaller or
|
2024-08-15 23:18:47 -04:00
|
|
|
;; larger than the default system font) can impact startup time
|
2024-04-03 20:15:15 -04:00
|
|
|
;; dramatically. The larger the delta, the greater the delay. Even trivial
|
2024-08-15 23:18:47 -04:00
|
|
|
;; deltas can yield up to a ~1000ms loss, depending also on
|
|
|
|
|
;; `window-system' (PGTK builds seem least affected and NS/MAC the most).
|
2022-09-14 17:57:03 +02:00
|
|
|
(setq frame-inhibit-implied-resize t)
|
2022-08-13 21:27:11 +02:00
|
|
|
|
2024-04-03 20:15:15 -04:00
|
|
|
;; PERF: A fair bit of startup time goes into initializing the splash and
|
|
|
|
|
;; scratch buffers in the typical Emacs session (b/c they activate a
|
|
|
|
|
;; non-trivial major mode, generate the splash buffer, and trigger
|
|
|
|
|
;; premature frame redraws by writing to *Messages*). These hacks prevent
|
|
|
|
|
;; most of this work from happening for some decent savings in startup
|
|
|
|
|
;; time. Our dashboard and `doom/open-scratch-buffer' provide a faster
|
|
|
|
|
;; (and more useful) alternative anyway.
|
2022-09-14 17:57:03 +02:00
|
|
|
(setq inhibit-startup-screen t
|
2024-04-03 20:15:15 -04:00
|
|
|
inhibit-startup-echo-area-message user-login-name
|
|
|
|
|
initial-major-mode 'fundamental-mode
|
|
|
|
|
initial-scratch-message nil)
|
|
|
|
|
;; PERF,UX: Prevent "For information about GNU Emacs..." line in *Messages*.
|
2022-09-14 17:57:03 +02:00
|
|
|
(advice-add #'display-startup-echo-area-message :override #'ignore)
|
2022-09-26 12:32:30 +02:00
|
|
|
;; PERF: Suppress the vanilla startup screen completely. We've disabled it
|
|
|
|
|
;; with `inhibit-startup-screen', but it would still initialize anyway.
|
2024-04-03 20:15:15 -04:00
|
|
|
;; This involves file IO and/or bitmap work (depending on the frame type)
|
|
|
|
|
;; that we can no-op for a free 50-100ms saving in startup time.
|
2022-09-26 12:32:30 +02:00
|
|
|
(advice-add #'display-startup-screen :override #'ignore)
|
2016-05-26 18:51:39 -04:00
|
|
|
|
2022-09-15 23:43:49 +02:00
|
|
|
(unless initial-window-system
|
2024-04-03 20:15:15 -04:00
|
|
|
;; PERF: `tty-run-terminal-initialization' can take 2-3s when starting up
|
|
|
|
|
;; TTY Emacs (non-daemon sessions), depending on your TERM, TERMINFO,
|
|
|
|
|
;; and TERMCAP, but this work isn't very useful on modern systems (the
|
|
|
|
|
;; type I expect Doom's users to be using). The function seems less
|
|
|
|
|
;; expensive if run later in the startup process, so I defer it.
|
|
|
|
|
;; REVIEW: This may no longer be needed in 29+. Needs testing!
|
2022-09-24 11:01:49 +02:00
|
|
|
(define-advice tty-run-terminal-initialization (:override (&rest _) defer)
|
|
|
|
|
(advice-remove #'tty-run-terminal-initialization #'tty-run-terminal-initialization@defer)
|
|
|
|
|
(add-hook 'window-setup-hook
|
|
|
|
|
(doom-partial #'tty-run-terminal-initialization
|
|
|
|
|
(selected-frame) nil t))))
|
2022-09-14 17:57:03 +02:00
|
|
|
|
2024-04-03 20:15:15 -04:00
|
|
|
;; PERF: `load-suffixes' and `load-file-rep-suffixes' are consulted on each
|
2024-08-15 23:18:47 -04:00
|
|
|
;; `require' and `load'. Doom won't load any modules this early, so I omit
|
|
|
|
|
;; *.so for a tiny startup boost. Is later restored in `doom-start'.
|
2024-03-19 21:30:16 -04:00
|
|
|
(put 'load-suffixes 'initial-value (default-toplevel-value 'load-suffixes))
|
|
|
|
|
(put 'load-file-rep-suffixes 'initial-value (default-toplevel-value 'load-file-rep-suffixes))
|
|
|
|
|
(set-default-toplevel-value 'load-suffixes '(".elc" ".el"))
|
|
|
|
|
(set-default-toplevel-value 'load-file-rep-suffixes '(""))
|
2024-08-15 23:18:47 -04:00
|
|
|
;; COMPAT: Undo any problematic startup optimizations eventually, to prevent
|
|
|
|
|
;; incompatibilities with anything loaded in userland.
|
2024-03-19 21:30:16 -04:00
|
|
|
(add-hook! 'doom-before-init-hook
|
|
|
|
|
(defun doom--reset-load-suffixes-h ()
|
|
|
|
|
(setq load-suffixes (get 'load-suffixes 'initial-value)
|
|
|
|
|
load-file-rep-suffixes (get 'load-file-rep-suffixes 'initial-value))))
|
|
|
|
|
|
2024-04-03 20:15:15 -04:00
|
|
|
;; PERF: Doom uses `defcustom' merely to announce variables that users may
|
|
|
|
|
;; reconfigure. Trouble is it fires off initializers meant to accommodate
|
|
|
|
|
;; any user attempts to configure them *before* they are defined, which
|
|
|
|
|
;; isn't possible since the user's first opportunity to modify them comes
|
|
|
|
|
;; long after they're defined (in $DOOMDIR/init.el), so this is
|
|
|
|
|
;; unnecessary work. To spare Emacs the startup time, I disable this
|
|
|
|
|
;; behavior until $DOOMDIR is loaded.
|
2024-03-19 21:30:16 -04:00
|
|
|
(setq custom-dont-initialize t)
|
|
|
|
|
(add-hook! 'doom-before-init-hook
|
|
|
|
|
(defun doom--reset-custom-dont-initialize-h ()
|
|
|
|
|
(setq custom-dont-initialize nil)))
|
|
|
|
|
|
2024-09-11 13:57:01 -04:00
|
|
|
;; These optimizations are brittle, difficult to debug, and obscure other
|
|
|
|
|
;; issues, so bow out when debug mode is on.
|
|
|
|
|
(unless init-file-debug
|
|
|
|
|
;; PERF: The mode-line procs a couple dozen times during startup, before
|
|
|
|
|
;; the user even sees the first mode-line. This is normally fast, but we
|
|
|
|
|
;; can't predict what the user (or packages) will put into the
|
|
|
|
|
;; mode-line. Also, mode-line packages have a bad habit of throwing
|
|
|
|
|
;; performance to the wind, so best we just disable the mode-line until
|
|
|
|
|
;; we can see one.
|
|
|
|
|
(put 'mode-line-format 'initial-value (default-toplevel-value 'mode-line-format))
|
|
|
|
|
(setq-default mode-line-format nil)
|
|
|
|
|
(dolist (buf (buffer-list))
|
|
|
|
|
(with-current-buffer buf (setq mode-line-format nil)))
|
|
|
|
|
;; PERF,UX: Premature redisplays/redraws can substantially affect startup
|
|
|
|
|
;; times and/or flash a white/unstyled Emacs frame during startup, so I
|
|
|
|
|
;; try real hard to suppress them until we're sure the session is ready.
|
|
|
|
|
(setq-default inhibit-redisplay t
|
|
|
|
|
inhibit-message t)
|
|
|
|
|
;; COMPAT: If the above vars aren't reset, Emacs could appear frozen or
|
|
|
|
|
;; garbled after startup (or in case of an startup error).
|
|
|
|
|
(defun doom--reset-inhibited-vars-h ()
|
|
|
|
|
(setq-default inhibit-redisplay nil
|
|
|
|
|
inhibit-message nil)
|
|
|
|
|
(remove-hook 'post-command-hook #'doom--reset-inhibited-vars-h))
|
|
|
|
|
(add-hook 'post-command-hook #'doom--reset-inhibited-vars-h -100))
|
2024-03-19 21:30:16 -04:00
|
|
|
|
2024-04-03 20:15:15 -04:00
|
|
|
;; PERF: Doom disables the UI elements by default, so that there's less for
|
|
|
|
|
;; the frame to initialize. However, `tool-bar-setup' is still called and
|
|
|
|
|
;; it does some non-trivial work to set up the toolbar before we can
|
|
|
|
|
;; disable it. To side-step this work, I disable the function and call it
|
|
|
|
|
;; later (see `startup--load-user-init-file@undo-hacks').
|
|
|
|
|
(advice-add #'tool-bar-setup :override #'ignore)
|
|
|
|
|
|
2024-07-12 18:15:26 -04:00
|
|
|
;; PERF,UX: site-lisp files are often obnoxiously noisy (emitting output
|
|
|
|
|
;; that isn't useful to end-users, like load messages, deprecation
|
2024-09-01 13:03:31 -04:00
|
|
|
;; notices, and linter warnings). Displaying these in the minibuffer
|
|
|
|
|
;; causes unnecessary redraws at startup which can impact startup time
|
|
|
|
|
;; drastically and cause flashes of white. It also pollutes the logs. I
|
|
|
|
|
;; suppress it here and load it myself, later, in a more controlled way
|
2024-07-12 18:15:26 -04:00
|
|
|
;; (see `startup--load-user-init-file@undo-hacks').
|
2024-03-19 21:30:16 -04:00
|
|
|
(put 'site-run-file 'initial-value site-run-file)
|
|
|
|
|
(setq site-run-file nil)
|
|
|
|
|
|
2024-08-15 14:04:08 -04:00
|
|
|
(define-advice startup--load-user-init-file (:around (fn &rest args) undo-hacks 95)
|
2024-04-03 20:15:15 -04:00
|
|
|
"Undo Doom's startup optimizations to prep for the user's session."
|
2024-08-15 14:04:08 -04:00
|
|
|
(unwind-protect
|
|
|
|
|
(progn
|
|
|
|
|
(when (setq site-run-file (get 'site-run-file 'initial-value))
|
|
|
|
|
(let ((inhibit-startup-screen inhibit-startup-screen))
|
2024-09-11 13:58:01 -04:00
|
|
|
(letf! ((defun load-file (file)
|
|
|
|
|
(load file nil (not init-file-debug)))
|
2024-08-15 14:04:08 -04:00
|
|
|
(defun load (file &optional noerror _nomessage &rest args)
|
2024-09-11 13:58:01 -04:00
|
|
|
(apply load file noerror (not init-file-debug) args)))
|
|
|
|
|
(load site-run-file t))))
|
2024-08-15 14:04:08 -04:00
|
|
|
(apply fn args))
|
|
|
|
|
;; Now it's safe to be verbose.
|
|
|
|
|
(setq-default inhibit-message nil)
|
|
|
|
|
;; COMPAT: Once startup is sufficiently complete, undo our earlier
|
|
|
|
|
;; optimizations to reduce the scope of potential edge cases.
|
|
|
|
|
(advice-remove #'tool-bar-setup #'ignore)
|
|
|
|
|
(add-transient-hook! 'tool-bar-mode (tool-bar-setup))
|
|
|
|
|
(unless (default-toplevel-value 'mode-line-format)
|
|
|
|
|
(setq-default mode-line-format (get 'mode-line-format 'initial-value)))))
|
2024-03-19 21:30:16 -04:00
|
|
|
|
|
|
|
|
;; PERF: Unset a non-trivial list of command line options that aren't
|
|
|
|
|
;; relevant to this session, but `command-line-1' still processes.
|
|
|
|
|
(unless doom--system-macos-p
|
|
|
|
|
(setq command-line-ns-option-alist nil))
|
|
|
|
|
(unless (memq initial-window-system '(x pgtk))
|
|
|
|
|
(setq command-line-x-option-alist nil))))
|
fix: memory leak & freezes on native-comp+pgtk builds
b7f84bd introduced a nasty regression that caused an infinite loop and
runaway memory usage on some pgtk+native-comp builds of Emacs when it
attempted to perform deferred native compilation of your packages. This
would make Emacs unusable and, if left alone, could even crash your
system.
The only Emacs builds I'm certain are affected are derived from
flatwhatson/emacs (like emacs-pgtk-native-comp on Guix and Arch Linux in
particular). 28.1 stable and master (on emacs-mirror/emacs@e13509468b7c)
are unaffected.
It appears that some, earlier pgtk builds stack idle timers differently.
I'm not entirely sure how, because it doesn't manifest in more recent
builds of Emacs, and I'm already burnt out on debugging this, but here's
how Doom encountered it:
Doom has an incremental package loader; it loads packages, piecemeal,
after Emacs has been idle for 2s, then again every 0.75s until it
finishes or the user sends input (then it waits another 2s before
starting again). However, if at any time the iloader detected that
native-compilation is in progress, it waits 2s before trying
again (repeat, until native-comp is done). But here's the catch, given
the following:
(run-with-idle-timer
2 nil (lambda ()
(run-with-idle-timer 1 nil (lambda () (message "hi")))))
I had assumed "hi" would be emitted after 3 seconds (once idle), but
instead it is emitted after 2. Like this, Doom's iloader would elapse
one idle timer directly into another, ad infinitum, until Emacs was
forcibly killed.
By switching to run-at-time and employing my own rudimentary idle timer,
I avoid this issue. Also, the iloader no longer needs to be considerate
of native-comp, because the latter does its own rate-limiting controlled
by native-comp-async-jobs-number.
Amend: b7f84bdd0105
2022-09-10 01:01:28 +02:00
|
|
|
|
2020-12-01 19:33:55 -05:00
|
|
|
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
;;
|
|
|
|
|
;;; `doom-context'
|
|
|
|
|
|
|
|
|
|
(defvar doom-context '(t)
|
|
|
|
|
"A list of symbols identifying all active Doom execution contexts.
|
|
|
|
|
|
|
|
|
|
This should never be directly changed, only let-bound, and should never be
|
|
|
|
|
empty. Each context describes what phase Doom is in, and may respond to.
|
|
|
|
|
|
|
|
|
|
All valid contexts:
|
|
|
|
|
cli -- while executing a Doom CLI
|
2024-08-15 23:24:56 -04:00
|
|
|
compile -- while byte-compiling packages
|
|
|
|
|
eval -- during interactive evaluation of elisp
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
init -- while doom is formally starting up for the first time, after its
|
2024-08-15 23:24:56 -04:00
|
|
|
core libraries are loaded, but before $DOOMDIR is
|
|
|
|
|
modules -- while loading modules configuration files (but not packages)
|
|
|
|
|
sandbox -- This session was launched from Doom's sandbox
|
|
|
|
|
packages -- while a module's packages.el's file is being evaluated
|
|
|
|
|
reload -- while reloading doom with `doom/reload'")
|
2023-02-23 01:16:38 -05:00
|
|
|
(put 'doom-context 'valid-values '(cli compile eval init modules packages reload doctor sandbox))
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(put 'doom-context 'risky-local-variable t)
|
|
|
|
|
|
2023-12-05 17:39:33 -05:00
|
|
|
(defun doom-context--assert (context)
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(let ((valid (get 'doom-context 'valid-values)))
|
|
|
|
|
(unless (memq context valid)
|
|
|
|
|
(signal 'doom-context-error
|
|
|
|
|
(list context "Unrecognized context" valid)))))
|
|
|
|
|
|
|
|
|
|
(defun doom-context-p (context)
|
2024-08-15 23:24:56 -04:00
|
|
|
"Return t if CONTEXT is active, nil otherwise.
|
|
|
|
|
|
|
|
|
|
See `doom-context' for possible values for CONTEXT."
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(if (memq context doom-context) t))
|
|
|
|
|
|
|
|
|
|
(defun doom-context-push (context)
|
|
|
|
|
"Add CONTEXT to `doom-context', if it isn't already.
|
|
|
|
|
|
|
|
|
|
Return non-nil if successful. Throws an error if CONTEXT is invalid."
|
|
|
|
|
(unless (memq context doom-context)
|
2023-12-05 17:39:33 -05:00
|
|
|
(doom-context--assert context)
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(doom-log ":context: +%s %s" context doom-context)
|
|
|
|
|
(push context doom-context)))
|
|
|
|
|
|
|
|
|
|
(defun doom-context-pop (context &optional strict?)
|
|
|
|
|
"Remove CONTEXT from `doom-context'.
|
|
|
|
|
|
|
|
|
|
Return non-nil if successful. If STRICT? is non-nil, throw an error if CONTEXT
|
|
|
|
|
wasn't active when this was called."
|
|
|
|
|
(if (not (doom-context-p context))
|
|
|
|
|
(when strict?
|
|
|
|
|
(signal 'doom-context-error
|
|
|
|
|
(list doom-context "Attempt to pop missing context" context)))
|
|
|
|
|
(doom-log ":context: -%s %s" context doom-context)
|
|
|
|
|
(setq doom-context (delq context doom-context))))
|
|
|
|
|
|
|
|
|
|
(defmacro doom-context-with (contexts &rest body)
|
2023-12-05 17:09:36 -05:00
|
|
|
"Evaluate BODY with CONTEXTS added to `doom-context'."
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(declare (indent 1))
|
|
|
|
|
`(let ((doom-context doom-context))
|
|
|
|
|
(dolist (context (ensure-list ,contexts))
|
|
|
|
|
(doom-context-push context))
|
|
|
|
|
,@body))
|
|
|
|
|
|
2020-12-01 19:33:55 -05:00
|
|
|
|
2020-12-01 13:43:51 -05:00
|
|
|
;;
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Reasonable, global defaults
|
2020-12-01 13:43:51 -05:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Don't litter `doom-emacs-dir'/$HOME
|
2022-09-12 18:05:14 +02:00
|
|
|
;; HACK: I change `user-emacs-directory' because many packages (even built-in
|
|
|
|
|
;; ones) abuse it to build paths for storage/cache files (instead of correctly
|
|
|
|
|
;; using `locate-user-emacs-file'). This change ensures that said data files
|
|
|
|
|
;; are never saved to the root of your emacs directory *and* saves us the
|
2022-09-13 18:19:56 +02:00
|
|
|
;; trouble of setting a million directory/file variables. But it may throw off
|
|
|
|
|
;; anyone (or any package) that uses it to search for your Emacs initfiles.
|
2022-09-17 20:12:06 +02:00
|
|
|
(setq user-emacs-directory doom-profile-cache-dir)
|
2022-06-18 00:37:46 +02:00
|
|
|
|
|
|
|
|
;; ...However, this may surprise packages (and users) that read
|
|
|
|
|
;; `user-emacs-directory' expecting to find the location of your Emacs config,
|
|
|
|
|
;; such as server.el!
|
2022-09-13 14:06:56 +02:00
|
|
|
(setq server-auth-dir (file-name-concat doom-emacs-dir "server/"))
|
2022-06-18 00:37:46 +02:00
|
|
|
|
|
|
|
|
;; Packages with file/dir settings that don't use `user-emacs-directory' or
|
|
|
|
|
;; `locate-user-emacs-file' to initialize will need to set explicitly, to stop
|
|
|
|
|
;; them from littering in ~/.emacs.d/.
|
2022-09-17 20:12:06 +02:00
|
|
|
(setq desktop-dirname (file-name-concat doom-profile-state-dir "desktop")
|
|
|
|
|
pcache-directory (file-name-concat doom-profile-cache-dir "pcache/"))
|
2022-06-18 00:37:46 +02:00
|
|
|
|
|
|
|
|
;; Allow the user to store custom.el-saved settings and themes in their Doom
|
|
|
|
|
;; config (e.g. ~/.doom.d/).
|
2022-09-13 14:06:56 +02:00
|
|
|
(setq custom-file (file-name-concat doom-user-dir "custom.el"))
|
2022-06-18 00:37:46 +02:00
|
|
|
|
2022-07-29 12:22:33 +02:00
|
|
|
;; By default, Emacs stores `authinfo' in $HOME and in plain-text. Let's not do
|
|
|
|
|
;; that, mkay? This file stores usernames, passwords, and other treasures for
|
|
|
|
|
;; the aspiring malicious third party. You'll need a GPG setup though.
|
2022-09-17 20:12:06 +02:00
|
|
|
(setq auth-sources (list (file-name-concat doom-profile-state-dir "authinfo.gpg")
|
2022-07-29 12:22:33 +02:00
|
|
|
"~/.authinfo.gpg"))
|
|
|
|
|
|
2022-06-18 00:37:46 +02:00
|
|
|
(define-advice en/disable-command (:around (fn &rest args) write-to-data-dir)
|
2022-09-12 18:05:14 +02:00
|
|
|
"Save safe-local-variables to `custom-file' instead of `user-init-file'.
|
2022-06-18 00:37:46 +02:00
|
|
|
|
|
|
|
|
Otherwise, `en/disable-command' (in novice.el.gz) is hardcoded to write them to
|
|
|
|
|
`user-init-file')."
|
|
|
|
|
(let ((user-init-file custom-file))
|
2021-08-04 01:18:06 -04:00
|
|
|
(apply fn args)))
|
2020-06-13 16:09:26 -04:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;;; Native compilation support (see http://akrl.sdf.org/gccemacs.html)
|
|
|
|
|
(when (boundp 'native-comp-eln-load-path)
|
|
|
|
|
;; Don't store eln files in ~/.emacs.d/eln-cache (where they can easily be
|
|
|
|
|
;; deleted by 'doom upgrade').
|
|
|
|
|
;; REVIEW Use `startup-redirect-eln-cache' when 28 support is dropped
|
2022-09-17 20:12:06 +02:00
|
|
|
(add-to-list 'native-comp-eln-load-path (expand-file-name "eln/" doom-profile-cache-dir))
|
2020-08-17 21:46:54 -04:00
|
|
|
|
2022-09-14 17:57:03 +02:00
|
|
|
;; UX: Suppress compiler warnings and don't inundate users with their popups.
|
|
|
|
|
;; They are rarely more than warnings, so are safe to ignore.
|
|
|
|
|
(setq native-comp-async-report-warnings-errors init-file-debug
|
2022-09-16 19:06:15 +02:00
|
|
|
native-comp-warning-on-missing-source init-file-debug)
|
|
|
|
|
|
2023-02-20 17:52:56 -05:00
|
|
|
;; HACK: native-comp-deferred-compilation-deny-list is replaced in later
|
|
|
|
|
;; versions of Emacs 29, and with no deprecation warning. I alias them to
|
|
|
|
|
;; ensure backwards compatibility for packages downstream that may have not
|
|
|
|
|
;; caught up yet. I avoid marking it obsolete because obsolete warnings are
|
|
|
|
|
;; unimportant to end-users. It's the package devs that should be informed.
|
|
|
|
|
(unless (boundp 'native-comp-deferred-compilation-deny-list)
|
|
|
|
|
(defvaralias 'native-comp-deferred-compilation-deny-list 'native-comp-jit-compilation-deny-list))
|
|
|
|
|
|
2022-09-16 19:06:15 +02:00
|
|
|
;; UX: By default, native-comp uses 100% of half your cores. If you're
|
|
|
|
|
;; expecting this this should be no issue, but the sudden (and silent) spike
|
|
|
|
|
;; of CPU and memory utilization can alarm folks, overheat laptops, or
|
|
|
|
|
;; overwhelm less performant systems.
|
|
|
|
|
(define-advice comp-effective-async-max-jobs (:before (&rest _) set-default-cpus)
|
|
|
|
|
"Default to 1/4 of cores in interactive sessions and all of them otherwise."
|
|
|
|
|
(and (null comp-num-cpus)
|
|
|
|
|
(zerop native-comp-async-jobs-number)
|
|
|
|
|
(setq comp-num-cpus
|
2023-09-11 23:34:41 +02:00
|
|
|
(max 1 (/ (num-processors) (if noninteractive 1 4))))))
|
|
|
|
|
|
|
|
|
|
(define-advice comp-run-async-workers (:around (fn &rest args) dont-litter-tmpdir)
|
|
|
|
|
"Normally, native-comp writes a ton to /tmp. This advice forces it to write
|
|
|
|
|
to `doom-cache-dir'/comp/ instead, so that Doom can safely clean it up as part
|
|
|
|
|
of 'doom sync' or 'doom gc'."
|
|
|
|
|
(let ((temporary-file-directory (expand-file-name "comp/" doom-profile-cache-dir)))
|
|
|
|
|
(make-directory temporary-file-directory t)
|
|
|
|
|
(apply fn args))))
|
2022-09-14 17:57:03 +02:00
|
|
|
|
|
|
|
|
;;; Suppress package.el
|
|
|
|
|
;; Since Emacs 27, package initialization occurs before `user-init-file' is
|
|
|
|
|
;; loaded, but after `early-init-file'. Doom handles package initialization, so
|
|
|
|
|
;; we must prevent Emacs from doing it again.
|
|
|
|
|
(setq package-enable-at-startup nil)
|
2022-06-18 15:04:12 +02:00
|
|
|
|
2022-09-13 18:19:56 +02:00
|
|
|
;;; Reduce unnecessary/unactionable warnings/logs
|
2022-06-18 15:04:12 +02:00
|
|
|
;; Disable warnings from the legacy advice API. They aren't actionable or
|
|
|
|
|
;; useful, and often come from third party packages.
|
2021-10-09 19:31:21 +02:00
|
|
|
(setq ad-redefinition-action 'accept)
|
2018-06-15 14:58:31 +02:00
|
|
|
|
2022-08-08 17:51:29 +02:00
|
|
|
;; Ignore warnings about "existing variables being aliased". Otherwise the user
|
|
|
|
|
;; gets very intrusive popup warnings about our (intentional) uses of
|
2022-09-12 00:42:15 +02:00
|
|
|
;; defvaralias, which are done because ensuring aliases are created before
|
|
|
|
|
;; packages are loaded is an unneeded and unhelpful maintenance burden. Emacs
|
|
|
|
|
;; still aliases them fine regardless.
|
2024-05-05 00:05:23 -04:00
|
|
|
(setq warning-suppress-types '((defvaralias) (lexical-binding)))
|
2022-08-08 17:51:29 +02:00
|
|
|
|
2022-06-18 15:04:12 +02:00
|
|
|
;; Reduce debug output unless we've asked for it.
|
2021-10-09 19:31:21 +02:00
|
|
|
(setq debug-on-error init-file-debug
|
|
|
|
|
jka-compr-verbose init-file-debug)
|
2020-08-02 16:28:56 -04:00
|
|
|
|
2022-09-13 18:19:56 +02:00
|
|
|
;;; Stricter security defaults
|
2022-06-18 15:04:12 +02:00
|
|
|
;; Emacs is essentially one huge security vulnerability, what with all the
|
|
|
|
|
;; dependencies it pulls in from all corners of the globe. Let's try to be a
|
|
|
|
|
;; *little* more discerning.
|
|
|
|
|
(setq gnutls-verify-error noninteractive
|
|
|
|
|
gnutls-algorithm-priority
|
|
|
|
|
(when (boundp 'libgnutls-version)
|
|
|
|
|
(concat "SECURE128:+SECURE192:-VERS-ALL"
|
2023-12-05 17:05:13 -05:00
|
|
|
(if (and (not doom--system-windows-p)
|
2022-06-18 15:04:12 +02:00
|
|
|
(>= libgnutls-version 30605))
|
|
|
|
|
":+VERS-TLS1.3")
|
|
|
|
|
":+VERS-TLS1.2"))
|
|
|
|
|
;; `gnutls-min-prime-bits' is set based on recommendations from
|
|
|
|
|
;; https://www.keylength.com/en/4/
|
|
|
|
|
gnutls-min-prime-bits 3072
|
|
|
|
|
tls-checktrust gnutls-verify-error
|
|
|
|
|
;; Emacs is built with gnutls.el by default, so `tls-program' won't
|
|
|
|
|
;; typically be used, but in the odd case that it does, we ensure a more
|
|
|
|
|
;; secure default for it (falling back to `openssl' if absolutely
|
|
|
|
|
;; necessary). See https://redd.it/8sykl1 for details.
|
|
|
|
|
tls-program '("openssl s_client -connect %h:%p -CAfile %t -nbio -no_ssl3 -no_tls1 -no_tls1_1 -ign_eof"
|
|
|
|
|
"gnutls-cli -p %p --dh-bits=3072 --ocsp --x509cafile=%t \
|
|
|
|
|
--strict-tofu --priority='SECURE192:+SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3' %h"
|
|
|
|
|
;; compatibility fallbacks
|
|
|
|
|
"gnutls-cli -p %p %h"))
|
2017-06-08 11:47:56 +02:00
|
|
|
|
2022-09-14 19:01:57 +02:00
|
|
|
|
|
|
|
|
;;
|
|
|
|
|
;;; Custom hooks
|
|
|
|
|
|
|
|
|
|
(defcustom doom-before-init-hook ()
|
2022-09-23 22:12:25 +02:00
|
|
|
"A hook run after Doom's core has initialized; before user configuration.
|
2022-09-14 19:01:57 +02:00
|
|
|
|
2022-09-23 22:12:25 +02:00
|
|
|
This is triggered right before $DOOMDIR/init.el is loaded, in the context of
|
|
|
|
|
early-init.el. Use this for configuration at the latest opportunity before the
|
|
|
|
|
session becomes unpredictably complicated by user config, packages, etc. This
|
|
|
|
|
runs in both interactive and non-interactive contexts, so guard hooks
|
|
|
|
|
appropriately against `noninteractive' or the `cli' context (see
|
|
|
|
|
`doom-context').
|
2022-09-14 19:01:57 +02:00
|
|
|
|
|
|
|
|
In contrast, `before-init-hook' is run just after $DOOMDIR/init.el is loaded,
|
2022-09-23 22:12:25 +02:00
|
|
|
but long before your modules and $DOOMDIR/config.el are loaded."
|
2022-09-14 19:01:57 +02:00
|
|
|
:group 'doom
|
|
|
|
|
:type 'hook)
|
|
|
|
|
|
|
|
|
|
(defcustom doom-after-init-hook ()
|
2022-09-23 22:12:25 +02:00
|
|
|
"A hook run once Doom's core and modules, and the user's config are loaded.
|
2022-09-14 19:01:57 +02:00
|
|
|
|
2023-07-22 18:12:19 +02:00
|
|
|
This triggers at the absolute latest point in the eager startup process, and
|
2022-09-23 22:12:25 +02:00
|
|
|
runs in both interactive and non-interactive sessions, so guard hooks
|
|
|
|
|
appropriately against `noninteractive' or the `cli' context."
|
2022-09-14 19:01:57 +02:00
|
|
|
:group 'doom
|
|
|
|
|
:type 'hook)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
;;
|
|
|
|
|
;;; Last minute initialization
|
|
|
|
|
|
2023-12-02 11:23:54 -05:00
|
|
|
(when (daemonp)
|
|
|
|
|
(message "Starting Doom Emacs in daemon mode!")
|
|
|
|
|
(unless doom-inhibit-log
|
|
|
|
|
(add-hook! 'doom-after-init-hook :depth 106
|
|
|
|
|
(unless doom-inhibit-log
|
|
|
|
|
(setq doom-inhibit-log (not (or noninteractive init-file-debug))))
|
|
|
|
|
(message "Disabling verbose mode. Have fun!"))
|
|
|
|
|
(add-hook! 'kill-emacs-hook :depth 110
|
|
|
|
|
(message "Killing Emacs. Sayonara!"))))
|
|
|
|
|
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(add-hook! 'doom-before-init-hook :depth -105
|
|
|
|
|
(defun doom--begin-init-h ()
|
|
|
|
|
"Begin the startup process."
|
2024-05-05 00:05:23 -04:00
|
|
|
;; HACK: Later versions of Emacs 30 emit warnings about missing
|
|
|
|
|
;; lexical-bindings directives at the top of loaded files. This is a good
|
|
|
|
|
;; thing, but it inundates users with unactionable warnings (from old
|
|
|
|
|
;; packages or internal subdirs.el files), which aren't useful.
|
|
|
|
|
(setq-default delayed-warnings-list
|
|
|
|
|
(assq-delete-all 'lexical-binding delayed-warnings-list))
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(when (doom-context-push 'init)
|
2023-12-05 17:05:13 -05:00
|
|
|
;; HACK: Ensure OS checks are as fast as possible (given their ubiquity).
|
|
|
|
|
(setq features (cons :system (delq :system features)))
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
;; Remember these variables' initial values, so we can safely reset them at
|
|
|
|
|
;; a later time, or consult them without fear of contamination.
|
|
|
|
|
(dolist (var '(exec-path load-path process-environment))
|
|
|
|
|
(put var 'initial-value (default-toplevel-value var))))))
|
2022-09-14 19:01:57 +02:00
|
|
|
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(add-hook! 'doom-after-init-hook :depth 105
|
2022-09-23 22:03:38 +02:00
|
|
|
(defun doom--end-init-h ()
|
|
|
|
|
"Set `doom-init-time'."
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(when (doom-context-pop 'init)
|
|
|
|
|
(setq doom-init-time (float-time (time-subtract (current-time) before-init-time))))))
|
2022-09-23 22:03:38 +02:00
|
|
|
|
refactor: introduce doom-context
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
2022-09-24 12:38:25 +02:00
|
|
|
(unless noninteractive
|
|
|
|
|
;; This is the absolute latest a hook can run in Emacs' startup process.
|
|
|
|
|
(define-advice command-line-1 (:after (&rest _) run-after-init-hook)
|
|
|
|
|
(doom-run-hooks 'doom-after-init-hook)))
|
2022-09-14 19:01:57 +02:00
|
|
|
|
2022-07-30 21:49:00 +02:00
|
|
|
(provide 'doom)
|
|
|
|
|
;;; doom.el ends here
|