In 4989661, I reduced the init time for bin/doom by eliminating the
extra `emacs` call in its shebang. This does the same for
bin/doomscript.
Ref: 498966179f
The NOERROR argument on `load` no only suppress file-missing errors, but
file permission errors, so I avoided it. However, if any
`require` *inside* `doom.el` throws `file-missing`, this bootstrapper
will assume this means we're loading a non-Doom config.
Those `face-*` calls sometimes returned nil, causing new frames spawned
from emacsclient to quietly crash sometimes. By instead relying on
`frame-inherited-parameters` we achieve the same but more stable result.
Amend: 9753bfb775
`racket-mode` recently added `racket-hash-lang-mode` as an alternative
major mode.
Close: #7543
Co-authored-by: hlissner <hlissner@users.noreply.github.com>
Any buffers opened before company-mode was loaded would not have
`company-backends` initialized in them.
Fix: #6261Fix: #6180Fix: #5896Fix: #5672Fix: #2015
Even `emacs --batch -f kill-emacs` can take a non-trivial amount of time
to start up (0.661s on my system). This makes the two `emacs` calls in
bin/doom's shebang amount to >1s of startup time for Doom scripts (~1.5s
on my system). This change removes the second call (or at least defers
it until the after-script; at least, if $TMPDIR or $TEMP aren't set),
bringing down that time to a more bearable 0.9s.
This sacrifices the more descriptive "Can't find Emacs in your $PATH"
error message should the user set their own $EMACS, but the alternative
bash error is good enough:
$ EMACS=foo doom version
/home/$USER/.config/emacs/bin/doom: line 12: foo: command not found
I'm not doing more sophisticated checks on $EMACS, because it could be a
command (like `flatpak run org.gnu.emacs`), rather than an executable or
path, and the boilerplate to handle that, within what small space we get
in bin/doom's shebang, would be too much maintenance headache just for a
slightly better error message.
`git-commit` is no longer distributed with `magit` and no longer
declares its dependencies, causing "file missing: with-editor" and
similar errors for folks who don't have magit installed. Also, VC's
commit workflows don't utilize the mode, so there's no reason to keep it
in this module.
Ref: magit/magit@c170fcf399
Ref: #8003
Most of these lsp packages are already in `lsp-client-packages`, which
lsp-mode will eagerly load the first time `lsp-mode` is activated, so we
don't need to do it ourselves, except in cases where the package isn't
in `lsp-client-packages` (like lsp-julia).
