The auto-generated script has bom characters on my mac. if bin/doom
exits with code 254, it gives me the below error:
`.../doom.123.0.sh: line 1: #!/usr/bin/env: No such file or directory`
Although this is a refactor for normal users of Doom, it is a bugfix for
one (I assume) unsupported configuration: when Doom is not running from
a git checkout. In that case, `doom--help-package-configs` currently
returns Git's error messages. This breaks `doom/help-packages` because
it expects each returned line to contain at least one `:` character, so
it errors out with `Wrong number of arguments: (file line _match &rest),
2`.
Using ripgrep here should be equivalent for normal users as long as they
have not added untracked files not covered by Doom's .gitignore.
If the package is local, the local-repo has absolute local file path,
and straight-modified-dir will return as it is, which always exists.
Fix it by passing package only to straight-modified-dir.
Consult the doom-context to determine if a transient hook should fire,
rather than after-init-time (less reliable; there may be times we want
them to fire post-init).
Also ensures that they're chained to find-file hooks whether or not this
is a daemon session (since they could concievably be triggered before
the daemon finishes initializing, but after Doom initializes).
Before this, it was non-trivial to *truly* disable the menu-bar in GUI
frames on MacOS, unless you knew about the
doom-restore-menu-bar-in-gui-frames-h hook and removed it. With this
change, the hook will bow out if the user has tampered with/called
menu-bar-mode at all.
The face and theme-face manipulation only needs to happen once per
frame, and the `set-fontset-font` calls only need to happen once per
session (or whenever the user calls `M-x doom/reload-fonts`). This
change ensures this and saves Emacs some work when initializing new
frames, as well as resolves `set-fontset-font` related segfaults in some
edge cases (#7803).
Fix: #7803
After switching to the sudo-ed tramp buffer, this restores the point and
scroll position of the window to match the source buffer.
I exploit save-place here instead of simply saving/restoring (point)
and (window-start), because I believe it's better UX that save-place
treat the two buffers as effectively the same now and in the future, and
record the last cursor position equally between them, even if the
implementation is messier. This *could* be generalized into an advice
for save-place-find-file-hook and save-place-to-alist, but that's an
experiment for another day.
This is an experimental implementation and may change later.
Close: #7181
Co-authored-by: YourFin <YourFin@users.noreply.github.com>
auto-save can trigger processes that hang silently in the background,
making those buffers inoperable (hanging Emacs) for the rest of the
session, even if they are killed (tramp caches them), so I suppress them
solely for these temporary tramp buffers created by doom/sudo-find-file
and doom/sudo-this-file.
I backported `find-sibling-file` from Emacs 29+ in 198fe82, but it
passes a third argument (REGEXP) to `file-expand-wildcards` which wasn't
introduced until 29, so users on 28 or earlier would see a
wrong-number-of-arguments error (see #7795).
Rather than backport the entire `file-expand-wildcards`
function (risking other edge cases), I've advised its usage in
`find-sibling-file-search` to behave as it would in 29+ with a non-nil
REGEXP argument.
Amend: 198fe82b6dFix: #7795
I revisit all our startup optimizations to see how they fair in Emacs
29.x and 30.x. Most of them still hold up. I've revised and updated most
of the accompanying comments to better explain them, given what I know
now compared to when I first wrote them.
Doom makes multiple attempts to re-clone repos if they failed the first
time, however, if a user provides a :local-repo and that location isn't
a git repo, Doom assumes this it is the result of a failed clone, and so
deletes it to "try" again (which will fail). This can result in lost
work.
This prevents this from happening to packages/repos outside of
$DOOMLOCALDIR (all packages under $DOOMLOCALDIR must be git repos).
Fix: #7785
Amend: 3643c4dadd
Amend: 1fa8d3a4b9
If the buffer is an indirect clone, it may not have a buffer-file-name.
Also changes the command to throw an error if the current file has no
file path *and* is not a dired buffer.
directory-empty-p was introduced in 28.1, but Doom still supports 27.1,
so 27.x users would see this error when running any bin/doom command
that clones packages.
Fix: #7779
Amend: 1fa8d3a4b9
It seems the temporary branch that 'doom upgrade' creates is sometimes
left over after a 'doom upgrade', preventing the next 'git fetch' from
completing.
Ref: #7771
Caused by a regression originally introduced in b6b755d, but incorrectly
fixed in 89c56a3. Don't code while sleep deprived, kids.
Amend: 89c56a3393
Amend: b6b755dea4
12a765c introduced suppression of package-rebuilding prompts on 'doom
upgrade', but inadvertently reversed the check. This fixes that (and
refactors the if/or tree into a `cond`).
Amend: 12a765c509
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
'doom purge' is now deprecated.
Also changes 'doom sync's -p option to --gc. Since GCing causes the loss
of historical data, I'd rather it be a long option to make it a little
harder to do accidentally.
This changes 'doom sync' to be smarter about responding to changed
package recipes/pins, changes in Emacs version, or instances where the user
has copied a config to a new system.
In all these cases, the user would formerly have to know about a
specific combination of 'doom sync -u' and 'doom build' to ensure Doom
is in a good state. With this change, 'doom sync' handles all these
cases.
Also, 'doom build' is now deprecated (and 'doom sync' now has a
--rebuild option to mimic its old behavior).
Also also, sometimes, a package may silently fail when cloned (which
used to result in an empty repo). Now, if this is detected, cloning will
be re-attempted up to 3 times before aborting with much more visible
error.
Note: these are stopgap solutions, until v3 is finished.
Something often reported are file-missing errors when a package that
should be present isn't. This can easily happen if, say, during a 'doom
sync' or 'doom upgrade' a package fails to clone correctly and the user
misses the errors, then tries to carry on as normal. What's worse is
that Straight leaves behind an empty directory, which it treats as a
sign that the package has been cloned correctly, so it doesn't raise any
fuss over them.
With this change, 'doom sync' (and 'doom upgrade') will now try again,
if the clone process fails the first time (up to 3 times) before
aborting the whole process altogether, which should be loud enough for
users not to miss. Note that these failures at 99.99% because of
network (or upstream downtime) issues.
For now, this does leave Doom in an incomplete state (until you try
again when the connection issue is resolved), but a rollback step will
be added in v3 to prevent this, as well as better error messages (as
well as @doomelpa mirror for packages on less reliable hosts, like
codeberg, savannah, etc).
BREAKING CHANGE: This removes the 'doom compile' and 'doom clean'
commands, and offers no immediate replacement for them (and no plan to
include one). In the future, byte-compilation of Doom's internals will
be baked into 'doom sync', but until then, Doom is not optimized to take
advantage of byte-compilation, and forcing it provides no benefit.
Before this, startup optimizations were disabled in debug mode, but more
often than not, this just made it difficult to reproduce some errors at
startup.
