nvim-surround
nvim-surround copied to clipboard
`cst` on JSX <a> tag with onClick prop using arrow function does not change the surround tag
Checklist
- [X] Have you tried updating the plugin to the latest version?
- [X] Have you checked the Breaking Changes issue?
- [X] Have you read through
:h nvim-surround
to see if there might be any relevant information there?
Neovim Version
NVIM v0.8.3
Plugin Version
Nightly (Beta)
Minimal Configuration
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({
"git",
"clone",
"--filter=blob:none",
"https://github.com/folke/lazy.nvim.git",
"--branch=stable", -- latest stable release
lazypath,
})
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({
"wellle/targets.vim",
"kylechui/nvim-surround"
})
Sample Buffer
<a onClick={(event) => {event.preventDefault(); console.log('this does not change the surrounding tag');}>My link text</a>
Keystroke Sequence
cstbutton<CR>
Expected behavior
<button>My link text</button>
Actual behavior
<button> {event.preventDefault(); console.log('this does not change the surrounding tag');}>My link text</button>
Additional context
No response
This seems like a pattern matching issue, since the arrow function has a >
symbol in it. I'm not entirely sure what heuristic to use here to discern what is or is not an arrow function, aside from using Tree-sitter. Is there a particular server that is used most commonly here?
I could also try pattern matching against =>
as a pair I think...
Note to self: seems like it can be solved by taking the middle child from this kind of jsx_element
by using queries:
(jsx_element
open_tag: (jsx_opening_element) @open
. (_) @inside .
close_tag: (jsx_closing_element) @close
) @tag
Any jazzing on this 🎷? I don't really know how to set up a dev environment for neovim plugins. Do you know of any resources to get me setup so I can try my hand at contributing to the code?
I would take a look at this: https://github.com/folke/neodev.nvim. You can try adjusting the Lua pattern for HTML tags as a workaround in configuration, but I don't think it's possible to do this without queries.
I did some more thinking about this and I think it makes more sense for users to provide this functionality themselves, as opposed to having it built-in to the plugin, since it's filetype/treesitter/user specific. One thing that comes to mind in particular is that if the tag is inside some string for some reason, treesitter will fail to recognize it, and I think it would be overly opinionated of the plugin to assume that users want things one way or another (feels reminiscent of this comment).
I think I'll close this as not planned; if you need help implementing it for yourself then feel free to let me know!