Skip to content

Conversation

zdm
Copy link
Contributor

@zdm zdm commented Mar 30, 2025

This patch allows to flexibly define snippets for injected languages.
Now treesitter filetype detector returns two filetypes:

  1. filetype for code under the cutsor;
  2. combined filetype for code under the cursor + parent code block (for injected language);

For example, for lua injected into vim script it will retirn:

{
    filetype = "lua",
    injected_filetype = "vim/lua",
}

This will allow users to configure snippets more flexibly. For example, if I want to add some snippets for lua code, injected into vim, for example vim.print( $1 ), I will need to setup filetypes mapping like this:

vim.g.vsnip_filetypes = {
    [ "vim/lua" ] = { "lua", "vim/lua" },
}

So for regular lua script lua.json snippets will be used, and for injected vim/lua - lua.json and vim/lua.json.

@zdm
Copy link
Contributor Author

zdm commented Mar 31, 2025

I have no idea, why tests are failed.
There are no any helpful messages in the log.
For me it works under linux and winfows.
Could you take a look please?

@hrsh7th
Copy link
Owner

hrsh7th commented Mar 31, 2025

Thank you.

Is there any precedent in the vim/neovim ecosystem for calling an embedded file type something like vim/lua?

If it's a custom extension I would be hesitant to merge the PR.

@zdm
Copy link
Contributor Author

zdm commented Mar 31, 2025

No conflicts with vim/nvim.
This format ("vue/htnl", etc...) is used internally only and does not passed to the editor.
It used only in the lua code to find appropriate filetypes mapping (if they were defined by the user).

@zdm
Copy link
Contributor Author

zdm commented Mar 31, 2025

I changed filetype separator to ".", this is more vim-like. This doesn't affect anything, just for consistency.

@zdm
Copy link
Contributor Author

zdm commented Apr 4, 2025

@hrsh7th
Hi, will you accept it? Tell me please if you have any questions.

@zdm
Copy link
Contributor Author

zdm commented Apr 8, 2025

Hi, man.
So, what is your decision?
Please, reject it, if you don't want this changes.

@hrsh7th
Copy link
Owner

hrsh7th commented Apr 8, 2025

What I'm wondering is that this function is so useful and versatile that a standard mechanism will eventually be implemented in the neovim core.

In other words, if we choose ft/ft or ft.ft here and the official version chooses ft#ft, it will lose consistency.

Apart from that, I think ft/ft is better.

For now, let's merge with ft/ft.

@zdm
Copy link
Contributor Author

zdm commented Apr 8, 2025

So, should I revert separator back from "." to "/" and you will merge?

@hrsh7th
Copy link
Owner

hrsh7th commented Apr 8, 2025

yes :)

@zdm
Copy link
Contributor Author

zdm commented Apr 8, 2025

Filetype separator reverted to "/".

@hrsh7th
Copy link
Owner

hrsh7th commented Apr 8, 2025

thank you

@hrsh7th hrsh7th merged commit 0a4b841 into hrsh7th:master Apr 8, 2025
0 of 11 checks passed
@zdm
Copy link
Contributor Author

zdm commented Apr 8, 2025

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants