- Fixes Doom's former inability to (trivially) juggle multiple profiles
based on the same EMACSDIR (see #6593).
- Adds '--profile NAME' switch to bin/doom (also recognized
$DOOMPROFILE).
- Adds new doom-profile* variables. These will eventually replace
doom-{local,etc,cache}-dir and doom-{autoloads,env}-file.
This is intentionally messy to ensure backwards compatibility for a
little while longer. This will be fixed over the next couple weeks.
Ref: #6593
doom-debug-p and doom-interactive-p have always been intentionally
redundant, because changing the variables they replaced had other
side-effects, which made writing tests for them difficult. Since our
new (yet unpublished) tests lean heavily toward integration testing more
than unit testing, this becomes an implementation detail.
And doom-init-p's only use was refactor out at some point in the past,
so it's no longer used.
Also done to reduce Doom's footprint, in general.
Restructures Doom's primary core files and entry points to prepare for
backports (from the new CLI) coming soon.
- Removes $EMACSDIR/init.el.
- Doom configures Emacs to ignore ~/.emacs and ~/_emacs files.
- Doom's bootstrapper for interactive sessions was moved out of core.el
and doom-initialize into doom-start.el. This change is preparation for
Doom's new profile system (coming soon™️), where this bootstrapper
will be dynamically generated.
- core.el and early-init.el have been reorganized, comment headers moved
around, and comments updated to reflect these changes.
I change `user-emacs-directory' because most (if not all) packages --
even built-in ones -- abuse it exclusively to build paths for
storage/cache files (instead of correctly using
`locate-user-emacs-file'). This ensures your $EMACSDIR isn't littered
with data files *and* saves us the trouble of setting every
directory/file variable under the sun.
Granted, this introduces an edge case for any legitimate uses of the
variable (e.g. where the caller seeks to locate the user's initfiles),
but I've found no such uses in any of the packages I've audited for Doom
or elsewhere.
NSM has better UX when an invalid/expired certificate is encountered: it
prompts the user to decide what to do with it. If gnutls-verify-error is
non-nil, gnutls either kills or hangs the connection. This is (mostly)
acceptable in noninteractive sessions, where I can more tightly control
outgoing connections, but not in interactive sessions where I stand a
higher chance of stepping on the user's toes instead.
Ref: emacs-circe/circe#405
Eventually, our modules will move to their own repos (doomemacs/modules
and doomemacs/contrib-modules). Once done, it will formally adopt the
CalVer versioning scheme (Doom's core will stick to SemVer -- these
decisions will be better explained later). These mini-releases won't
mean much until this happens, hence the -dev suffix.
These two variables have been the wrong way around for a while. In
preparation for splitting Doom into separate repos (its core and module
libraries), I've corrected them. doom-modules-version is a placeholder
and will be removed later.
I've also settled on -dev suffix for inter-release versions of Doom,
rather than alpha.
Reduce cases where native-comp procedures were executed in
non-native-comp contexts (somehow).
Also:
- Adds a NATIVECOMP constant for statically detecting the feature.
- Remove native-comp-* -> comp-* aliases (Emacs HEAD has long since
moved on from these).
- Add 'no-native-compile: t' to autoloads file.
68d8364ae added a deprecation notice to any use of a
MODE-local-vars-hook, instructing users to use after-MODE-hook instead,
however this hasn't been decided yet and shouldn't have made it into
68d8364ae.
Ref 68d8364aeaFix#5612
Emacs 27 introduced a bunch of `window-*-change-functions` hooks,
including `window-selection-change-functions` and
`window-buffer-change-functions`, which handles 98% of the use case for
Doom's `doom-switch-{buffer,window,frame}-hook` hooks, so I've rewritten
them to use them under the hood, which amounts to simpler code and fewer
hacks.
The delay will not be adjusted on a per-GC basis, depending on its last
run-time. This should average to around 2-3s, which should be a good
compromise between GCing too often and too infrequently.
Thise should reduce the artificial latency added to window manager
operations (like calls to some of Emacs' frame API, e.g.
make-frame-invisible) on the PGTK build of Emacs. This should mitigate
latency issues with childframes in general and packages that use them,
e.g. lsp-ui and company-box.
There's also a small chance 0.001 is much too low, and may cause
artefacting on especially slow hardware. More testing is needed.
- Remove remaining `EMACS27+` checks, since the whole codebase is
assumed to run at version 27 or above now
- Remove `EMACS27+` definition since it's no longer needed
Emacs 27.x has been the stable version of Emacs for nearly a year, and
introduces a litany of bugfixes, performance, and quality-of-life
improvements that significantly reduce Doom's maintenance burden (like
XDG support, early-init.el, image manipulation without imagemagick, a
native JSON library, harfbuzz support, pdumper, and others).
With so many big changes on Doom's horizon, I like having one less (big)
thing to worry about.
Also reverts bb677cf7a (#5232) as it is no longer needed.
Reverts 86fd6c621 which increased gcmh-high-cons-threshold from Doom's
16mb default to its upstream default (of 1gb). This was an experiment.
In theory, the user should idle enough that it would GC enough to stave
off freezes/stuttering/paging, but in practice, either users did not
idle enough or the GC didn't clean up enough when given the opportunity.
The result: terrible stuttering and freezing after long periods of use.
Back to 16mb gang.
Its output is helpful. Let's not silence it.
But prevent output during incremental loading from hijacking the
minibuffer (likely the original reason org-roam-verbose was disabled).
We only need this magic in CLI sessions. It's better to only use half
the CPUs in interactive sessions (if the user has enabled
comp-deferred-compilation for some reason).
Fixes#5042
(defvaralias A B) throws an error if A is already defined. This breaks
Doom in the event that Doom's config is loaded late (e.g. with 'doom
run'), or these variables are set elsewhere (e.g. the sandbox). I didn't
want to have to do all these checks at startup, but it seems
unavoidable.
Since Doom will only support near-enough the latest commit of Emacs 28
HEAD, I will remove these fixes at the end of May, give or take a week.
After studying set-language-environment, it seems to embody all these
lines. And without without it, non-English glyph rendering is very
slow (see https://emacs-china.org/t/org-mode/16918).
This may have other implications, however, so further testing is needed.
Already set in early-init.el, and deferred compilation is auto-disabled
in noninteractive sessions, so only matters to clients that load
early-init.el.
