Restoring indirect buffers indiscriminately isn't so simple, and can
come with unserializable data that Emacs will throw errors on while
restoring a saved workspace.
Revert: 5f04be599fFix: #6043
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).
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).
This functionality falls under the umbrella of "better defaults" rather
than essential defaults, and so belongs in :config default.
Whats more, the naming convention (+emacs-...) was intentional, because
this function (and the :config default module) will be moved to :doom
emacs in the near future.
This also indirectly fixes#8373.
Fix: #8373
In case the mode is activated before gcmh is loaded (as is the case with
session persistance libraries like desktop.el or
persp{ective,-mode}.el).
Close: #8372
BREAKING CHANGE: Anyone used to realgud will find it missing as of this
commit. It's been replaced with Dape (see
https://github.com/svaante/dape).
This change was made because realgud's implementation was archaic and
over-complicated, dap-mode requires lsp-mode (and has a lot of moving
parts and points of failure), and dape is straight-forward by
comparison; to set up and use. Note that dap-mode and dap-ui is now
deprecated and will be removed in the future, but still remains behind
the +lsp flag for backwards compatibility, at least until v3.
This also adds a '<leader> d' prefix for debugger commands (except for
vanilla users, who already have dape's prefix on 'C-x C-a')
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
A regression introduced in bac90c0. The extra --eval isn't necessary in
bin/doomscript because it loads early-init.el (and thus, lisp/doom.el)
sooner than bin/doom does.
Fix: #8362
Amend: def4579a9f
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
As of recent commits of Emacs 31, elisp files missing a
"lexical-binding: t" cookie will emit this warning:
Warning (files): Missing ‘lexical-binding’ cookie in "path/to/elisp/file".
You can add one with ‘M-x elisp-enable-lexical-binding RET’.
See ‘(elisp)Selecting Lisp Dialect’ and ‘(elisp)Converting to Lexical Binding’
for more information.
You can look forward to many of these if you use any old and
unmaintained elisp packages, or if you have elisp shell scripts with
shebang lines (which make this warning unavoidable).
This commit silences these warnings because it's poorly implemented.
It's obnoxious to users and they aren't the ones that should be told
this. It ought to be emitted during byte-compilation or by linters (e.g.
`M-x checkdoc`) at the folks actually in a position to do something
about the warning (i.e. the developers).
Ref: https://lists.gnu.org/r/emacs-devel/2024-05/msg00283.html
