Commit graph

18 commits

Author SHA1 Message Date
Henrik Lissner
41051f4761
fix: disable UI elements earlier
Moves this from doom-ui to doom-start, since there is more savings to be
had if this is done early.

Also moves the menu-bar fix for macos out of the :os macos module into
doom-start, because it is a fix (and for a Doom optimization) and not a
feature, so it shouldn't be behind a module.
2022-09-16 01:14:23 +02:00
Henrik Lissner
b914830403
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-16 01:14:23 +02:00
Henrik Lissner
4a253757cb
refactor: how UI elements are disabled at startup
The default-frame-alist properties are only necessary for the scrollbar.
The variables are enough for the rest. Also, no need to set
x-gtk-use-symtem-tooltips if we're turning off tooltips anyway.

Also moves the UI config that snuck its way into doom-start back to
doom-ui.
2022-09-16 01:14:23 +02:00
Henrik Lissner
0d7c3eaf24
feat: add doom-{before,after}-init-hook
doom-before-init-hook runs before $DOOMDIR/init.el is loaded.

doom-after-init-hook runs at the *very* end of the Emacs startup
process (after window-setup-hook).
2022-09-16 01:14:23 +02:00
Henrik Lissner
57a91235bd
perf: add additional startup optimizations
Also switches `expand-file-name` calls with the much faster
`file-name-concat` where possible.
2022-09-16 01:14:22 +02:00
Henrik Lissner
42d88421ba
refactor: move startup optimizations to doom.el
I move our hackiest and least offensive startup optimizations to core,
so they're easy for me to keep track of (they'll likely change often,
between major Emacs releases), to keep them from affecting non-Doom
profiles, and make it easy for readers to use as a reference.
2022-09-16 01:14:22 +02:00
Henrik Lissner
6ddaed5cdd
nit: comment revision and formatting
For clarity, to enforce conventions, and explain the unexplained.
2022-09-16 01:14:22 +02:00
Henrik Lissner
07d22adb4a
nit: revise comments, reformat config sections 2022-09-16 01:14:21 +02:00
Henrik Lissner
6a83079d2e
refactor: move core optimizations to doom-start
These only benefit interactive sessions, and doom-start's responsibility
is to configure interactive sessions; it doesn't make sense to keep
these in core.
2022-09-16 01:14:20 +02:00
Henrik Lissner
6cac7b05b6
refactor(lib): tidy doom-log output
This commit reduces the debug log noise, makes it easier to
read/parse/search, and soft-introduces a convention for doom-log
messages, where they are prefixed with a unique identifier loosely named
after it's running context or calling function.

I haven't enforced it everywhere doom-log is used yet, but this is a
start.
2022-09-12 16:01:43 +02:00
Henrik Lissner
0c43c769ef
refactor!: replace doom-incremental-load-immediately var
BREAKING CHANGE: This removes the doom-incremental-load-immediately
variable. Instead, set doom-incremental-first-idle-timer to 0 to force
all iloaded packages be eagerly loaded at startup. This is already the
default behavior for daemon sessions.
2022-09-12 15:59:29 +02:00
Henrik Lissner
46e23f37ba
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@e13509468b)
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: b7f84bdd01
2022-09-10 01:38:58 +02:00
Henrik Lissner
7e65329289
refactor: move gcmh config to doom-start
Configuration for interactive sessions ought to live in doom-start.

Ref: 3ce4b38c3d92
2022-09-06 22:55:47 +02:00
Henrik Lissner
1a639b7341
feat: add auto-mode-alist entries for future doom dotfiles 2022-09-06 22:55:47 +02:00
Henrik Lissner
6cf0e04de0
refactor: move doom-first-*-hook to doom-start
doom-start is responsible for configuring an interactive session, so
variables associated with interactive sessions ought to live there.
2022-09-06 22:55:47 +02:00
Henrik Lissner
b7f84bdd01
perf: defer incremental loading for nativecomp users
It'd be detrimental to runtime performance to incrementally load more
packages as Emacs is natively compiling others, so hold off on it a bit
longer.
2022-09-06 22:55:47 +02:00
Henrik Lissner
9b8ed397e8
feat!(cli): load project .doomrc instead of ci.el
BREAKING CHANGE: Before, 'doom ci' would load
$GIT_WORKING_TREE/.github/ci.el, to give users/projects an opportunity
to provide project-local configuration for bin/doom (mainly for CI/CD).
Now, this ci.el file is no longer loaded and instead, *all* bin/doom
sessions will walk up the file tree and load the first .doomrc it finds.

This gives bin/doom users a more general place configure all of its
commands, and not just 'doom ci' commands.

Extras:
- Adds .doomrc to auto-mode-alist (so that it starts in
  emacs-lisp-mode).
2022-08-07 19:43:28 +02:00
Henrik Lissner
b9933e6637
refactor!: restructure Doom core
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.

  (after! core-cli-ci ...)

To fix it, simply s/core-/doom-/, i.e.

  (after! doom-cli-ci ...)

What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/

Ref: #4273
2022-07-30 22:41:13 +02:00
Renamed from core/core-start.el (Browse further)