Open klaasb opened 10 years ago
If i would now repeat|gciw| on foo, i would expect to revert to the original
You are expecting too much of tcomment. :-) Anyway, the is the ic text object that should select the current inline comment. So one could expect gcic to do what you want but it doesn't. I'll look into it when I have some time.
I also would have expected too much... (ie. gciw
to toggle an existing inline comment)
Additionally, I noticed that g<iw
doesn't seem to do anything either.
But I found that g<ac
does work (where the ac
text object is provided by a separate vim-textobj-comment plugin) and for languages like C where the inline comment is delimited by /*
and */
you can also use vim-surround to strip out the comment markers with ds/
.
+1 for nested comments. i also like ic
and ac
textobjects like the ones provided by vim-textobj-comment. it's more in line with the rest of vim than 'inline comment' vs linewise comments. but what happens with ic
and ac
when the cursor is over a nested comment? what would make sense would be selecting the inner one and then having a way to expand the selection.
after trying vim-textobj-comment on ocaml code i found it does not work since it relies on the comments and commentstring settings which are not properly defined by the ftplugin for ocaml. so apparently this way of defining comments is not reliable.
so apparently this way of defining comments is not reliable.
Unfortunately, vim doesn't provide a uniform way to retrieve info about comments formatting[1](like emacs does IIRC). That's why every commenting-related plugin sooner or later ends up including data on how to construct comments for a given filetype.
[1] The comments & commentstring option are supported only by some plugins and they don't help if you want to know how to format a comment in for a fileformat other than the current buffer's format.
that's unfortunate and worthy of an upstream improvement. well.
Given the following example in e.g. Java:
I can comment foo with
gciw
(or equivalent):If i would now repeat
gciw
on foo, i would expect to revert to the original, but instead I get:If I use
gcf/
(or equivalent) on the first / I get:on the * after the first /:
I used Java in the above example, but where this is even more useful is for languages which support proper nested comments (e.g. OCaml, Haskell, etc.).
I have not looked at the plugin code in detail to see where this could be added, but from the way it behaves, I guess it would require (more?) parsing for existing comments which does not seem to exist. Could you please add this, or point out to me where in the code we might be able to detect whether to comment/uncomment?