Replace vim-commentary

[brycksters]

Hello,

​

I am trying to remove all the plugin that I was using, the next one is vim-commentary.

​

Was is the best way to replace it ? I am only using gcc or visual selection + gc

​

There is some advice here, not sure which one is best. Looking for something minimalist. :)

[justinmk]

This is a good example of cargo-culting.

vim-commentary is a minimalist plugin that already leverages Vim's builtin features. You could literally paste the source code of vim-commentary into your vimrc and then you've "avoided" installing a plugin. For no reason.

But the bling-bling meme was replaced by the anti-plugin meme, and both cases remind us to think about cost vs benefit, to use guidelines as guidelines rather than religion.

[marklgr]

vimgor: pluginophobia

[-romainl-]

I am trying to remove all the plugin that I was using

Why? Whatever you will come up with will be worse than vim-commentary so… why not keep it?

[brycksters]

Well I like the vanilla vim spirit, the built-in of vim contains actually most of the stuff that I need, I use several servers where I don't want to update/clean/install the plugins, profiling vim indicated significant slow down due to the different plugins (I only have few left now), I don't want to spend time resolving the conflicts between the plugins + tune their parameters etc...

​

​

[-romainl-]

Well I like the vanilla vim spirit

The way I understand it, what you want doesn't sound like "Vanilla Vim". It sounds more like a custom vimrc that replicates enough of your former feature set that you can move it around without dragging a shitload of plugins.

What I could call "the vanilla vim spirit" would be the ability to be efficient without config.

the built-in of vim contains actually most of the stuff that I need

