LuaSnip
LuaSnip copied to clipboard
extend_load_ft is not working for some filetype
I try to extend NeogitCommitMessage, which is a ft defined by Neogit, from gitcommit.
- Clear the snippets of NeogitCommitMessage
- Extend NeogitCommitMessage from gitcommit
- No luasnip triggered from gitcommit in NeogitCommitMessage
When I type luasnip
, it should have triggered this. The process is recorded luasnip: NeogitCommitMessage.
luasnip
is working in gitcommit. The process is recorded too luasnip: gitcommit.
Ah, load_ft_func
is exclusively used by the loaders, for your purposes ls.ft_extend("NeogitCommitMessage", {"gitcommit"})
should do it.
load_ft_func
is useful when files need to expand snippets from filetypes different from their own (eg. whatever is reported by ft_func
and the ft_extend
-system). One example for this is treesitter-aware expansion in markdown-files (fenced code blocks could be lua
or json
, for example)
I think it's ls.filetype_extend
. I've seen that usage in the Examples, but I forgot it :(
Now it works!
treesitter-aware expansion in markdown-files
Could you give an example code for this? I tried the following, and no snippet defined in rust or lua snippet files shows up.
local load_ft_func = extend_load_ft {
markdown = { 'rust', 'lua' },
}
ls.setup { load_ft_func = load_ft_func }
Ah, that's what ft_func
is responsible for that:
ls.setup({
ft_func = require("luasnip.extras.filetype_functions").from_pos_or_filetype,
load_ft_func = require("luasnip.extras.filetype_functions").extend_load_ft({
markdown = {"lua", "json"}
})
})
Well, it doesn't work for me, either :(
Oh, it should only expand lua-snippet when inside a fenced code-block for lua (eg. only expand snippets of the filetype treesitter reports for the current cursor-position), does that work?
it should only expand lua-snippet when inside a fenced code-block for lua
It didn't.
There is the setup and the screencast.
Ouh, looks like the markdown-parser is a tad unreliable when it comes to reporting the correct filetype :|
get_snippet_filetypes
is used internally to get the active filetypes at the cursor-position, so anything reported there is valid for the next expand.
https://user-images.githubusercontent.com/41961280/187065228-412278cb-1a96-4c89-ba3d-6638a19bc625.mp4
(Whenever I've typed fn
and nothing happens for a while, I'm furiosly mashing expand
:D)
https://user-images.githubusercontent.com/25300418/187066928-d80076fa-30e4-493d-9fb5-f63956700d59.mp4
I tried get_snippet_filetypes
too, and the filetype in codefence is always { "markdown", "all" }
for me, though I see you get lua
filetype somewhere.
Weird, which parser do you use? I'm using just markdown
, not markdown_inline
markdown_inline
and markdown
.
This is the same with markdown
only:
https://user-images.githubusercontent.com/25300418/187068274-dce5d321-26fa-4fef-8e53-d2524664c176.mp4
Huh. Which nvim-version are you on? I'm on master
NVIM v0.8.0-dev-922-g42e9fe7d9
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-10 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/cmake.config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az130-680
The full config is here.
Mhm, okay no difference there. That was my last guess, no idea what's different then :/
Could you try if injected filetypes are recognized in other circumstances? For example, vim.cmd
in lua-files (depends on the lua-parser though, so you might have to add it)
Still { "lua", "all" }
everywhere in vim.cmd
... No idea...
Mmmmmm that's very weird, it looks like the highlight is even correct.
from_pos_or_filetype
is defined in this file, you could insert some prints
to find what's going wrong.
Maybe one of the nvim-treesitter
-requires is not resolved?