I am running Emmet via emmet-ls, a LSP with Snippet-support, which plugs its snippets into my completion-engine, nvim-cmp, via a generic LSP-source.
I am, however, also running Ultisnips. A seperate Snippet-Engine, that plugs its own set of snippets via its own source into my completion-engine.
On its own, either works fine. In the HTML and CSS filetypes, the snippets conflict. As Emmet specifies a complex syntax for its snippets, some keywords trigger the expansion via Ultisnips instead of Emmet.
Example:
<!-- div>h expands to -->
<div>
<h></h>
</div>
<!-- div>a should expand to -->
<div>
<a.../>
</div>
<!-- instead -->
div><a.../>
The snippet a is captured by UltiSnips, so no complete Emmet snippet is created and only the a snippet is expanded.
Ultisnips can not be disable for a single filetype, one could however delete all snippets for that filetype.
As I am considering swammping to Luasnips anyway, this issue is postponed and serves only as documentation right now.
I am running Emmet via emmet-ls, a LSP with Snippet-support, which plugs its snippets into my completion-engine, nvim-cmp, via a generic LSP-source.
I am, however, also running Ultisnips. A seperate Snippet-Engine, that plugs its own set of snippets via its own source into my completion-engine.
On its own, either works fine. In the HTML and CSS filetypes, the snippets conflict. As Emmet specifies a complex syntax for its snippets, some keywords trigger the expansion via Ultisnips instead of Emmet. Example:
The snippet
a
is captured by UltiSnips, so no complete Emmet snippet is created and only thea
snippet is expanded. Ultisnips can not be disable for a single filetype, one could however delete all snippets for that filetype. As I am considering swammping to Luasnips anyway, this issue is postponed and serves only as documentation right now.