Originally, this intended to *stop* diff-hl from too aggressively
deleting the diff overlays while editing. This is either no longer the
case or the old advice was mistaken; the intended behavior is achieved
without it.
If vterm-buffer-name-string is set to non-nil, then vterm will rename
the buffer after it is initialized. Since +vterm/toggle looks up buffers
by name, it will lose track of them, causing it to create a new one on
each invocation. With this, it will no longer lose track of them.
Fix: #6651
BREAKING CHANGE: users who are used to diff-hl displaying diffs in dired
will notice they have vanished. diff-hl's conig has been moved to :ui
vc-gutter +diff-hl (added in 27a448b). Enable it to get it back.
Ref: 27a448b04b
Unsetting file-name-handler-alist around a `load` call prevents any
change to this variable from surviving that file's evaluation (e.g. by
packages loaded therein). Since the user's config files are loaded with
this macro, this affects users' configs, which is unacceptable.
Since this optimization is already done in early-init.el, we can get
away with being more selective here.
See 6f1c0f7cc7 for part 1.
Turns out startup.elc likely exists on most Emacs installations (and,
since it's so integral to Emacs, it likely gets special treatment), so
it was a poor heuristic for this fix. Instead, a more variable target
would be calc-loaddefs.el.
On some systems, only calc-loaddefs.el.gz exists (in which case, we
should turn off the optimization). On others, calc-loaddefs.el
exists (so I'll assume it's safe to leave them on). I won't check for
calc-loaddefs.elc because it doesn't matter; calc.el explicitly
calls (load "calc-loaddefs.el") so it is never loaded.
Of course, you can sidestep the entire issue by building Emacs with
--without-compress-install, but it's not practical for users to
know/want to do that.
Amend: 6f1c0f7cc7
Some installs of Emacs do not come with byte-compiled versions of its
bundled elisp files, so when loading them, Emacs falls back to loading
its *.el.gz files. This would be fine if it were not for a startup
optimization Doom employs, where it sets file-name-handler-alist to
nil (and by doing so, robs Emacs of the ability to read compressed
elisp). This causes "symbol's value as variable is void: \213" errors at
startup.
With this commit, Doom now disables this optimization early if it
suspects this applies to your install. But time will tell if it's early
enough.
Ref: https://mail.gnu.org/archive/html/emacs-devel/2022-08/msg00234.html
Based on the new variable `+tree-sitter-hl-enabled-modes`
This allows for people to use tree sitters tools without having
to use it for highlighting.
Useful because some modes (such as web-mode and its derivatives) do a
better job than the tree sitter alternative in this respect.
If tangling failed, it would do so silently, continuing on with the
'doom sync'. This causes a visible error instead, aborting the 'doom
sync'. Unfortunately, org-babel-tangle doesn't appear to produce any
errors, so this our error message can't be improved at this stage.
Fix: #6642
This adds an alternative backend to the :ui vc-gutter module, enabled
with the +diff-hl flag. In the future, I intend for diff-hl to replace
git-gutter, as it is slightly faster and depends on more native
functionality (vc.el), but it's still a little buggy. It will remain
opt-in until those issues are sorted out.
BREAKING CHANGE: This changes moves its default configuration of the
fringe behind a +pretty flag. This won't cause breakage, but will cause
a (possibly unwanted) visual change: git-gutter will use its default
indicators (e.g. + and - symbols) instead of the continuous bars from
before.
To get back the old look, enable `+pretty` on the `:ui vc-gutter`
module.
This was done to make the defaults toggleable, to standardize +pretty,
to document issues with this customization that have been brought up by
members of the Emacs community, and to better document it in comments
for posterity.
Since fd 8.3.0 has low availability across distros (see repology link
below), I don't want to make it Doom's minimum supported version.
Instead, I do a quick version check and adjust accordingly. I'll think
up a more elegant solution after v3.
Ref: https://repology.org/project/fd-find/versionsFix: #6618Fix: #6600Close: #6597
- Rename doom-docs--display-header-h -> doom-docs--display-menu-h to
better represent what it does.
- Add comments to describe the purpose of lib/docs, and TODO annotations
to hint at its future and remind me later.
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).
- Adds -o/--file option,
- If -o/--file is passed a dash, print codeowners to stdout,
- Adds --dryrun option,
- Will accept literal string entries in doom-make-codeowners as
standalone lines (useful for comments).
Evaluating code (and :tools (eval +overlay) enabled) will do one of two
things with the return value:
If long, it will be displayed in a popup window on the bottom of the
frame. If short (<3-4 lines), it will be displayed in an overlay at the
end of the line.
If you happened to have scrolled horizontally (such that the BOL isn't
visible), the overlay would be displayed offscreen and unreadable. Any
attempt to scroll it into view will cause it to disappear (as per its
transient nature). This fix pads each newline in said overlay such that
the overlay is pushed into view.
CLIs can now use this for implicit validation for options that take a
file path or - to signal "print to stdout", like so:
(defcli! (doom command) ((outfile ("--out" (file stdout))))
(if (equal outfile "-")
(print! "output")
(with-temp-file outfile
(insert "output"))))
If OUTFILE is not an existing file path or a -, you'll see an this
helpful error:
Error: -o/--file received invalid value "FOO"
Validation errors:
- Must be a dash to signal stdout.
- File does not exist.
See 'doom h[elp] make codeowners' or 'doom make codeowners {-?,--help}' for documentation.
Now you can specify more than one allowed (implicit) for a CLI option:
(defcli! (doom somecommand) ((foo ("--foo" (file int)))))
This will test FOO to ensure it is either an existing file path or an
integer. If neither is true, you'll see this helpful error:
Error: -o/--file received invalid value "FOO"
Validation errors:
- Not an integer.
- Not a valid path to an existing file.
doom-enlist is now a deprecated alias for ensure-list, which is built
into Emacs 28.1+ and is its drop-in replacement. We've already
backported it for 27.x users in doom-lib (in 4bf4978).
Ref: 4bf49785fd
