LuaSnip icon indicating copy to clipboard operation
LuaSnip copied to clipboard

extend_load_ft is not working for some filetype

Open zjp-CN opened this issue 2 years ago • 16 comments

I try to extend NeogitCommitMessage, which is a ft defined by Neogit, from gitcommit.

Setup is here. In the commit:

  • 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.

zjp-CN avatar Aug 26 '22 17:08 zjp-CN

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)

L3MON4D3 avatar Aug 26 '22 19:08 L3MON4D3

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 }

zjp-CN avatar Aug 27 '22 01:08 zjp-CN

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"}
	})
})

L3MON4D3 avatar Aug 27 '22 08:08 L3MON4D3

Well, it doesn't work for me, either :(

zjp-CN avatar Aug 27 '22 08:08 zjp-CN

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?

L3MON4D3 avatar Aug 27 '22 14:08 L3MON4D3

it should only expand lua-snippet when inside a fenced code-block for lua

It didn't.

There is the setup and the screencast.

zjp-CN avatar Aug 28 '22 05:08 zjp-CN

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)

L3MON4D3 avatar Aug 28 '22 08:08 L3MON4D3

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.

zjp-CN avatar Aug 28 '22 09:08 zjp-CN

Weird, which parser do you use? I'm using just markdown, not markdown_inline

L3MON4D3 avatar Aug 28 '22 09:08 L3MON4D3

markdown_inline and markdown.

This is the same with markdown only:

https://user-images.githubusercontent.com/25300418/187068274-dce5d321-26fa-4fef-8e53-d2524664c176.mp4

zjp-CN avatar Aug 28 '22 09:08 zjp-CN

Huh. Which nvim-version are you on? I'm on master

L3MON4D3 avatar Aug 28 '22 10:08 L3MON4D3

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.

zjp-CN avatar Aug 28 '22 11:08 zjp-CN

Mhm, okay no difference there. That was my last guess, no idea what's different then :/

L3MON4D3 avatar Aug 28 '22 16:08 L3MON4D3

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)

L3MON4D3 avatar Aug 28 '22 16:08 L3MON4D3

image

Still { "lua", "all" } everywhere in vim.cmd... No idea...

zjp-CN avatar Aug 30 '22 03:08 zjp-CN

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?

L3MON4D3 avatar Aug 30 '22 08:08 L3MON4D3