[bug] Markdown integration breaks dynamic commentstring on nightly about image.nvim HOT 16 CLOSED

I almost have the solution! PR soon :)

from image.nvim.

Works now! :)

from image.nvim.

That's https://github.com/numToStr/Comment.nvim, right? I can reproduce this.

from image.nvim.

So, here is what I found out so far:

Comment.nvim get's the treesitter parser of the current buffer here https://github.com/numToStr/Comment.nvim/blob/0236521ea582747b58869cb72f70ccfa967d2e89/lua/Comment/ft.lua#L270
vim.print(parser) reveals that when image.nvim is disabled, the parser has injections (which it needs to find the correct language context for the commentstring), but when we enable it, the parser comes with:

_injections_processed = false,

And I have no idea why another plugin has an influence on vim.treesitter.get_parser.

from image.nvim.

Very weird that it does that. The parser is shared per-buffer, but it shouldn't have an impact on injections.
We just get the root and run a query on it :(

from image.nvim.

It's also weird because my plugin otter.nvim that provides the lsp features for injected languages also uses the parser and neither breaks itself nor breaks comments

from image.nvim.

My suspicion is that in image.nvim we are only getting the inline parser

    local parser = vim.treesitter.get_parser(buf, "markdown_inline")

and nvim.treesitter somehow caches this and remembers this for the current buffer.
Thus, when comment.nvim asks for the buffer: local ok, parser = pcall(vim.treesitter.get_parser, A.nvim_get_current_buf()), they get only the inline parser.
My plugin on the other hand explicitly specifies the language of the parser: https://github.com/jmbuhr/otter.nvim/blob/93227da6bc7db5c0e331df81dd92e91520e084de/lua/otter/keeper.lua#L207 and thus does not break.

So I think the fix is to explicitly get the parser language in Comment.nvim (with vim.treesitter.language.get_lang() for the current filetype instead of falling back to whatever parser was last created.

EDIT
That didn't work so far.
I tried replacing the parser getting code in Coment.nvim with

    local buf = A.nvim_get_current_buf()
    local parsername = vim.treesitter.language.get_lang(vim.api.nvim_buf_get_option(buf, "filetype"))
    local ok, parser = pcall(vim.treesitter.get_parser, buf, parsername)

but the parser still comes without injections processed.

from image.nvim.

Super interesting, so it should work if it gets the parser after Comment.nvim.
Maybe it would work if we request the "markdown" parser first, then the inline one.

from image.nvim.

I tried that, but it then the query can't find the image node. Something is preventing the part in image.nvim from processing injections, and the inline parser is an injection into the block markdown parser.

from image.nvim.

This is all very weird

from image.nvim.

It might be worth it to bisect nightly versions as well. Would take a little bit but I suspect it would lead us right to the problem. Since it works on stable.

Unfortunately I've completely broken my Linux install (first time :D) and am really busy this weekend so I can't do that myself for a little bit.

from image.nvim.

True, maybe it's a neovim issue.

from image.nvim.

So get_parser uses a table of parsers indexed by buffer number, meaning the first time a parser is being asked for for a buffer it is created and then reused. https://github.com/neovim/neovim/blob/master/runtime/lua/vim/treesitter.lua#L107

What this means in practice is that we can break other plugins when we attach a parser to a buffer that doesn't match the expected language associated with the filetype. So I believe the correct thing to do is actually change it here and don't require the "markdown_inline" parser but just the "markdown" parser. This will also require changing the way the query is handled, I'm not quite sure yet how to directly query a child-tree. Here is someone having the same question: tree-sitter/tree-sitter#2696

from image.nvim.

Awesome insight, thanks for researching. The behavior is very weird, wondering if it should be classified as a bug in Neovim. Anyhow, maybe we can work around this by not using the buffer parser, just getting its text and parsing it with markdown-inline separately.

from image.nvim.

#58

from image.nvim.

Fixed by #58 🎉

from image.nvim.