The -!/--force flags suppress straight's 'how to proceed' prompts, but
not the secondary ones like 'Really delete remote "origin"?'. This fixes
that.
Fix: #7906
To make these errors more consistent with similar commands/operations,
as well as rely less on cl-check-type (cl-lib's understanding of the
`font` type is a bit odd; they'd emit warnings/errors about this, but
still perform the checks -- I opted to check more explicitly instead).
BREAKING CHANGE: This removes git-gutter as an implementation for the
`:ui vc-gutter` module, leaving only the diff-hl implementation. There
are no longer any +git-gutter or +diff-hl flags for this module. Users
don't have to do anything to keep the vc gutter, unless they prefer
git-gutter for any reason (in which case they'll need to install and set
it up themselves).
This has been planned for some time, because of a roadmap goal for Doom
to lean into native/built-in functionality where it's equal or better
than the third party alternatives. diff-hl relies on the built-in vc.el
library instead of talking to git directly (thus expanding support to
whatever VCS's vc.el supports, and not git alone), which also means it
can take advantage of its caching and other user configuration for
vc.el. Overall, it is faster and lighter.
What I've also been waiting for was a stage-hunk command, similar to
git-gutter:stage-hunk, which arrived in dgutov/diff-hl@a0560551cd and
dgutov/diff-hl@133538973b, and have evolved since.
Ref: dgutov/diff-hl@a0560551cd
Ref: dgutov/diff-hl@133538973b
Ref: https://github.com/orgs/doomemacs/projects/5/views/1?pane=issue&itemId=58747789
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke
`file-truename` of file, keeping symbolic from being converted to a real
path.
* lisp/doom-modules.el(doom-module-from-path) Replace
`file-in-directory-p` with `string-match` to determine the module to
which the file belongs.
Fix: #7821
These checks and warnings were added on some recent commit of Emacs.
They're annoying to deal with and the end-user typically can't do much
about them (e.g. old packages), so I suppress them across the board.
That said, there are a few we cannot catch in non-interactive
sessions (where they aren't delayed), and those early warnings don't
respect delayed-warnings-list. This ought to be considered a bug
upstream.
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
