This was a tricky regression to track down. 9753bfb tries to fix an
issue where the `default` face's :foreground changes to `#000000` in any
new frames created after the initial one (by calling `make-frame`),
because those frames' `background-color` and `foreground-color`
parameters default to "#000000" (possibly a bug with `disable-theme` too
eagerly defaulting them to black).
240493a replaces that with new, seemingly cleaner approach: setting
`frame-inherited-parameters`, which instructs `make-frame` to copy those
parameters from the last open frame, however, those parameters in the
initial daemon frame will be set to "unspecified-bg" or
"unspecified-fg" (see the docstring for `face-{back,fore}ground`), which
are invalid color strings. `make-frame` crashes tries to create a frame
with those color values, causing #8059.
Fix: #8059
Amend: 240493ae92
Amend: 9753bfb775
Forgot that `ob-dot.el` exists in Org. I blindly expected the
`graphviz-dot-mode` package to provide babel support in f6b7e8a.
Also, `org-src-lang-modes` expects its CDRs to omit the -mode suffix,
which should fix syntax highlighting of graphviz/dot babel blocks.
Amend: f6b7e8ae48
Ref: #7546
In 9a6bcc3, the new default for `truncate-string-ellipsis` was long
enough that it could cause `truncate-string-to-width` to error out (see
exceeded `truncate-string-to-width`s END-COLUMN argument.
Amend: 9a6bcc31f9Fix: #8044
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.
