Hacker News Reader

Comment by baby_wipe | Hacker News Reader

I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.

View on HN

It depends what you use Vim for. If Vim is your only code editor, it’s crazy that you’d leave tons of productivity enhancements on the table because you want that standardized, bottom-of-the-barrel experience. Nice things are nice!

I have tons of customizations in my Vim, and have very little trouble using vi or vanilla Vim when I log into production machines. It is frustrating to not have my magic this and that, but no less frustrating than it would be going from IntelliJ on my own box to Vim on someone else’s.

I wish I could upvote your comment many times. I wish the parent comment pointed out what use case they have for Vim, as this really dictates the "right" approach.

I wrote about this previously in the context of Vim vs Emacs, though it's similar to customized vimrc/plugins vs vanilla vimrc:

"One can reduce part of the [editor] debate down to a single question: how fully featured do you want your text editor out of the box? If you’re a DevOps engineer who spins up new environments constantly you’ll have different ideas about the best choice compared to a full stack engineer working in a single development environment that can be painstakingly setup. For the DevOps engineer, a light text editor that is installed by default is likely ideal, while for a developer with a single computer, a full-featured IDE (auto-completion, plug-ins, custom keys) is worth the high setup cost."

https://www.nemil.com/musings/betterdebates.html

> it’s crazy that you’d leave tons of productivity enhancements on the table because you want that standardized, bottom-of-the-barrel experience

Like what exactly and compared to what environment?

Same. I spend most of my time in a terminal and SSH into various boxes daily. I do customize my standard Unix toolset, but avoid plugins and non-standard configs that increase cognitive burden. It's very liberating to feel comfortable with shitty defaults. If you feel at home with the defaults, you feel at home anywhere.

You can remotely edit on any system accessible over ssh thanks to netrw:

    vim scp://some-remote-box/some/path

You can jump to a directory listing by including a trailing /

   :help netrw

Emacs has Tramp, and you can do the same thing!

Is there a way to combine this with sudo, to edit root's files remotely? Apparently tramp is supposed to support this, but I prefer vim.

> You can remotely edit on any system accessible over ssh thanks to netrw:

Yeah, and either lose all the goods of path completion or gain atrocious lag on each tab. Because of that, I rarely use netrw.

Most people store their dot files (including their vim config) in a git repo and just check out a copy on any machine they use. That's what I do (git+stow). I can be up and running on a new system in just a few seconds.

Does anybody know a saner way of doing this cross-platform? I've resorted to doing platform checks in my .bashrc and don't get me started on the OSX / Linux differences in .platform, .bash_platform, and .bashrc sourcing.

And when I tried termux on Android, oh dear lord. The whole thing breaks because of permissions issues. Had that issue on WSL too.

https://github.com/007/dotfiles

Lowest-common-denominator for linux and mac, mostly just "make it work if you notice it's broken". I have one file that's bash magic, and link it to everywhere it might be needed - bashrc, bash profile, etc. It's kind of monolithic, not great but at least 100% consistent for what ends up where, and avoids sourcing external stuff or requiring N different files to work. You'll see some of your pain in the repo history, change X to Y to make it osx or *nix compatible based on whichever is my primary platform.

Same goes for vim, just absolute basics for vimrc and a few very portable plugins and niceties hardwired. No package manager, just a bare directory.

> I've resorted to doing platform checks in my .bashrc

This is what I do, too. Most of mine is portable, but I have a block in bashrc that branches on uname.

I use vimswitch (http://vimswitch.org) to copy my vim settings over to new machines.

(Disclaimer: I am the author of vimswitch)

Across linux and OS X, I use a solution based on the this HN comment and it's follow-up discussion: https://news.ycombinator.com/item?id=11071754

Lot of other suggestions on the same HN thread: https://news.ycombinator.com/item?id=11070797

I was a heavy customizer and used it with all sorts of plugins, but maintaining it across computers with little incompatibilities between OS's and version just got to be too much. I finally came around to the tmux side and now use vim as the editor and unix as the IDE. Going to give kakoune another shot in the new year as well.

Right there with you. While the power of vim is to be able to customize it, I hate getting used to something and then not being able to use it everywhere. I've managed to get by with no extra .vimrc things whatsoever for quite some time :D Does it take me longer to do some things compared to using what's in this article? Yup. Does it prevent me from doing good, and still relatively quick, work? Nope.

When I want the power of formatting and and all the goods, I use visual editors with no shame or remorse (VS Code is my current poison of choice).

Just chiming in real fast that you can use ssh to edit files on remote systems even if they don't have emacs themselves via /user@host:~/filename.txt

So I also can use emacs almost anywhere. (I still advocate users and admins at least be functional in vi/vim regardless). Also don't forget GNU Nano isn't out of the game either as a small almost everywhere easy to use editor.

I used to have this mindset, but now that I've got all my dot files on github I can get a machine set up pretty quickly. And for those times where I'm SSHing into a machine for whatever reason, using plain old vi hasn't been a problem. I typically do avoid overriding any of the main key bindings though so that I don't get confused when I do have to use plain vanilla vi.

Leverage your tools. Don’t let them leverage you.

Reduce the friction of importing your vim config non-destructively and on demand.

My vim is pretty customized but I can't say I have any trouble personally with vims that aren't mine.

I agree with this, I use plain GVim on all my machines. I'm not interested in plugins that will slow it down - it's fine the way it is.

Reply on news.ycombinator.com