Comment.nvim
Comment.nvim copied to clipboard
jsx
tl;dr - I am just playing with the idea of making jsx first-class, probably via pre_hook but if the implementation gets more complicated than I hope it to be then I'll probably make this a separate plugin.
Usage
require('Comment').setup({
pre_hook = function(ctx)
return require('Comment.jsx').calculate(ctx)
end,
})
Why?
- It's fun to play with treesitter.
- I personally don't like the verbose integration with
context-commentstring. jsxis the only thing that is missing to make this plugin a masterpiece.- And lastly, one less plugin to install(?)
What's missing?
In its current state, it works but does have some issues regarding accuracy
~1. Can't comment/uncomment multiple attributes at once [^1]~ Fixed using workaround
Details
- Actual
<p
{/* he="llo" */}
{/* wor="ld" */}
para="graph"
>
this is a p tag
</p>
- Expected
<p
// he="llo"
// wor="ld"
para="graph"
>
this is a p tag
</p>
(Also when uncommenting, expecting // to be used instead of {/* */})
~2. Can't uncomment the following at once [^1]~ Fixed using workaround
Details
<div>
{/* <section> */}
{/* <p>hello</p> */}
</section>
</div>
(This is not a priority, as the syntax is already broken)
- Actual
<div>
// {/* <section> */}
// {/* <p>hello</p> */}
</section>
</div>
- Expected
<div>
<section>
<p>hello</p>
</section>
</div>
[^1]: Both of them are a non-issue if you comment/uncomment them individually
FAQ
Why
pre_hookis needed?
Because everyone is not using jsx so if you need it then that's da way.
Is this going to be shipped with the plugin?
As I said it depends on the implementation. If it's small, simple, and covers most cases then I'll merge it.
Any other issues?
I don't use jsx that much, so if you find something feel free to comment. And to be clear I am not aiming for 100% accuracy but ~90%. So, there is a chance that some issue won't get fixed.
Can I use it? Is this stable?
Yes, you can definitely use it. And as you know JS is JS so this will always remain experimental.
For testing
sample.tsx
const Yoo = () => {
return (
<div>
<section>
<p>hello</p>
<p
he="llo"
wor="ld"
attr={{
...window,
hello: () => {
return (
<section>
<p>IDK</p>
</section>
);
},
}}
>
hello
</p>
<p>{true ? "true" : "false"}</p>
<p>{true && "true"}</p>
<p>
{true && (
<section>
<p>This is awesome</p>
</section>
)}
</p>
<div id="div">
{getUser({
name: "numToStr",
job: "making plugins",
})}
</div>
</section>
<div className="flex items-center justify-center image-uploader">
<span className="animate-ping h-4 w-4 rounded-full bg-sky-400 opacity-75"></span>
</div>
</div>
);
};
It seems this is blocked by the following upstream issues:
- https://github.com/neovim/neovim/pull/15330 - To capture sibling comment or attribute nodes using the
+quantifier - https://github.com/neovim/neovim/pull/17099 - To easily iterating over captured nodes
I currently implemented a workaround for this.
Excellent! Waiting for this 🥂
@kuntau It would be helpful if you can test this out and report any cases where comments are not correct apart from the issues that are already listed :)
Previously mentioned issues are now fixed (workaround) so this is now usable (I am using it) but there might be some cases where different commentstring might get used. I am leaving this PR for further testing.
To be clear I am not aiming for 100% accuracy but ~90%. So, there is a chance that some issue won't get fixed.
I was trying this out, it seems that this doesn't trigger for .tsx files? Works great for .js files though, though it seems that it comments individual lines rather than a block. Is that the expected behaviour?
https://user-images.githubusercontent.com/6487613/171071876-37a03f90-9361-4fb4-bcaa-b865c21fcc77.mp4
I was trying this out, it seems that this doesn't trigger for
.tsxfiles?
Works for me though. Do you have tsx parser installed?
though it seems that it comments individual lines rather than a block. Is that the expected behaviour? https://user-images.githubusercontent.com/6487613/171071876-37a03f90-9361-4fb4-bcaa-b865c21fcc77.mp4
I think you are pressing gc in this clip. Try with gb.
I wasn't aware that there's a tsx parser, I only had the typescript one installed.
Everything seems to work as expected, including gb and gc behaviour! Thank you!
Seems to work fine when we just have JSX elements around, but breaks when I have normal HTML element like <option>.

