[mini.ai] cannot use treesitter textobjects inside an injected language

[datwaft]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version of the main branch

Module(s)

mini.ai

Neovim version

0.12 (!at least latest Nightly build!)

I can also reproduce with v0.11.4.

Description

tree-sitter textobjects don't work inside injected languages.

For example with the following markdown document:

# Some document

This document contains some text:

```python
x = 10
```

And the following queries:

(fenced_code_block
  (code_fence_content) @cell.inner) @cell.outer

And the following text object:

local spec_treesitter = require("mini.ai").gen_spec.treesitter
require("mini.ai").setup({
	custom_textobjects = {
		c = spec_treesitter({ a = "@cell.outer", i = "@cell.inner" }),
	},
})

If your cursor is in ```python and you press vic the inside of the codeblock will be selected, but if your cursor is inside the codeblock then the following error will appear:

E5108: Lua: (mini.ai) Can not get query for buffer 1 and language "python".
stack traceback:
        [C]: in function 'error'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:2029: in function 'error'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:1612: in function 'error_treesitter'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:1569: in function 'range_querier'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:1006: in function 'spec'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:1363: in function 'get_textobject_spec'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:606: in function 'find_textobject'
        ...s/datwaft/.local/share/nvim/lazy/mini.ai/lua/mini/ai.lua:1061: in function 'select_textobject'
        [string ":lua"]:1: in main chunk

Reproduction

1. Create separate 'nvim-repro' config directory:

   • '~/.config/nvim-repro/' on Unix
   • '~/AppData/Local/nvim-repro/' on Windows

2. Inside 'nvim-repro' directory create a file named 'init.lua'.
   Populate it with the following content:

   -- Clone latest 'mini.nvim' (requires Git CLI installed)
   vim.cmd('echo "Installing `mini.nvim`" | redraw')
   local mini_path = vim.fn.stdpath("data") .. "/site/pack/deps/start/mini.nvim"
   local clone_cmd = { "git", "clone", "--depth=1", "https://github.com/nvim-mini/mini.nvim", mini_path }
   vim.fn.system(clone_cmd)
   vim.cmd('echo "`mini.nvim` is installed" | redraw')
   
   -- Make sure 'mini.nvim' is available
   vim.cmd("packadd mini.nvim")
   require("mini.deps").setup()
   
   MiniDeps.add({
   	source = "nvim-treesitter/nvim-treesitter",
   	checkout = "main",
   	hooks = {
   		post_checkout = function()
   			vim.cmd("TSUpdate")
   		end,
   	},
   })
   
   vim.api.nvim_create_autocmd("FileType", {
   	group = vim.api.nvim_create_augroup("tree-sitter-enable", { clear = true }),
   	callback = function(args)
   		local lang = vim.treesitter.language.get_lang(args.match)
   		if not lang then
   			return
   		end
   
   		if vim.treesitter.query.get(lang, "highlights") then
   			vim.treesitter.start(args.buf)
   		end
   	end,
   })
   
   local spec_treesitter = require("mini.ai").gen_spec.treesitter
   require("mini.ai").setup({
   	custom_textobjects = {
   		c = spec_treesitter({ a = "@cell.outer", i = "@cell.inner" }),
   	},
   })

3. Inside 'nvim-repro/queries/markdown' directory create a file named 'textobjects.scm'.
   Populate it with the following content:

   ; extends
   
   ; inner cell and outer cell textobjects
   (fenced_code_block
     (code_fence_content) @cell.inner) @cell.outer
   

4. Run NVIM_APPNAME=nvim-repro nvim (i.e. execute nvim with NVIM_APPNAME environment variable set to "nvim-repro").
   Wait for all dependencies to install.

5. Execute :TSInstall python markdown markdown_inline

6. Try vic outside a codeblock and inside a codeblock. Right now it works outside but not inside.

Screen.Recording.2025-09-15.at.00.26.44.mov

As you can see in the video if the cursor is in any line with text it also doesn't work.

[datwaft]

Bisecting the commits, the last commit that worked for me was nvim-mini/mini.ai@4b5348f.

[datwaft]

Fun fact: looks like my workflow was the opposite of #1836, instead of using a text object inside the codeblock I want the text object to select something outside the injected language (the codeblock itself).

Ideally, I think, we should give priority to text objects inside the injected language but search outside the injected language if the text object doesn't exist in the injected one.

[echasnovski]

Thanks for the issue!

I did not try to reproduce the particular steps in the issue, but I did encounter this myself recently in a similar situation. The markdown file has both markdown and markdown_inline parsers, which leads to textobjects for markdown to not be recognized when the "smallest local tree-sitter parser" is markdown_inline. Although this is working as intended, it should probably be improved somehow.

Ideally, I think, we should give priority to text objects inside the injected language but search outside the injected language if the text object doesn't exist in the injected one.

At the moment I don't think I like the idea because it introduces issues about how the textobject should be searched. Like if there is a non-covering textobject with injected language and covering textobject for parent language, which one should be chosen with cover_or_next search method. I'd probably expect the former, but I can see how the latter can be expected.

My current idea is to allow to specify "valid" languages for textobject. Then they can be adjusted specifically for filetype to query only expected parser. This has both upsides and downsides, which mostly are related to expected workflow and use cases. I'll take a look.

[echasnovski]

This should now be resolved on latest main after #2010. The textobject is searched not only in the injected language at cursor, but also goes up their parents until textobject is found. This feels like a reasonable behavior here.