Live data from Hacker News

A Good Vimrc (2014)

dougblack.io

11–20 of 56 posts

Re: A Good Vimrc (2014)

#11
post #7

Good write up. Ive been looking into Now this might sound like heresy but I've been considering moving to emacs lately and using evil mode. The thing that gets me is vim's lack for auto completion for stuff like scala. Has anyone managed to set that up?

I'm in the same place right now.

Did the emacs fundamentals tutorial. Installed evil. Got a little frustrated when some things didn't work exactly as expected. Also there is a weird TLS bug with the melpa and marmalade repos and the packaged emacs that debian stable offers. If I need to compile something then Neovim starts looking more attractive (I'm not aware of any package for debian stable atm but am happy to be corrected).

Now I'm just looking to try to solve my problems in vim again :)

Re: A Good Vimrc (2014)

#13
post #3

Now just add the section about uploading it to your GitHub so all new servers get setup with a simple git clone, and any new changes can be propogated around with push/pull.

For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just: git clone https://github.com/me/my-dotfile-repo cd my-dotfile-repo stow --target=$HOME zsh stow --target=$HOME vim ... Elegant, cross-platform, easy to remember. [0]: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

Sorry if this is a super naive/dumb question, but why wouldn't I simply write a "build" script that copies files out of my dotfile repo to where they're supposed to go?

Re: A Good Vimrc (2014)

#14
I wonder why text editor preferences are so personal. I use the same editor and probably 90% of the same config as this guy and was nodding along until I saw he remapped B and E. Horrifying! Those are fundamental motions.

Re: A Good Vimrc (2014)

#15
post #13
post #3

Earlier quoted context omitted.

For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just: git clone https://github.com/me/my-dotfile-repo cd my-dotfile-repo stow --target=$HOME zsh stow --target=$HOME vim ... Elegant, cross-platform, easy to remember. [0]: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

Sorry if this is a super naive/dumb question, but why wouldn't I simply write a "build" script that copies files out of my dotfile repo to where they're supposed to go?

1) It's cumbersome, and you'll need to specially handle things like deleting files. I personally wouldn't be comfortable having a homebaked script rm stuff in my home directory.

2) By using copies instead of symlinks you'll need to run your script Everytime you make changes and be careful to edit only your clone instead of the target location.

Re: A Good Vimrc (2014)

#16
post #13
post #3

Earlier quoted context omitted.

For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just: git clone https://github.com/me/my-dotfile-repo cd my-dotfile-repo stow --target=$HOME zsh stow --target=$HOME vim ... Elegant, cross-platform, easy to remember. [0]: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

Sorry if this is a super naive/dumb question, but why wouldn't I simply write a "build" script that copies files out of my dotfile repo to where they're supposed to go?

The copies get out of sync, if you edit ~/.vimrc instead of ~/projects/dotfiles/vimrc you will have a hard time keeping all of your systems in sync.

Replace copies with links and you are golden. Yeah, you can write a simple script to create those links for you, but Stow seems pretty full featured.

Re: A Good Vimrc (2014)

#17
post #3

Now just add the section about uploading it to your GitHub so all new servers get setup with a simple git clone, and any new changes can be propogated around with push/pull.

For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just: git clone https://github.com/me/my-dotfile-repo cd my-dotfile-repo stow --target=$HOME zsh stow --target=$HOME vim ... Elegant, cross-platform, easy to remember. [0]: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

I switched over to Stow last time I set up a new machine and now regret not having discovered it long ago. It always amazes me how for basically any problem you might have there's probably a GNU project to resolve it.

Re: A Good Vimrc (2014)

#18
post #11
post #7

Good write up. Ive been looking into Now this might sound like heresy but I've been considering moving to emacs lately and using evil mode. The thing that gets me is vim's lack for auto completion for stuff like scala. Has anyone managed to set that up?

I'm in the same place right now. Did the emacs fundamentals tutorial. Installed evil. Got a little frustrated when some things didn't work exactly as expected. Also there is a weird TLS bug with the melpa and marmalade repos and the packaged emacs that debian stable offers. If I need to compile something then Neovim starts looking more attractive (I'm not aware of any package for debian stable atm but am happy to be…

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

There are packages for Jessie at the very least.

Re: A Good Vimrc (2014)

#19
post #6

> Don't put any lines in your vimrc that you don't understand. Actually true for most human-configurable setting files.

I sort of disagree with this and think one should extend in the opposite direction- to keep sharp, have an RNN generate some plausible config options / shell commands, and append them to the bottom of your vimrc / bashrc on startup. This results in sort of like a 'chaos monkey' of coding, to prepare you for when real emergencies pop up.

Huh? The point of a Chaos Monkey is to simulate failures that might happen in real life. How does this do so?

Re: A Good Vimrc (2014)

#20
post #6

Earlier quoted context omitted.

I sort of disagree with this and think one should extend in the opposite direction- to keep sharp, have an RNN generate some plausible config options / shell commands, and append them to the bottom of your vimrc / bashrc on startup. This results in sort of like a 'chaos monkey' of coding, to prepare you for when real emergencies pop up.

Huh? The point of a Chaos Monkey is to simulate failures that might happen in real life. How does this do so?

Don't tell me you've never accidentally rm -rf'd something important
Post reply on HN