seems has problem with Jsx Component with props(use gc)

@ecosse3 @ShiChenCong Nice catch! I'll try to fix those issue.
@ShiChenCong Is that a self closing element in the image? Can you reply with the element that you are facing issue with, if that's ok.
@numToStr I've been using this PR for the last few days and have not noticed any weird behavior whatsoever. Seems to be working quite great in a React environment for me so far! Thanks for the hard work on this 😄
I can confirm the bugs that @ecosse3 has reported. It sometimes can't comment regular HTML tags correctly. for some reason if I remove the className it works!
https://user-images.githubusercontent.com/87268103/171988969-b9020f08-7bc3-48e3-8f42-becd4d00d2ca.mp4
Also:
https://user-images.githubusercontent.com/87268103/171989054-7c5ecfe8-4bc9-453c-8059-3f005586de2b.mp4
The jsx:
<NodeViewWrapper className="flex items-center justify-center image-uploader">
{loading && (
<span className="animate-ping h-4 w-4 rounded-full bg-sky-400 opacity-75"></span>
)}
</NodeViewWrapper>
@ahhshm I was able to reproduce the same.
My observation is that any element that has attributes on the same line alongside the opening element is using wrong comment string. It doesn't matter whether it's a custom or native elements.
@numToStr Sorry for reply so late, yes, It is self closing element
@ShiChenCong No problem. Now it should work with self closing element.
@ahhshm @ecosse3 I pushed a fix that should resolve the issue that you were facing before.
@numToStr Sorry for the late response.
It seems like updates have solved all of the previous problems. I just found a small bug, it has a little problem with uncommenting opening fragment tags:
https://user-images.githubusercontent.com/87268103/174428050-e2719393-6eb0-4c06-958f-73dc8772537b.mp4
with ts_context_commentstring:
https://user-images.githubusercontent.com/87268103/174428296-a00134b6-b0f7-4e99-9559-7820bd5b4281.mp4
The jsx (for testing):
<NodeViewWrapper as="figure" dir="ltr" data-type="custom-image">
{node.attrs.src && (
<>
<img
src={node.attrs.src}
alt="Image"
className={`${node.attrs.src.startsWith("data:") && "blur-sm"}`}
/>
<bdi>
<NodeViewContent as="figcaption" className="text-center" />
</bdi>
</>
)}
</NodeViewWrapper>
@ahhshm hmmm...this also seems to be broken in context-commentstring. I'll try to fix this.
Any update on this? I've been using this branch since it was created and it's working fine for me. I haven't encountered any specific bug in a while and although it's a WIP, it seems pretty stable. Anything that I can help you with to merge it into the main beach sooner?
No pressure btw. I just want to know when I can remove branch="jsx" in my packer config:)
@ahhshm I am really happy to hear that this is working without any major hiccups. As I said earlier, my main reason for holding this out is because
- lack of
+quantifier https://github.com/neovim/neovim/pull/19563 (this will also help in text objects 😋) - Improved
Query:iter_matches()API https://github.com/neovim/neovim/pull/17099
Both would've helped in making the implementation robust and much nicer but it seems both PRs are kinda blocked, sadly.
For those who are still looking for a temporary solution. You can check this ,https://github.com/JoosepAlviste/nvim-ts-context-commentstring#commentnvim
I'm getting this message every time I attempt to comment in jsx.
I believe I've configured the pre_hook properly:
Update:
Updating the pre_hook now shows the nil error everywhere, not just in JSX files. I've tried to just call require on 'Comment.jsx' and it throws a not found error.
Please help.
Update:
Updating the pre_hook now shows the nil error everywhere, not just in JSX files. I've tried to just call require on 'Comment.jsx' and it throws a not found error.
Please help.
This is also happening to me.
Any news about this? I am getting [Comment.nvim] nill message when using this branch.