Hacker News Reader

Comment by ogre_codes | Hacker News Reader

> My vim config is 600 lines. I have fixes for small annoyances. I have a bookmarking system set up in 45 lines. I have extra syntax highlighting for code snippets that are important to me because I’m doing things the original syntax maintainers never even considered. I create impromptu keyboard mappings and abbreviations and autocommands as needed for given tasks. I can move around in the design space at will.

I use VIM on and off, but I wanted to post the above because I think it exemplifies who might like using VIM.

VIM is ideal for people who find it worthwhile to spend the time building their configuration out. VIM is the productivity tool that gets better as you put the time and effort into building it out. If you aren't the kind of person who wants to put that time and effort in, it is still decent as a basic editor, but it doesn't really shine.

View on HN

I don't disagree with your thesis, but I should point out that I have been using Vim almost exclusively for almost six years now (well, NeoVim for 4 of those years), and my config is only about 40 lines, and most of it is just installing plugins for whatever languages I'm using.

Despite me not hacking it like crazy, I still think it really shines as an editor; Vim macros were sort of life-changing to me once they clicked for me. I also just think that modal editing is superior once you get past the initial learning curve.

Let me back up a step here.

I use VIM for almost all basic editing. Its muscle memory.

But for code editing, I generally end up on VSCode because it seems to have better language support. I've spent a fair amount of time with configuring VIM trying to get where I feel it needs to be. But whenever I shift to a new stack, it always seems to take an investment of time and effort to get VIM set where it's better than VSCode.

I share your experience, but it should only be a matter of time until the vim LSP clients[1] mature.

