The default mapping <CR> overrides the default behavior of the quickfix. Instead of opening the file, it throws this error:

E5108: Error executing lua: ...r/neovim/0.9.1/share/nvim/runtime/lua/vim/treesitter.lua:190: attempt to index local 'node_or_range' (a nil value)
stack traceback:
        ...r/neovim/0.9.1/share/nvim/runtime/lua/vim/treesitter.lua:190: in function 'get_node_range'
        ...cal/share/nvim/lazy/wildfire.nvim/lua/wildfire/utils.lua:13: in function 'get_range'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:30: in function 'unsurround_coordinates'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:78: in function 'update_selection_by_node'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:96: in function 'init_by_node'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:104: in function <...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:101>

Default behavior of NODES("{[ < is good, but i MOSTY do WORD selection which is not seem to happening

example of wats wrong

just give me a way to do so :)

Issue

<CR> is by default mapped to starting and incrementing a selection. While this is a great default binding, it causes issues in quickfix windows. In a quickfix, <CR> moves the cursor to the selected entry, but this plugin's binding of <CR> raises an error, and does not move the cursor.

E5108: Error executing lua: /usr/share/nvim/runtime/lua/vim/treesitter.lua:190: attempt to index local 'node_or_r
ange' (a nil value)
stack traceback:
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:190: in function 'get_node_range'
        ...cal/share/nvim/lazy/wildfire.nvim/lua/wildfire/utils.lua:13: in function 'get_range'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:30: in function 'unsurround_coordinates'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:78: in function 'update_selection_by_node'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:96: in function 'init_by_node'
        ...ocal/share/nvim/lazy/wildfire.nvim/lua/wildfire/init.lua:104: in function <...ocal/share/nvim/lazy/wil
dfire.nvim/lua/wildfire/init.lua:101>

Therefore, it would be useful to specify a list of filetypes (i.e. qf for quickfix) on which to not set this mapping (or revert <CR> back to the original)

Workaround

I can manually run the following in a quickfix window, and then things will work as expected again.

:noremap <CR> <CR>

Or I can add an autocommand into my wildfire config as follows:

{
    'sustech-data/wildfire.nvim',
    event = 'VeryLazy',
    dependencies = { 'nvim-treesitter/nvim-treesitter' },
    config = function()
        require('wildfire').setup()

        local augroup_revert_cr = vim.api.nvim_create_augroup('revert_cr', {})

        vim.api.nvim_create_autocmd({ 'FileType' }, {
            group = augroup_revert_cr,
            pattern = { 'qf' },
            desc = "Revert wildfire's <CR> on filetypes",
            callback = function()
                vim.cmd('noremap <CR> <CR>')
            end,
        })
    end,
}

I would argue that the ability to specify filetypes for which to revert/disable the mapping is better than to hardcode the fix for quickfix alone. I can image that one might have already remapped <CR> for certain filetypes, which would require falling back to this autocommand for solving the issue.

On the offhand, one could instead/also specify a list of filetypes for which to enable the mappings.

This here is a perfectly reasonable workaround though, so I understand if there is no interest in addressing this particular issue.

First of all, I want to express my gratitude for the fantastic plugin. When I use the incremental selection that comes with treesitter its selection strategy is always too aggressive ('a' instead of 'i'). it often annoys me, until I find the plugin you wrote. It is what I've been looking for !

However, I would like to propose an additional feature that I believe would further improve the usability of the plugin:

I suggest adding support for continuous commented lines. . For example, consider the following code:

surrounds = {
  { "(", ")" },
  -- { "{", "}" },
  -- { "<", ">" },
  -- { "[", "]" },
}

When incrementally selecting the content, it would be helpful if the plugin could select the commented lines:

	-- { "{", "}" },
	-- { "<", ">" },
	-- { "[", "]" },

And then, upon further incremental selection, expand the selection to include the surrounding {} block:

  { "(", ")" },
  -- { "{", "}" },
  -- { "<", ">" },
  -- { "[", "]" },

This feature would provide a more intuitive and granular selection process, allowing users to easily select and manipulate commented sections of their code.

I know this may be a big change to your code. so if you don’t want this, it’s just ok😀.

I have this custom keymap

keymap("x", "<bs>", function()
    vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("holo", true, false, true), "t", false)
end, opts)

which simply shrink one char at two side as a workaround for too aggressive in incremental selection
but this plugin will ignore this changed selection range and after I type bs and type CR again it will expand further like I don't type bs, which behaves different of treesitter' orignal one.