Hacker News Reader

Comment by a-b | Hacker News Reader

Vim is great, but hard out of box. That's why I'd like to mention couple community distributions to make it even better:

• http://vim.spf13.com this distribution is remarkable! Extremely well documented vimrc file is a great source of knowlege by itself https://github.com/spf13/spf13-vim/blob/3.0/.vimrc

• https://github.com/carlhuda/janus

Also, it worth to mention

http://spacemacs.org

and

https://neovim.io

View on HN

I would recommend against starting with someone else's pimped out configs and go with something more conservative. Tim Pope's sensible.vim is a good starting point. It has "sensible defaults" but no opinionated keyboard configs, extra plugins or so.

https://github.com/tpope/vim-sensible

That's pretty much all I have, plus a few personal shortcut keys and some syntax highlights that aren't included in vanilla vim.

It's pretty short, I recommend copying it to your .vimrc, understanding every line (:help) and modifying to taste.

Vim-sensible is the first, and sometimes only, vim plugin I use. It is small, takes care of most of the stuff I had in my personal .vimrc file and works across all of the systems I am on. I used to just load up vim with tons of plugins until I realized I used about 5% total of everything I was loading in.

These days it's vim-sensible,vim-go, syntastic and the base16 themes.

For me it's a matter of mental overhead. When I used to tweak every little setting and install a plugin for everything, it was so much work, for, and let us be realistic, very little gain in the long run. Now I usually run defaults with some bare essential tweaks that is obvious improvement on my "quality of life" - and if I cannot automate the setup it needs to be required or I'm not doing it - that is it.

I understand why someone would want to start with a prefilled vimrc, but I really can't stress enough how useful writing your own vimrc is. I started with bits and pieces from everywhere on the internet, but one day, I sat down and wrote my own vimrc. I realized I didn't even know 1/2^32th of the things that were possible with vim!

That's very true. On other hand based on my experience from San Francisco Vim meetup many beginners give up because of a steep vim learning curve at the beginning.

It's better to start from something that already solves code editing problems and then customize it or even rewrite rc from scratch.

I used to customize vim quite a bit, but I got tired of trying to sync my config across multiple systems, some behind corporate firewalls.

I run into this with TMUX too. It's a pain when you are used to your specific config to the point that it's hard to use the default config.

I got into emacs when I started lisping, but vastly prefer vim's keyboarding and macros. So when spacemacs came about, I jumped on board and love it. The power of emacs and the sense of vim.

Plus, I don't have to customize spacemacs aside from enabling modules I want... very easy to do. Very easy to keep in sync across multiple machines.

If `git pull` works, I recommend just putting all your dotfiles in a git repository. If `git pull` doesn't work, then you've got Problems.

Or you know, you're ssh'd into a machine, that other developers use, too; has specific networking requirements, etc..

Yep. I spend all day connected to machines that I have to access through a jump server because they have no direct internet access in or out themselves. No way is it worth it for me to customize anything there.

I realize that this is a pretty rare situation though.

I find TRAMP (https://www.emacswiki.org/emacs/TrampMode) invaluable in these situations. It lets you run shells/edit files on remote machines from within your local Emacs. There are a few quirks that you need to get used to, but it makes Emacs + a bunch of regular Linux boxes into something that feels very Plan-9-y.

In your case, you would want to look into the multihop settings that will let you open files and eshells on remote machines, but use an intermediate machine (your jump boxes) to get there.

For shared accounts, it's really annoying if others mess with settings. For that reason, I use the following piece of shell code that I put in .bashrc. Explanation: you configure the MYMACHINE variable as the IP address you usually come from.

  # If we're logging in through SSH, write this down
  if [ -n "$SSH_CLIENT" ]; then
    # Alternative settings
    MYMACHINE="172.16.140.14"
    FROM=`echo $SSH_CLIENT | cut -f1 -d" "`
    case $FROM in
      *$MYMACHINE)
        export TMOUT=180 #Logout after 3 minutes
        set -o vi
        # all sorts of other settings
      ;;
    esac
  fi

>I used to customize vim quite a bit, but I got tired of trying to sync my config across multiple systems, some behind corporate firewalls.

Mine is on github. https://github.com/milesrout/.vim

I can operate without it, though. The only thing is that I always have swap : and ;.

I highly, highly recommend people write their own vimrc from the ground up and add plugins as necessary.

That option doesn't make a lot of sense when it's as difficult as it is to know what options can be cusatomized, and in what ways.

I agree that things should be gradual, but having a commented config that people can reference and say "Oh, that sounds super useful actually" seems like a good thing to me.

I switched to NeoVim last year and couldn't be happier. It's stable, everything works, it has nice defaults and it gets updated all the time.

I switched because there were several bugs in Vim that drove me nuts and they weren't being fixed by the Vim team. One person suggested NeoVim and to my delight, these bugs were not present in NeoVim. I immediately donated $20 to the NeoVim team because I was so happy.

What are the bugs?

After using vim for many years with a basic .vimrc, I pulled in spf13, and wow, how little I knew!

I know many suggest learning vim from the ground up, but I'd say there's benefit to learning from the top down as well. Stripping spf13 down to the bits I'm interested in was an incredible learning experience.

For servers I still roll with pretty minimal configurations, but for local dev quite happy with an spf13 based .vimrc

No, Vim is not "hard" at all.

Vim is "complex", though, and it requires investment, just like any professional tool. One would be a moron to think he can master Photoshop, Fontlab, or Pro Tools in a week and one would be a moron to think one of those crappy distributions will make him master Vim in a week.

If you don't want to invest in Vim just use something else.

Yeah. I'm always baffled by these programmers complaining about the learning curve of vim or Git. Guess what, good tools are complex and you'll have to learn to use them and practice using them in any profession.

I wrote a minimalist vim config with install scripts based on spf13. I wrote it for myself, so I just took out a lot of unneeded options and tried to keep the scripts lean. I encourage people to check it out, clone it, make it their own.

https://github.com/monological/zvim

I really prefer the VSCode approach here of editing the config file in a split window with one pane of all options with their default settings and a description of what they do, and a config file which can override those defaults.

neovim also has interesting discussion on default settings

https://github.com/neovim/neovim/issues/2676

It's not 'hard'. It's 'sparse'.

There is a learning curve with any tool.

Reply on news.ycombinator.com