Because of the python dev's propensity to use env managers, setting the
pyright executable globally doesn't make much sense, and could in fact
end up intrusively overriding a user's local settings.
A better approach may be to introduce an envvar here that can be set
from external .envrc or venv config files, or making
`lsp-pyright-langserver-command` a safe file-local variable (so it can
be set from .dir-locals.el or in the file-local variables of a python
file), but if I decide to do one or the other, I'd like to be consistent
about it across all python executables/external dependencies (and
possibly even to all :lang modules that depend on env managers), so I'll
defer implementing that until I have the time to give it more thought
and plan it better.
Amend: 1fa1eba5ac
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
This avoids inserting braces when you type "a_", so you end up typing
"a_i" instead of "a_{i}".
The official LaTeX manual says that braces are correct, but it doesn't
matter for many cases, e.g., when the sub/superscript is just a single
token like "i". It's simply a matter of taste in these cases.
- Frank Mittelbach, a LaTeX maintainer, says that he types "a_i":
https://tex.stackexchange.com/questions/82329/how-bad-for-tex-is-omitting-braces-even-if-the-result-is-the-same#comment176261_82331
- David Carlisle, another LaTeX maintainer, says that a_i "arguably
improves the look of the source code":
https://tex.stackexchange.com/a/82337
- Joseph Wright, yet another LaTeX maintainer, says that he "would
always use braces here, so favour a_{i}":
https://tex.stackexchange.com/a/1929
And I think if it is a matter of taste, then the sane default is to
avoid any magic that gets in the way of users. Anyone who prefers braces
can still enable this argument, but people who do not like them won't
get upset every time they type "_" or "^".
In v3, 'doom run' will have a different purpose (for launching project
or CI/CD tasks), so it now emits a warning that it's moved to a new
'doom emacs' command.
I refrain from updating documentation because a rewrite of our docs will
be coming up soon.
We bind to basic-save-buffer in :config default (and save-buffer calls
it too), so we advise that instead. However, this is a temporary
solution because it casts way too wide a net. Probably better to add a
new save-without-formatting keybind instead.
Fix: #8420
- 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
Minimize the flycheck rules when using org-mode's edit functionality for
source code blocks (e.g. `#+begin_src emacs-lisp / #+end_src`) that pops
up a new buffer with the minor mode `'org-src-mode`.
Forge depends on ghub, and ghub requires 29.1+, so Forge has dropped
backwards compatibility (plus, code-review depends on Forge).
Also adds a doctor check for this constraint.
Fix: #8419
Ref: magit/forge@35224e5dd4
Allow doom-project-find-file to search file hierarchies from arbitrary
starting points (otherwise, project.el will resolve to the nearest
project root).
1. Add jump-to-heading functionality for EWW buffers
2. Bind within imenu (replaces +eww/jump-to-url-on-page; bound to
`:localleader l`)
The new functions are based on existing `eww--capture-url-on-page` and
`+eww/jump-to-url-on-page`. However, I took a different approach and
used alists to hide the position/coordinates from the `completing-read`.
Also, unlike `+eww/jump-to-url-on-page`, we don't give the user an
option of limiting the scope to a region or visible portion of the
buffer. `+eww/jump-to-heading-on-page` always prompts based on the
entire buffer.
Examples:
1. `<h1>H1</h1>`
- "H1"
2. `<h1>H1</h1><h2>H2</h2>`
- "H1"
- "H1/h2"
3. `<h1>H1</h1><h2>H2</h2><h3>H3</h3>`
- "H1"
- "H1/H2"
- "H1/H2/H3"
4. `<h1>H1-1</h1><h2>H2</h2><h1>H1-2</h1>`
- "H1-1"
- "H1-1/H2"
- "H1-2"
Gaps in the hierarchy (for example a `<h2>` followed by an `<h5>`) are not
represented in the labels presented to the user. Take the Wikipedia
entry for Emacs (above) as an example. The `<h2>` "Content" is the first
heading on the page, there's no preceeding `<h1>`, so it's shown to the
user as "Content" without any prefix. Examples:
1. `<h2>H2</h2>`
- "H2"
2. `<h2>H2</h2><h4>H4</h4>`
- "H2"
- "H2/H4"
3. `<h2>H2</h2><h4>H4</h4><h5>H5</h5>`
- "H2"
- "H2/H4"
- "H2/H4/H5"
4. `<h2>H2</h2><h1>H1</h1><h5>H5</h5>`
- "H2"
- "H1"
- "H1/H5"
- modules/emacs/eww/autoload.el
- (eww--capture-url-on-page): Rename to `eww--capture-urls-on-page`
- (eww--capture-headings-on-page): Add; based on existing `eww--capture-urls-on-page`
- (+eww/jump-to-heading-on-page): Add; based on existing `+eww/jump-to-url-on-page`
- modules/emacs/eww/config.el
- (keybind) Bind `+eww/jump-to-heading-on-page` to `<:localleader.>`;
based on existing org-mode jump-to-heading keybind (`consult-org-heading`)
Wherever an interactive motion command (that good-scroll has advised) is
used programmatically.
This should be addressed upstream. Either by adding
boundary/called-interactively guards to
`good-scroll--point-at-top-fix-a`, or by avoiding interactive motion
commands in ledger-mode.
Fix: #8376
Leave it to users to implement this, if they want this, but not only
might it cause confusion, but users may want a clean slate every time
they launch a new debugging session in the same project.
Fix: #8407
