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
Use `ess-view-data` given the extensive support for multiple backends
like base, dplyr, DT, kable, etc. Also, it seems that `ess-R-data-view`
is in an unmaintained/stale state.
Fix: #6455
This way rebinding our keybinds for ess sub-packages will require a
simpler after! line. I.e.
(map! :after ess-help ...)
Instead of
(map! :after (ess ess-help) ...)
Ref: #6455
Yasnippet expanding snippets (on TAB) from another mode can cause
org-element warnings. Until this interop is resolved, best to not make
TAB too smart.
It still works in src blocks, however.
Fix: #8363
BREAKING CHANGE: This removes eclim.el and meghanada.el support from the
Java module. Both of these projects are unmaintained and recommend the
user switch to lsp-java, which is already offered by the module's +lsp
flag.
Fix: #8360
This changes what buffer `+emacs-lisp-eval` evaluates elisp in (useful
for the :tool eval module's commands, like `+eval/buffer` and
`+eval/region`, or the Evil operators on gr/gR).
Creates a scratch buffer/org src block alternative to ielm.
When invoking `+emacs-lisp/open-repl`, if no working buffer is set in
the resulting ielm buffer, it will default to the selected buffer prior
to opening the repl.
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.
