- 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.
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.
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.
- 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.
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.
Makes `envrc-reload`, `envrc-reload-all`, `envrc-allow`, or `envrc-deny`
restart any running lsp/eglot clients within the current direnv, so that
they reflect the new environment.
There's little reason for users to use these macros in their private
configs over plain ol' `with-eval-after-load` and `use-package`, unless
they're writing their own modules.
It's my fault for signal boosting them in documentation and whenever I'm
asked for help, because beginners now believe they are somehow
required for Doom to work correctly (there are guides out there
telling beginners that migrating to Doom involves replacing all
instances of `with-eval-after-load` and `use-package` in their
pre-existing configs with `after!` and `use-package!` -- which was never
true).
What's more, I plan to replace `use-package`, internally, so the
`use-package!` macro won't exist for much longer.
Way back, I added these three pseudo-features:
(featurep 'dynamic-modules)
(featurep 'harfbuzz)
(featurep 'jansson)
Why? Because some build features have pseudo features (like
`tty-child-frames`, `pgtk`, and `threads`), but others don't, and I
wanted more consistency around build feature detection. Years later, I
realized it wasn't used much internally and only ended up confusing
readers who didn't realize these were Doom's additions and not built
into Emacs. Emacs' idiosyncrasies may not be nice or elegant, but
they're less surprising to elisp beginners and veterans alike.
Treat paths as paths, rather than strings. Removes the requirements that
doom-*-dir variables end in slash (though I'll continue doing so as a
convention). Also moves a lot of cache/data into the current profile's
cache/data directories. Shouldn't actually affect anything for folks not
using Doom's profile system (yet).
Fix: #8616
0d2f10d introduced a regression that broke the arity check in
`set-tree-sitter!` for pre-30 compatibility, because `func-arity`
returned the arity of the advice, not the advised function, so the
`commit` argument was always stored in `treesit-language-source-alist`,
even before it was supported, resulting in wrong-number-of-args errors
for users on Emacs <=29.
Amend: 0d2f10dcab