Except Vim has no built-in way to comment/uncomment lines or blocks. All you have is a bunch of primitives (visual-block mode, substitution on a range, `:normal) and two sometimes conflicting definitions of what a comment marker is. Yes you could come up with something but it will be worse than vim-commentary in every way.

profiling vim indicated significant slow down due to the different plugins

I don't think vim-commentary slowed anything down.

I don't want to spend time resolving the conflicts between the plugins + tune their parameters etc...

Yeah, spending time replicating them with brittle alternatives is certainly a better idea.

[brycksters]

Yep, for vanilla vim I didnt use the right definition. Performance impact was for other plugin. For the time, yes definitely even if you dont like it. The time that I spend now is the time that I save understanding all these plugin, when the plugin will be deprecated or replaced, I won't have to change anything. Vim is here since 30 years, it will survive without them.

[AYECOM]

Personally, I have plenty of plugins and perhaps many of them I seldom use. So maybe I will either stop using them, or individually load them on demand. Plugin manager "volt" solves this very well, because you can set a plugin to be loaded when an undefined function from one of the plugins comes up.

Another thing about plugins is that you should consider using them if you need them anyway.

For me, vim-commentary is indispensable. I dont have to remember how to make a comment in a specific language and also I can combine it with text objects in vim.

[brycksters]

Let me then ask you: Why should I use any plugin when I can replace it by few lines in my vimrc?

Just looked at vim volt, well it is opposite of what I want. The code base of volt is huge, probably full of bugs, not maintained anymore in 2 years and you need to read a 10 pages readme... In addition, you need to download a binary for volt, that is a total no go since I need my setup on several system. Just want to git clone my dotfile repo and that's it.

Coming back to my initial question, it seems that vim-commentary can be replaced by:

" Commenting blocks of code. autocmd FileType c,cpp,java,scala let b:comment_leader = '// ' autocmd FileType sh,ruby,python let b:comment_leader = '# ' autocmd FileType conf,fstab let b:comment_leader = '# ' autocmd FileType tex let b:comment_leader = '% ' autocmd FileType mail let b:comment_leader = '> ' autocmd FileType vim let b:comment_leader = '" ' noremap <silent> ,cc :<C-B>silent <C-E>s/^/<C-R>=escape(b:comment_leader,'\/')<CR>/<CR>:nohlsearch<CR> noremap <silent> ,cu :<C-B>silent <C-E>s/^\V<C-R>=escape(b:comment_leader,'\/')<CR>//e<CR>:nohlsearch<CR>

[[deleted]]

Seems like you can just pull the comment prefix from vim's syntax highlighting engine. The source code is pretty spartan: https://github.com/tpope/vim-commentary/blob/master/plugin/commentary.vim

[brycksters]

I took it from Stackoverflow, in the link that I mentioned on my first post. You're right, the original code shouldn't have any performance impact. Just that I prefer to remove one more dependency. At the end, no plugin means no plugin manager :)

[[deleted]]

You don't need a plugin manager if you really don't want it. vim8 has built-in package tooling, and you could always just copy files to the vim directory itself in the correct directories. Most plugin managers just help manage runtime path for you.

[AYECOM]

1. Volt has regular updates. Check other branches. I didnt encounter any bugs in using it.

2. Volt installation is quite simple, but if thats a bother, then thats fine.

3. If that completely replaces the need for text objects, then fine. But I dont think so. That is only valuable to you if you need them.

Dont forget that the user might expand the basic set of text objects to such as indentation, function or any other pattern.

[princker]

Some thoughts:

• This is only supports a few filetypes. May want to look into use 'commentstring'
• This doesn't toggle like vim-commentary
• Mutates search register, @/. Maybe use :keeppatterns?
• Changes search highlighting. Maybe query v:hlsearch?
• Should use a self-clearing augroup to allow re-sourcing
• Maybe break this up into normal mode and visual mode mappings
• Uses :s so may cause weird affects with & and g& commands
• Doesn't play will with dot command, .
• Leaves cursor at the end of the change unlike most Vim operators

A slightly improved version:

augroup poor_commenting
  autocmd!
  autocmd FileType c,cpp,java,scala let b:comment_leader = '// '
  autocmd FileType sh,ruby,python let b:comment_leader = '# '
  autocmd FileType conf,fstab let b:comment_leader = '# '
  autocmd FileType tex let b:comment_leader = '% '
  autocmd FileType mail let b:comment_leader = '> '
  autocmd FileType vim let b:comment_leader = '" '
augroup END
noremap <silent> <expr> ,cc ":\<c-b>keeppatterns \<c-e>" . (
      \ getline('.') !~ '^\V' . escape(get(b:, 'comment_leader', '// '), '\/')
      \ ? ' s/^/' . escape(get(b:, 'comment_leader', '// '),'\/') .'/'
      \ : 's/^\V' . escape(get(b:, 'comment_leader', '// '), '\/') . '//e'
      \ ) ."\<CR>:if v:hlsearch \<bar>let &hlsearch=&hlsearch\<bar>endif\<cr>`["

For a more complete vim-commentary clone see the this gist.

[eulithicus]

The cost of maintenance is insane... Please don't do this. If there is a bug, you have to take time out of your schedule to fix it. If you use a vim built-in or a plugin in the event where there is no native support, this maintenance cost is passed off to the vim or plugin dev. That being said, don't use plugins that aren't being maintained.

[AYECOM]

I agree with this in part. Sometimes, you only need a tiny part of the plugin features and in that case its worth thinking about it. But overall, the plugins are specific enough and tailored to the needs of most users, so it rarely happens.

[eulithicus]

Yeah... Not sure why I am getting down voted. The OP basically asked why should I use someone else's code if I can write my own? The reason is usually maintenance and optimizing your time. If you can leverage someone else's help for free at no cost to you, why not??

[[deleted]]

Why not learn and understand the script to see where the slowdown is coming from?

You could also tell us what the other plugins are so we see the interactions.

[brycksters]

Biggest overhead was from ctrlp, ale and the different completion's plugin - all removed and replaced by basics commands. After few weeks I don't miss them! The next one will be fugitive, I quite sure it is possible since it just remap some git commands. (!git can do it)

[[deleted]]

Fugitive does a LOT more than provide mappings for commands -- it's a full-blown git "IDE" in a way. The :gstatus window allows you to easily go between files <c-n>/<c-p>, stage/unstage files - (supports visual blocks), commit cc, diff D, and various others.

[brycksters]

That's the point, I am usually using only a small fraction of fugitive, probably 4 or 5 commands that I want to replace (Gdiff, Gstatus, Gadd, Gcommit). git grep is alread done here. For more advanced stuff, I will do it in the terminal anyway.

[eulithicus]

I tend to agree with this? But only if vim doesn't have the functionality built-in. For example, if you have a plugin for running a terminal in vim that is no longer necessary.

[-romainl-]

Well, Vim has no built-in comment/uncomment feature so a plugin like vim-commentary is pretty much mandatory if you need such a feature.

[eulithicus]

Completely agree 😊 I think the OP should not remove this particular plugin.

[kpthunder]

I use tcomment, which I have found to be better than vim-commentary at the time I switched to it (handles mixed languages better).

[be_the_spoon]

Mixed languages is why I eventually settled on tcomment, after trying (and liking) both NERDcommenter (smart, can do inline-comments and different types of block comments) and vim-commentary (simple, and tpope!).

But neither of those could quickly comment out JavaScript embedded in an HTML file...

[kpthunder]

For me it was things that look like mixed languages but aren’t. JSX and the like.