One notable exception is Go with its [vim-go](https://github.com/fatih/vim-go) plugin, which feels very mature to me as someone new to the language.

[1]: https://langserver.org/

CoC is already there:

https://github.com/neoclide/coc.nvim

Having to install node.js for a language server client is sort of a downer. For this reason I've been eagerly awaiting the built-in client in neovim, though it's definitely less polished and feature-complete than CoC today.

Isn't the "built in" neovim language server lua? I personally can't see much difference between having to install nodejs runtime Vs the lua runtime.

The difference is that the lua runtime is embedded (and wicked fast) into Neovim vs nodejs that has to go over the remote plugin interface

Fair enough. I've been using coc for a while now and can't say I've ever had any speed issues that I've noticed. But if the neocvm language server is built in and "as good" as CoC then that'll be one less plugin I'll need to install when it's ready.

Yeah I don't have any node.js speed concerns for it, I just would like to have the simplest editor microservice architecture, and putting the client to a service in a service was a bridge further than I wanted.

CoC looks neat (installing right now), but it's a perfect example of what I mean. Having to poke through and add several dozen lines to my config file to get it working.

I would love to have this functionality with just

  brew install ts-vim

And just be done with it.

I don't use vscode that much, but when I was checking it out I installed some extension which lets you edit text with true neovim (point it to a bianry) while vscode handles chrome and code understanding. Worked pretty well.

You're probably talking about Neo Vim[1] by Alexey Svetliakov. I can't recommend this one enough for a (neo)vim experience in VS Code. It is relatively new and deserves a lot more attention.

[1]: https://marketplace.visualstudio.com/items?itemName=asvetlia...

Yeah that’s the one. Love that it’s not a half baked vim emulation.

There are many ways to use vim and they're all valid! People who love barebones vim are cool. People who love configuring vim are cool. People who love embedding vim in larger programs are cool. We have way more in common than vim squabblers pretend!

Are evil users cool too?

BTW, your main point about using vim is emacs greatest strength.

You wound me greatly, but yes, evil users are cool too. I mean, I first learned vim keybindings from Kile.

(People keep telling me I'd love emacs, and I have nothing against it, I just happened to learn vim first.)

Along with Evil, Emacs org-mode is the thing that eventually lures a number of people like you over from Vim. Evil makes editing in Emacs close enough (very close) to editing in Vim. Org-mode gives useful functionality that you can't get in Vim.

So, I am now a longtime emacs (and evil, love vim-ey things) user, and I've dipped my toes in the org-mode water a few times, but it's never quite stuck.

Have you got any suggestions? The number of people that recommend it makes me sure that there's value to be had there, but it's never really become a habit for me.

The important part is to find a method and then leverage orgmode for it. With out some system is hard to make it stick.

About 40 lines sounds reasonable to me.

I've been using vim and before that other vi clones or actual vi as one of my main editors for 40 years, and my .vimrc is 60 lines.

20 of those are to automatically decrypt on read and encrypt on write .gpg or .asc files, which I copied from somewhere 20-25 years ago and haven't actually used in 15+ years, leaving only 40 lines I actually care about.

Just as an FYI, Vim has built-in support for encryption: https://vim.fandom.com/wiki/Encryption

My problem is that some of that building should've been sensible defaults, and the community tends to outsource those responsibilities to extensions.

Which means your Vim experience now has some risk of rot. Once and awhile my configurations/extensions rot and I have to go and update myself as to what happened in the ecosystem, or what is interacting with what. One day I decided I'm too tired and switched to VSC.

Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.

Thankfully, you can get LSP-powered completion with coc.nvim, just like in VSC. It's miles better than YouCompleteMe, plus it's much easier to install—you can just use vim-plug or similar to install it.

LSP is truly one of those "rising tide lifting all boats" projects.

[0] https://github.com/neoclide/coc.nvim

I was using YCM and ALE to handle completion, but having switched to COC I won't look back. It's just a much better experience.

FWIW, neovim's built-in LSP (nvim-lspconfig -- written in Lua, currently in beta) is _outstanding_ and I have already replaced coc.nvim with it in my neovim set up. Set up is super simple, there are 2 extensions to install. Configuration is simple, I think I needed maybe 8 lines added to my `init.vim`. With that I get completion and in-line diagnostics and it's very, very fast, at least with solargraph, clangd, and tsserver.

> My problem is that some of that building should've been sensible defaults

Vim suffers a bit from the design equivalent of tech debt. Much of the defaults and common behaviors were created based on the limits of software/ hardware 30+ years ago. Those limits still affect current design.

> Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.

Given a fairly small amount of configuration, you can get autocomplete which is nearly as good as Intellisense in VSCode. For Typescript anyhow, the autocompletion comes from the same source background process.

Agreed (though I use nvim now and thoroughly recommend it)

Vimscript is weird. Sometimes the answer to "how to do this" comes in the form of "just install this package manager...". Stop. No.

Sure, I'm ok with adding a couple of lines to vimrc, copying some files, but don't push it.

I get much more out of the box from Vscode, PyCharm, etc. Why can't it be the same with vim?

Simple. Vim is not an IDE.

If you take a step back and look at software development as a whole then IDEs like VSCode and PyCharm take the top down approach.

Whereas Vim is one of the solutions which do it bottom up.

With both approaches you can theoretically arrive at the same functionality but in reality, there will always be something missing.

Some people prefer the bottom up approach as that gives them the illusion of knowing their tool completely whereas people with the top down preference think everything is curated for them.

Over time, both kinds of people notice this isn't quite true.

This is one of the motivating forces behind nvim. While nvim supports vim script, it provides Lua as its preferred language for extension. In addition, the internal APIs are documented and are intended to be accessible from any language via RPC.

https://neovim.io/doc/user/api.html

drawing from my own experience, i once found myself trying to work on a client website. thanks to a series of events i was using termux from a cellphone. i grabbed my vimrc from my dotfiles git repo and that was that. took all of 30 seconds to turn someone's cellphone into an interface identical to the one i use everywhere else

My .vimrc is around 80 lines including 15 plugins. It's mostly like that for last 8 years. And i don't have any problem using using unmodified vi/vim on servers, which is a big plus.

So no, vim shines and it's pretty bright

My vim config is empty. I use it periodically and know the basics. I prefer it over nano and pico by a mile.

600 lines seems pretty long to me. I don't even know what I would put in a .vimrc file. Obviously I don't use it enough to even have annoyances.

The nice thing about have no config is that I can hop into vim on any computer or server anywhere and be able to use the editor. I don't have to worry about having muscle memory of using keybindings/aliases that don't exist.

> My vim config is empty.

That's the way to go. Unfortunately, most humans are fallible and I had to add a single line:

    inoremap <tab> <esc>

Mine is 3 lines. Background dark, shift width and tab spaces. Been like that for around 18 years.

I should probably add that. I know I have had it at some point on a different computer.

Mine was empty until the defaults changed in vim 8 and broke a lot of sensible behaviour.

as much as I enjoy my current job, I really want to learn new programming language/paradigm, or new skills to let me have a job with vanilla Vim without vimrc as my daily driver.

VIM is fantastic for editing files on servers for this reason.

mine is empty because i jump between so many different machines and my config is not there. so i have to remember them.

While I understand why you may want an empty config, at the same time, I don't get it. It's not a criticism.

I knew a guy that not only had no config, he didn't even use syntax highlighting, which I can't live without.

All of that power and configurability is there for a reason. My config is about 250 lines; a lot of that is just to have Vim operate like it's 2020 and not the 90's.

I'm not a C programmer, so I don't want /usr/include in my search path, which it is by default.

I want to ignore things I have no intention to edit, so I have

    set wildignore=*~,.DS_Store,.git,.hg,.svn,*.bmp,*.gif,*.gz,*.ico,*.jpeg,*.jpg,*.mp4,*.pdf,*.png,*.tar,*.webp,*.xz

Gotta have relative numbering while showing the absolute number for the current line:

    set number
    set relativenumber

I write a lot of HTML; having Emmet (see https://medium.com/vim-drops/be-a-html-ninja-with-emmet-for-...) enables me to write

     div#page>div.logo+ul#navigation>li*5>a <C-y>,

and get

   <div id="page">
        <div class="logo"></div>
        <ul id="navigation">
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
        </ul>
    </div>

Saves lots of time and keystrokes.

From .vimrc to .vim: https://vimways.org/2018/from-vimrc-to-vim/

Fabulous article that explains runtime files and why many modifications to most people's .vimrc should be in ~/.vim/.vimrc and other other runtime directories.

Lots of Vim users talk about using a minimal config because they need to access random machines that won't have their custom setup.

Or that it's some kind of badge of honor to not have any plugins, even if they could save you a ton of time and keystrokes.

Let's not forget: 1. Vim is great at remote editing, so you can use your config when updating files on servers, etc.

2. You could put your ~/.vim/.vimrc in a repo and install it anywhere you need it in like 5 minutes.

3. You could also rsync your local config to a machine if you needed to.

Of course I can use barebones Vim on some random server, but sometimes you need all the goodies with you.

The video Your Vim is only for you: (https://www.youtube.com/watch?v=6LPBpmkQdw8) reminds us that our Vim is just for us and if that means tricking it out so that it becomes our own custom editor, then so be it.

> VIM is ideal for people who find it worthwhile to spend the time building their configuration out.

I've been using VIM for over a decade and currently my customized config consists of a half a dozen tweaks, such as YAML-specific settings stashed in ./.vim/after.

If you can post it on a public repo, I'd love to see it. (same goes for the many others who use VIM as a daily driver)

Reply on news.ycombinator.com