Resolve parser lang when different from filetype

[Gelio]

Use nvim-treesitter API to resolve the parser language when it is different than the buffer's filetype.

This happens for tsx files whose filetype is typescriptreact but the Treesitter parser language is tsx. The mapping of filetypes and parser languages is stored in nvim-treesitter.

PR #4 fixed that problem before. It seems that the solution stopped working over time.

Closes #17

Before (on master)

https://user-images.githubusercontent.com/889383/173181320-7471c0ca-3580-4f3c-9794-6a09d90acb45.mp4

E5108: Error executing lua ...local/share/nvim/runtime/lua/vim/treesitter/language.lua:25: no parser for
 'typescriptreact' language, see :help treesitter-parsers
stack traceback:
        [C]: in function 'error'
        ...local/share/nvim/runtime/lua/vim/treesitter/language.lua:25: in function 'require_language'
        /usr/local/share/nvim/runtime/lua/vim/treesitter.lua:39: in function '_create_parser'
        /usr/local/share/nvim/runtime/lua/vim/treesitter.lua:98: in function 'get_parser'
        ...nvim/site/pack/packer/start/nvim-treehopper/lua/tsht.lua:53: in function 'nodes'
        [string ":lua"]:1: in main chunk
Press ENTER or type command to continue

After

https://user-images.githubusercontent.com/889383/173181326-4f90d48e-8af5-4850-8151-485a2c0b0a17.mp4

[mfussenegger]

Sorry but I don't want this plugin to depend on nvim-treesitter. It should only depend on treesitter APIs that are part of neovim core.

[Gelio]

That's surprising to me. nvim-treesitter seems like a standard plugin to use alongside the built-in treesitter APIs, even for installing plugins. I'm genuinely curious why you would rather this plugin not depend on nvim-treesitter.

Regardless, do you have a suggestion how to fix the problem with the parser language being different that filetypes without requiring nvim-treesitter? This is the problem that this PR solves.

[mfussenegger]

That's surprising to me. nvim-treesitter seems like a standard plugin to use alongside the built-in treesitter APIs, even for installing plugins. I'm genuinely curious why you would rather this plugin not depend on nvim-treesitter.

Part of the intention of nvim-treesitter was to have a faster moving playground to experiment with the treesittter and additional APIs before they go into core. But the goal is to have everything necessary to create plugins like this without nvim-treesitter. If necessary components are missing these should eventually make it into core. There is already work ongoing in this direction (e.g. https://github.com/neovim/neovim/pull/18232). As a neovim core contributor myself part I'd rather help in that regard and keep my plugins free of nvim-treesitter. It's not that there is anything wrong with nvim-treesitter itself, it's that this helps inform what might be needed in neovim core itself.

Regardless, do you have a suggestion how to fix the problem with the parser language being different that filetypes without requiring nvim-treesitter?

Not yet, I'll have to take a closer look at why it broke (or ever worked)

[Gelio]

I see, thanks for a thorough explanation. I believe I understand why you want to keep away from using nvim-treesitter in this plugin. I'll wait for your suggestions on how to tackle this problem in a different way, other than hardcoding the mapping of those special filetype -> parser names.

[mfussenegger]

See https://github.com/mfussenegger/nvim-treehopper/pull/30