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
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 "^".
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`.
Auto-generates price files are a common feature among beancount users;
scanning them is a lot of unnecessary work when just reading commodity
directives (and operating_currency options) should be more than enough.
Amend: 5df769e994
Was supposed to be part of d3e8ca8. Now completes commodities/currencies
from declared commidities, operating_currency options, or price
directives. Currently only works in postings, but can be later extended
to complete in price directives and operating_currency options.
Amend: d3e8ca8d9d
- `+beancount/clone-transaction` now completes for all transactions
across this and any included files (depending on the value of
`+beancount-files`).
- Handles an edge case where `+beancount/clone-this-transaction` would
try and fail to clone a transaction at point where there wasn't any.
Enhances completion for beancount-mode in the following ways:
1. Adds completion for:
- Event directives and values,
- The payee field in transactions,
- Currencies and commodities,
2. Fixes completion for #tag and ^links not working at the end of a
transaction's heading.
3. Completion now scans not only the current file, but any included
files (recursively) for candidates if `+beancount-files' is set to
`auto`. It can otherwise be set to a list of static files or set to
`nil` (reverts to only scanning the current buffer). This applies not
only to completion-at-point functions, but also interactive commands
like `beancount-insert-account'.
This is all very rudimentary and needs polish!
Adds support for meta lines that only the flymake linter will see.
These are lines prefixed by any number of semicolons followed by a hash
then space. E.g.
;# include "../config.beancount"
;# 2025-01-01 pad Assets:Bank Equity:Opening-Balances
This is useful for silencing the linter in multi-file beancount projects
rather than suffer the usual deluge of multiple-include errors and
redundancies.
Beancount tools and Fava recognize relative paths in include and
document directives, and documents options. However, flymake-bean pipes
the buffer's contents to bean-check via /dev/stdin, so paths are
resolved relative to /dev instead of the location of the containing
beancount file, resulting in file errors. This commit expands those
relatives paths before sending the buffer's contents to bean-check to
resolve these false positives.
I'm only trying to override the RET key that evil-org binds, but also
binding these to [return] interferes with "RET" keybinds in various
places, like transient bindings on RET (e.g. gptel).
There is no beancount integration for flycheck (which will be
implemented later), so activate flymake in beancount so users of either
checker can enjoy bean-check linting.
Note: `add-hook!` will, in the future, deprecate implicit hooks, e.g.
(add-hook! some-mode #'function)
(add-hook! (some-mode another-mode) #'function)
This commit also removes the single-item lists passed to
`add-hook!` (which was unnecessary).
Doom treats the use of package.el and its API as user error unless
they've called `package-initialize' themselves (in which case, it is
assumed you know what you're doing and truly want to use package.el).
Adapted from Janfel's snippet in Wilfred/helpful#250.
And bound to C-{o,i} and {<,>} for evil users, and C-c C-{b,f} and {l,r}
for vanilla users (mirroring the back/forward keybinds for help.el).
Ref: Wilfred/helpful#250
