These groups' parents are their source (aka the module library they
belong to). They will be:
- doomemacs/core = doom
- doomemacs/modules = doom+
- doomemacs/modules-contrib = doom++
And this module belongs to doom+.
Rewrites link handlers and keybind to use the new org-link-preview
backend.
Fix: #8164Close: #8707
Co-authored-by: andrewpeck <andrewpeck@users.noreply.github.com>
- Renames `+emacs-lisp-eval-working-buffer` to
`+emacs-lisp-working-buffer`.
- `+emacs-lisp/change-working-buffer`: Expand to accept the prefix arg,
the ability to unset the current working buffer, and only set the
working buffer buffer-locally.
In recent versions of Emacs, `global-hl-line-mode` is separate from
`hl-line-mode`
(the global mode uses a different, more efficient mechanism for line
highlights), so it should bow out if `hl-line-mode` is enabled.
tree-sitter-verilog has unfortunately not been maintained for years.
Gonzalo maintains tree-sitter-systemverilog which boasts
- Full implementation of the latest SystemVerilog standard (IEEE 1800-2023)
- Robust and reliable: sv-tests results
- Actively maintained
- Implements node fields
- Supports parsing of code snippets (e.g., always block outside of a module)
- Basic preprocessing capabilities
- Thoroughly tested (~3000 tests) including:
verilog is strictly a subset of systemverilog so the systemverilog
grammar is backwards compatible with verilog features.
tree-sitter-verilog has significant issues and fails parsing many basic
verilog files.
I use tree-sitter-systemverilog daily and have had no issues since switching.
Now, +eval/send-region-to-repl or +eval:region/+eval:buffer will
communicate with the REPL via nodejs-repl's API, instead of feeding the
selection to the REPL line-by-line (the fallback method).
Inexplicably, the built-in git on MacOS is many orders of magnitude
faster than the external builds provided by Homebrew/Macports, so use
that there. Emacs on MacOS needs all the (performance) help it can get
and, fortunately, the bundled git is 2.23 or newer on (at least) MacOS
10.15 (Catalina) and newer, so this should be a relatively safe bet
without the need for version checks.
Prevent `get-register`s advice from affecting the `get-register` call in
`evil-get-register` in `+evil--use-evil-registers-a`.
Ref: #8698Fix: #8699
Amend: 88e2a0d5de
It's too easy for `package--initialized` to be set accidentally (if the
user loads straight or uses Doom's package API, which inevitably calls
doom-initialize-packages). Instead, package--activated is a better
heuristic because users who *want* package.el will call package-install
without suppressing activation.
Amend: eccde78741
This function should not be used as a substitute for
`package-initialize`, to activate packages installed via package.el,
this is solely for metadata for Doom's package manager.
- Resolves `magit-git-executable` ahead of time. We used to do this, but
back then, magit used `magit-git-executable` in TRAMP sessions too.
Now, magit has a separate `magit-remote-git-executable` variable.
- Only invalidate projectile cache if the magit status buffer's contents
has changed. This will prevent excessive (and potentially expensive)
`projectile-invalidate-cache` calls for trivial changes, l
- Avoid changing the active buffer when fetching a specific variable
from a buffer is enough (more cpu/mem efficient).
- Don't adjust the fringe if the fringes are already the requested size.
We were setting recentf-auto-cleanup to nil, which is not one of the
supported values in its defcustom type.
Set it to `'never` instead. This has exactly the same effect (recentf
only references `recentf-auto-cleanup` from a `cond` statement, which
does nothing for both values), but we might as well future-proof.
Clean up a duplicate assignment while I'm there.
Noticed because I had copied this into my personal config at some
point (to disable Doom's periodic save in daemon sessions) and recently
converted that config to use `setopt`, which complained.
Doom adds `recentf-cleanup` to `kill-emacs-hook`, but that function only
cleans up `recentf-list` without saving it to disk: saving is handled by
`recentf-save-list`. `recentf-mode` adds `recentf-save-list` to
`kill-emacs-hook` as well... but it only adds that hook when
`recentf-mode` is enabled, which means `recentf-save-list` ends up
before `recentf-cleanup` on `kill-emacs-hook`, rendering the cleanup
ineffective.
This is normally barely noticable, but with many paths on (slow) network
filesystems on `recentf-list` the cleanup can get slow enough to be
annoying.
Fix it by passing a priority to `add-hook`.
This leaves an ineffective cleanup call if we exit Emacs with
recentf-mode disabled, but that should normally only happen if we exit
Emacs without opening a file (`doom-first-file-hook` enables
recentf-mode). If that's an issue, we could add a function to
`recentf-mode-hook` which in turn adds to `emacs-term-hook`, but that
seems too complicated for little gain.
Some major modes may only have a flymake checker (like beancount-mode),
and since flymake is built into Emacs, it's possible the user may
encounter `flymake-mode` even when they haven't enabled +flymake for
this module, so at least load its flymake config.
- Makes {next,previous}-error search the current-buffer before looking
for others (#1908, #2497).
- Makes {next,previous}-error recognize flymake errors.
Fix: #2497Fix: #1908
Doom is configured to ignore :ensure in `use-package`, unless the user
has manually called `(package-initialize)` -- in which case, we assume
the user genuinely *wants* to use package.el, or some reason.
Emulating --init-directory has issues (e.g. isn't exposed to the *exact*
same $HOME environment), so if it's available (i.e. if Emacs 29+ is
being used or Doom lives in ~/.emacs.d or ~/.config/emacs), then use it.
This makes the 'doom emacs' command faster and more reliable as a launch
pad for Doom.
This is because Emacs can't differentiate between C-i and TAB. Doom
creates a special input event for <C-i> to distinguish them (which only
works in GUI Emacs), so I moved this keybind there.
Fix: doomemacs/community#79
- Simplifies development build check explanation.
- Removes the 27 check, because Doom core will continue to support 27+
for the foreseeable future, but Doom's modules will be dropping 27 and
28 support soon, but that check will be done elsewhere.
Some were outdated, some were incorrectly labeled, others were already
completed, some were missing... Gotta fix them all.
Also, in :ui hl-todo, there are comments that describe how Doom uses
each of these annotations; those have been updated.
