Hacker News Reader

Comment by exDM69 | Hacker News Reader

My advice: don't go wild with plugins or vimrc hacks. Get sensible.vim for sensible defaults and work with that. Vanilla vim is good enough for most editing and coding needs.

View on HN

In the well over 20 years I've used vim, I've always just installed and used whatever plugins I liked.

Occasionally there were conflicts or problems caused by plugins, and then I just troubleshot those and uninstalled or disabled plugins until I found the culprit. No big deal.

Whenever I use another computer that just has vanilla vim installed, without my own .vimrc on hand, I just touch ~/.vimrc and away I go. I just try not to spend too much time on such systems before loading up my own .vimrc. Again, not a big deal.

I really don't get people who deliberately cripple themselves by using fewer plugins or features than were maximally useful.

On the other hand, I was never a big fan of giant plugins that make a lot of choices for you. I like to make my own choices as much as possible, and know why and how these choices are made. So the plugins I install tend to be very specific plugins that are good at one particular thing that I feel vanilla vim is lacking.

I like the fact that my vimrc is easy to deploy on new machines without having to hassle with plugins.

At one point in the past, I did have a bunch of plugins (nerdtree, fugitive, surround, nerdcommenter, etc, etc) but they weren't that great (I guess because vim's scripting facilities and UI isn't optimal for writing complex IDE-like features) and were always conflicting or otherwise a hassle.

These days I get by with vanilla vim with a conservative vimrc and I don't consider my productivity crippled. The only plugins I miss are surround.vim and a commenting plugin.

If you like to try any plugins, sure go ahead but I don't think it's a good idea for someone new to vim.

What do you use instead of fugitive?

git on the commandline together with tig.

While I read this thread, I actually noticed that I use only a single feature out of vim-fugitive, which is the :Gw command. So I replaced vim-fugitive by https://github.com/majewsky/devenv/blob/master/vim/plugin/mi... just now.

For someone new to vim, I agree. They should really get used to vanilla vim before moving on to using fancy plugins. But once you have a good grasp of vanilla vim, I don't think there's any good reason to avoid plugins.

When I install my own .vimrc on another computer, I just copy my whole ~/.vim directory over with it, and that's really all it takes to migrate. Easy.

As for plugin conflicts, I've found them to be pretty rare, and when they happen they've been easy enough to troubleshoot and then I just disable the incompatible plugin, if I can't find some other fix. The occasional incompatible plugin is no reason to avoid plugins as a whole.

> The only plugins I miss are surround.vim and a commenting plugin.

Incidentally, surround.vim and commentary.vim are also why I wouldn't want to live without plugins. Everything else is expendable.

Any idea why a surround feature isn't in vanilla Vim? It seems to follow the Vim philosophy, i.e. enacted with a command that has action and movement components.

For coding, I would really suggest using the NERDtree plugin [1] (after getting a basic hang of vim modes)

[1] http://www.vim.org/scripts/script.php?script_id=1658

I had it at one point and it was decent (but not great), but I no longer use it.

I always prefer using tags files to do code navigation instead of browsing files. With `:set wildmenu` (enabled in sensible.vim), using `:tabnew :edit :split` etc from command mode is also quite nice. For browsing, the default netrw is decent or I use ranger in another window.

What I could really use is a fuzzy finding plugin, I've heard Ctrl-P is nice but I haven't tried it.

This is great advice for beginners, but as you get more advanced and comfortable with vim, it's OK to let your custom configuration grow organically. Once you've mastered vim you'll be fine on non-customized version running on a server.

I've always added a line to my .vimrc file that would source the vimrc_example file included in the vim distribution. I have maybe 5 more lines in there with some additional settings (colorscheme, ls=2, etc).

I wouldn't quite say this - the comforts that plugins bring can be quite useful, even if I only use them once in a blue moon - but definitely have some idea of what the bare minimum you want in a .vimrc is.

My retort. Install YouCompleteMe because if you don't have high quality auto-complete your editor will feel rubbish compared to an IDE and you will end up moving.

Is autocomplete really necessary though?

YES. Oh GOD yes.

Some of the worst D'oh moments I've had came from before I added tab completion to my .vimrc, because it almost completely eliminated errors that my typos introduced.

Do you have any suggestions about how it may not be, or are you just pondering the idea? I really want there to be something that has the benefits without the Intellisense-level overhead, I haven't seen it though.

I find autocomplete annoying.

I also suspect autocomplete to be the leading cause of a particular set of subtle bugs - ones where the words on the page seem right but the function chosen has a surprising and uncatered for side affect.

When you reinforce to people that it is OK to code blindly ahead, grasping for the right calls at the last second you will end up with poorer quality code (although, it may be typed faster).

There are always tradeoffs but for me, I feel like lack of autocomplete encourages people to use shorter less descriptive names for identifiers.

I am a believer in using as descriptive identifiers as possible to make the semantics of your code as clear as possible. If this gives rise to 5-word+ identifiers, so be it, providing it is done tastefully (and not for verbosity's sake).

As typing 10+ characters per function call/variable call can get tiring, lack of autocomplete can leads incentivizes the use of shorter names which runs counter to this philosophy, and leads to code being harder to read. (IMHO)

It really depends on what you're working on. Huge code bases, weird APIs (for instance the raw Windows API), verbose languages may need an IDE to be manageable.

You can also use vim with an IDE, e.g. IntelliJ IDEA. So you get the best of both worlds. :-)

As someone who uses IntelliJ at the moment, this is an interesting thought to me. What would your workflow look like? In-IDE terminal + Vim for code editing and the rest of the IDE for refactoring, running code, etc.?

Or did you mean use Vim bindings in IntelliJ?

Using vi key bindings is the easiest way to use IntelliJ, IMO. That's how I use my PyCharm and it's amazing. You can even tell your IDE to use your .vimrc.

Vim comes with autocomplete (omnicomplete) built in. It's just bound to a rather nasty key combination, and works mostly with text on the page and values in the tags files.

This isn't always enough for folks, who fall back to YCM or others.

I am well aware that vim comes with a crude autocomplete built in. It is just not anywhere near the same class of usefulness as IDEs' autocompeltes - YCM is. Hence just bite the bullet and install YCM or you will end up moving to an IDE in the end anyway.

Agree with this. I regularly have to jump onto other colleagues' machines and edit code. So I try to stay as close to vanilla key bindings as possible.

Reply on news.ycombinator.com