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.
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.
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
In case doom-profile-data-dir doesn't end with a slash (which is a
stipulation I won't be enforcing for Doom's dir variables in v3 and
beyond).
Fix: #8511
ts-modes do this already in 30/31+ (`derived-mode-add-parents` was added
in 30), but is still needed for 29.x users and any ts-modes that haven't
adapted (many of them).
Fix: doomemacs/community#29
If the base major mode doesn't exist, let's assume we want no
fallthrough for this major mode (in the event the grammar isn't ready)
and simply push forward anyway, even if a missing grammar results in a
broken state.
This will particularly affect major modes like `typescript-mode` (which
simply won't be installed if +tree-sitter is enabled) and
`go-{mod,work}-ts-mode` (for which no base major modes exist).
The difference (generally) between most base and ts-modes is
performance, not features, so "gracefully failing back to the base mode"
makes sense UX-wise, but `typescript-mode` notably inferior to
`typescript-ts-mode` (particularly in its TSX support). Beginners may
misidentify its shortcomings as bugs, so it's better to simply error out
early so the user can be made aware of the problem sooner and less
ambiguously.
In Emacs <=30, top-level `treesit-ready-p` calls in various *-ts-mode
packages (like lua-ts-mode or ruby-ts-mode) are commonplace, and they
throw up a warning popup if the grammar isn't available at load time.
This is intrusive. Instead, this forces it to log to *Messages* instead
before falling back to the normal major mode.
Fortunately, these top-level `treesit-ready-p` calls have been removed
in most *-ts-mode packages in 31+, but this still impacts users on <=30
or using third party *-ts-modes that haven't adapted.
However, this doesn't suppress the warning when opening a *-ts-mode.el
file (thanks to the byte-compiler).
I removed the grammar recipes in 3b58741 to avoid redundancy with the
upstream recipes, but didn't realize that those upstream recipes weren't
added until Emacs 31, so users on 30 and older would get errors when
trying to install any missing grammars.
This also establishes a hard dependency between :lang (php +tree-sitter)
and :lang ({javascript,web} +tree-sitter).
Amend: 3b58741522
BREAKING CHANGE: This commit removes a number of core packages and
features from this module and only replaces a handful of them, so that
we can lean more on LSP and tree-sitter. To be specific:
- We used to rely on `rjsx-mode` (derived from js2-mode) for total
JS/JSX support (though imperfect; Emacs was starved for options at the
time). This has now been replaced with `js-ts-mode` (built-in after
Emacs 29), falling back to `js-mode` (very rudimentary, but a decent
fallback).
- This also meant the removal of `js2-mode`, which `skewer-mode`,
`js2-refactor`, and `xref-js2` depended on, so those were removed
too, and have *somewhat* been replaced with LSP integration (offers
jump-to-definition/references and *some* refactoring actions, but no
replacement for skewer's functionality).
- Typescript support no longer relies on the jury-rigged, web-mode-derived
major mode (because TSX support in the upstream `typescript-mode`
isn't great). We now use `typescript-ts-mode` (built-in into Emacs
29.1+), falling back to `typescript-mode`.
- JSX/TSX support now *requires* tree-sitter (and Emacs 29.1+), where
`tsx-ts-mode` is available and outshines all the alternatives (at the
time of writing).
Due to the absolute chaos that is webdev, this module sacrifices some of
the graceful-degradation I've implemented for other modules and creates
a hard requirement on tree-sitter and Emacs 29.1+ for JSX/TSX. It still
tries to degrade gracefully for plain JS and TS, but the module's doctor
and docs will actively recommend tree-sitter.
Close: #5278Fix: #6172Fix: #7042Close: #8447
Co-authored-by: ribaricplusplus <ribaricplusplus@users.noreply.github.com>
