[Feature request] Text object for comments
This is a feature request.
Feature description
vim-commentary plugin has a text object for comment (gc), which you can use in operator pending mode. It selects the whole comment - all the adjacent lines which are commented - from anywhere within that comment. I find that a very convenient feature that allows for quick operations on the whole comment without a need to precisely select it.
As vim-commentary plugin has no support for embedded file types, which I find essential in modern programming, I'd love this feature implemented here, where embedded file types are supported.
Feature use cases
I find text object especially useful to delete commented code after I decide I'll no longer be using it - it's just a matter of doing dgc then.
The other result of that is a very useful shortcut gcgc, which uncomments the whole comment (instead of just a single line) from anywhere within that comment, without the need to precisely select the whole comment.
Example usage
An example to make it clear:
1. function f() {
2. // let i = 0;
3. // for (; i < 10; i += 1) {
4. // doSomething(i);
5. // }
6. // doFinal(i);
7. doSomethingElse();
8. }
Being anywhere in the lines 2-6 and pressing dgc would produce:
1. function f() {
2. doSomethingElse();
3. }
Being anywhere in the lines 2-6 and pressing gcgc would produce:
1. function f() {
2. let i = 0;
3. for (; i < 10; i += 1) {
4. doSomething(i);
5. }
6. doFinal(i);
7. doSomethingElse();
8. }
@robertjk You might find following two plugins helpful to use together with vim-commentary:
- https://github.com/suy/vim-context-commentstring
- https://github.com/inkarkat/vim-OnSyntaxChange
@robertjk You might find following two plugins helpful to use together with vim-commentary:
* https://github.com/suy/vim-context-commentstring * https://github.com/inkarkat/vim-OnSyntaxChange
Thanks. Actually that's what I'm on right now: vim-commentary + vim-context-commentstring. Still I thought it's good to make this plugin better by adding comment textobject support.
Still I thought it's good to make this plugin better by adding comment textobject support.
I certainly agree with you.
tcomment + text object plugin
If you prefer tcomment with its support for embedded languages over vim-commentary + vim-context-commentstring, you could go the other way and add a text object comment plugin to tcomment:
- https://github.com/glts/vim-textobj-comment
- https://github.com/thinca/vim-textobj-comment
Also the textobj-syntax should do it
- https://github.com/kana/vim-textobj-syntax
see following comment by tomtom himself: https://github.com/tomtom/tcomment_vim/issues/154#issuecomment-156822952
Implementation in commentary
When I see the sloc count of plugin/commentary.vim, one could think that this should not be a huge feature request.
The lines for setting up the mapping should also be quite similar:
onoremap <silent> <Plug>Commentary :<C-U>call <SID>textobject(get(v:, 'operator', '') ==# 'c')<CR>
" ...
omap gc <Plug>Commentary
" ...
However, vim-commentary is a simpler commenting plugin considering only linewise comments.
Existing code with name "textobject" in tcomment
It seems to be that there is already an experimental text object ic:
❯ find . -name "*textobject*"
./autoload/tcomment/textobject.vim
❯ git grep 'textobject'
autoload/tcomment/deprecated.vim: \ , 'tcommentTextObjectInlineComment': 'g:tcomment_textobject_inlinecomment'
autoload/tcomment/textobject.vim:function! tcomment#textobject#InlineComment() abort "{{{3
plugin/tcomment.vim:if !exists('g:tcomment_textobject_inlinecomment')
plugin/tcomment.vim: let g:tcomment_textobject_inlinecomment = 'ic' "{{{2
plugin/tcomment.vim:vnoremap <Plug>TComment_ic :<c-U>call tcomment#textobject#InlineComment()<cr>
plugin/tcomment.vim:noremap <Plug>TComment_ic :<c-U>call tcomment#textobject#InlineComment()<cr>
plugin/tcomment.vim: if g:tcomment_textobject_inlinecomment != ''
plugin/tcomment.vim: exec 'vmap' g:tcomment_textobject_inlinecomment ' <Plug>TComment_ic'
plugin/tcomment.vim: exec 'omap' g:tcomment_textobject_inlinecomment ' <Plug>TComment_ic'
❯ git grep 'text object'
CHANGES.TXT: - Try to handle char-type text objects (disabled by default)
CHANGES.TXT: - Experimental inline comment text object (not functional yet)
CHANGES.TXT: - Fix regression with text objects.
CHANGES.TXT: - Fix regression with text objects.
autoload/tcomment.vim: " tcomment handles those text objects most often as if they were of
doc/tcomment.txt: tcomment handles those text objects most often as if they were of
❯ git log --grep="textobject"
commit 23d9df8faaf334dd6dabf7b72c8a028be217949b
Author: Tom <[email protected]>
Date: Wed May 23 20:40:54 2018 +0200
FIX #212: s/g:tcomment_textoject_inlinecomment/g:tcomment_textobject_inlinecomment/
❯ git log --grep="text object"
commit 6f73abe23a137cb5225cec38500ede6d6e47de55
Author: Alex Roper <[email protected]>
Date: Fri Feb 14 12:43:57 2014 -0500
Fix regression with text objects.
commit 71cdff23b9c790427dce7484656b223c0a02dffd
Author: Tom <[email protected]>
Date: Fri May 17 16:08:14 2013 +0200
Experimental inline comment text object (not functional yet)
commit b4c17f3fceb9665df4d51670c96d802c20c53b8b
Author: Tom <[email protected]>
Date: Sun Apr 3 11:35:10 2011 +0200
Try to handle char-type text objects (disabled by default)
A search through the issues reveals a few matches as well
Also the textobj-syntax should do it
- https://github.com/kana/vim-textobj-syntax
The syntax textobj works well for line-wise comments.
The situation is more tricky for inline and block comments. It works but not in a consistent way. Sometimes, you have to try different maps to issue the right command and it is not easy to tell in advance which map behaves how. To make this work consistently would require some finetuning I currently don't have time for.
At least today, tcomment has the ic operator. Unfortunately it only works inside of an inline comment that does not span multiple lines. Anywhere else, it just cancels (without beeping). Even more surprisingly, it not only cancels operator-pending mode, but it also cancels out of Visual mode too.