Doesn't change the default behavior of the command, but adds an optional
FRAMES argument (a list of frames or `t` for all open and future
frames). If passed the prefix arg, FRAMES default to `t`, which applies
the opacity change to all open and future frames.
Close: #8395
Co-authored-by: lattarov <lattarov@users.noreply.github.com>
There are two editorconfig libraries. One built into 30+ and one on
MELPA. Same name, different APIs. If the MELPA one is installed through,
say, your OS package manager, then the detection heuristic in
`doom/set-indent-width` could get confused which library is which.
Fix: #8423
- cmd.exe chokes on the space in "C:\Program Files\...", but more
importantly, doom.ps1 should be invoked with powershell, not cmd.exe.
- Windows has pwsh.exe and powershell.exe, which, while not identical,
are close enough for our purposes, but needed to be accounted for.
Fix: #8098
Allow doom-project-find-file to search file hierarchies from arbitrary
starting points (otherwise, project.el will resolve to the nearest
project root).
Used to be that a ;;;###COOKIE with no argument would return NULL-VALUE.
No more, it will now return `t`.
Also corrects the docstring to properly reflect what this does.
A version of describe-char that, when given a prefix arg, will prompt
the user to click where to execute the command (so you can read
text-properties/overlay information for otherwise unselectable text, in
the minibuffer or special UIs).
Now `doom-debug-mode` manipulates `doom-log-level` if you activate it
with a prefix arg, setting it to 1 by default, reducing its verbosity
and cutting down on noise in the logs.
In the interest of slimming down Doom's core (as we near v3), I've
deprecated these macros. They doesn't really need to exist. Sure, the
alternatives aren't as ergonomic or elegant, but they're good enough
that we don't need these trivial wrappers. Their local uses have been
refactored out as well.
Also ensures the envvar is removed if it's empty, and doesn't permeate
an empty DEBUG when executing doom/reload.
Amend: 8c7711920eClose: #8310
Co-authored-by: AjaiKN <AjaiKN@users.noreply.github.com>
Since 87a024e, the profile init files are no longer byte-compiled, so
this block of code -- responsible for deleting byte-compiled init files
-- is no longer needed.
Amend: 87a024ee90
Instead of advising load-theme, which was more opinionated, and broke in
instances where users (relying on `custom-enabled-themes`s setter) or
packages (like auto-dark) were enabling themes with `enable-theme`
instead of `load-theme`.
This also adds support for enabling multiple themes with `doom-theme`.
Fix: #8119
`letenv!` is a layover from the days before
`with-environment-variables` (introduced in 28.x), and it remained
afterwards because I preferred the shorter name. From v3 and onward,
Doom's core will be put on a diet which, among other things, will
include culling redundant or superfluous functions/macros like this one.
The performance benefit of doing so has always been questionable or, at
best, negligible, but has caused numerous issues over the years. The
latest one being #8162, where byte-compiling a profile init file with
too many package autoloads would consume more than 255 opcodes, causing
an overflow error.
For simplicity's sake, Doom will no longer byte-compile this file.
Fix: #8162
These commands were removed in an ongoing effort to slim down Doom and
its core. The `doom/goto-private-*-file` family of commands were
redundant with `doom/open-private-config` and
`doom/find-file-in-private-config`.
This is an old issue that's haunted Doom for a while. I had initially
planned to wait until the switch to Elpaca, but I decided to just sit
down and solve this.
This ensures package autoloads are always written in depth-first
dependency order to Doom's profile init file, preventing load-order
issues like the notorious void-function geiser-activate-implementation
error. `geiser` needs to be built before any `geiser-*` plugins, since
its plugins reference variables/functions in geiser's own autoloads, but
there's no way to enforce package order in `straight--build-cache`
currently, and subsequent package updates (or just deleting package
directories by hand) can change the order of straight's build-cache in
subtle ways.
Fix: #7693Fix: #7472
`doom-module-load-path` will be removed in the next big refactor commit,
so as a stop gap, I simply move it to doom.el to resolve the reference
error.
This also removes the obsolete alias `doom-modules-dirs`, since it's
been deprecated long enough (and `doom-module-load-path` itself won't be
around much longer anyway).
Ref: #8147
Amend: 8cafbe4408
