Coming Home to Vim (2010) | Hacker News Reader

Coming Home to Vim (2010)

stevelosh.com

78 pointsbehnamoh87 comments

I found myself coming home to vim recently, as well—I just now call it [helix](https://helix-editor.com).

Cuteness aside: for all the awesomeness that a tailored vim setup provides, I haven't been able to keep one stable since a decade ago, when I used an ubuntu desktop for work. Maybe I'm just getting old, but Helix's batteries-included approach to reimplementing vim has resulted in a much better experience for me in practice, even though it's lost me some features in theory (I miss you, vim-fugitive!).

And my hands can't even tell it's not vim…mostly!

> And my hands can't even tell it's not vim…mostly!

How? Helix is <noun> → <verb> whereas Vim is <verb> → <noun>. I'm used to deleting entire sentences using `das`, but the order is completely the opposite in Helix.

Legit—`da` and `di` are the ones that trip me up the most.

Edits much simpler than that are often the same keystrokes as vim (`A`, `C`, `.`, `/`, etc), and those much more complicated would have kicked me into visual mode anyway.

And that makes it `sad`

+1 to helix.

I like the idea of using "<motion><verb>" instead of "<verb><motion>".

Though, when I was first trying it out, enough of helix's keybindings conflicted (or were different).. it definitely takes a bit of effort to adjust. (e.g. I like vim's `$` to go to the end of line, but helix uses this for "filter through shell command". Helix uses gh/gs/gl instead of 0/^/$; which is arguably nicer).

Pinning package versions has helped me ensure a completely reproducible environment. I’ve not had any instability.

One possible replacement for vim fugitive is tig. It’s very vim-like and gets the job done.

Helix is not Vim. Helix cursor is bad and they refuse to fix it:

https://github.com/helix-editor/helix/issues/3010

> Helix cursor is bad and they refuse to fix it

What? Our cursor matches the default vim one (always 1-width, always bar). If you want to change cursor shapes, there's a config option too https://github.com/helix-editor/helix/wiki/FAQ#change-cursor...

Incorrigibly pedantic.

I am half thinking of getting back into Vim (or trying again), because:

* The how-to-use and keybindings, while weird, are going to stick around for another 40 years and probably outlive me!

* Support for languages as good as VSCode

* It is fast

* It can load, search and navigate big files (e.g. 1Gb) quite easily, which most non-text editors seem to struggle with (Notepad++, VSCode, etc.)

This is also the reasons I am learning to use tmux, even when using Windows. Just feel it is a good investment, it is nice to use and scriptable.

What puts me off is getting the muscle memory to feel productive!

> Support for languages as good as VSCode

Oh come on now that's can't even be close. Surely vim supports and order of magnitude more languages than vscode at least. I actually haven't found one without vim support yet, including a dozen assembly languages, verilog & vhdl, various horrible proprietary scripting languages and so on.

Does vscode use vim syntax and script files to try and match that or something?

> Does vscode use vim syntax and script files to try and match that or something?

Vs code supports language server protocol [1] and also includes support for syntax highlighting [2]

If I recall correctly, vim supports syntax highlighting through less-than-elegant regex searches.

[1] https://code.visualstudio.com/api/language-extensions/langua...

[2] https://code.visualstudio.com/api/language-extensions/syntax...

Neovim uses the same Language Server Protocol servers as vs code; LSP support is built in.

Treesitter, also built-in to Neovim, provides semantic syntax highlighting, just like an IDE.

And Vim can use LSP using a plug-in like Coc.

The (clearly a bit facetious) question was not "is it possible to implement syntax and script files" but "is VSCode able to read vim's syntax and script files", as the ability to do something isn't equivalent to something already having been done.

Microsoft have made choices for vscode. Maybe even good ones?

What %ge of languages supported by vim are actually supported by microsoft - or "the microsoft community?"

It's a very high percentage for syntax highlighting itself (which is most of Vim's focus) if you include the deep extension library. The primary tokenizer VS Code uses for syntax highlighting is based on the TextMate Grammar format [1], which is a pretty wide industry standard of sorts today. A lot of grammars have already been expressed in TextMate Grammar format at least somewhere. The TextMate Grammar format is conceptually very similar to vim's: it mostly keys off of simple regular expressions to define token boundaries. The biggest difference is that TextMate Grammars are expressed as declarative JSON files and vim syntax grammars are expressed in vimscript. The vast majority of vim syntax grammars are very easily convertible to TextMate, though vimscript is Turing complete and there are some strange ones out there.

Today VS Code also allows for Language Server processes to entirely delegate syntax highlighting as well, if you do need a very custom turing-complete tokenizer. (More accurately, it is included so that Language Servers can share the tokenizer work they are already doing as part of their parsing and processing efforts rather than duplicate that effort in a TextMate Grammar.)

Wrapping a TextMate Grammar in a VS Code extension is one of the easiest types of extension to build for VS Code, it's just the grammar JSON file and a couple lines added to an appropriate package.json file added to a ZIP file that then ostensibly resembles an npm package.

Deeper projects such as Language Servers start to get complicated quickly, but also are where a lot of power that VS Code has that vim is starting to import the other direction: many neovim users rely on Language Servers ostensibly built for VS Code first for an increasing number of language features.

[1] https://code.visualstudio.com/api/language-extensions/syntax...

Neovim (different, sure) supports treesitter so syntax highlighting is no longer “less-than-elegant”.

VSCode has multiple for each of verilog, vhdl, x86, x86_64, llvm. Can't comment on how good they are!

Ada + vim was a mess last time I tried :(

I love vim modal keybindings more than Vim, I don't really use actual vim much at all, certainly not for coding. Luckily most editors / IDEs have Vim support

I can't stand the Vim plugin in VSCode, it is this awful uncanny valley thing. I'd rather just abandon all hope and get it over with.

This was my experience as well. I really tried to use the vim plugin for vscode but there were too many behavior differences between it and native vim. And VSCode just has too many features that I've grown to love that I just find myself learning the native VSCode bindings and using those most of the time now.

I miss VIM, I really do, but I really only use it these days if I need to ad-hoc modify an individual file while I'm in a terminal somewhere.

You can bind VS Code commands to vim-style commands. I have plenty of VS Code specific features bound to leader-based commands

Are you using the plugin backed by Neovim or the other one?

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

I use it but it's typically a source of problems to the point that I have to save everything and restart my session. You can have very, very little custom neovim configuration present. My vimrc checks if it's inside of VSCode and does nothing but I still frequently encounter problems. Weekly, at the very least. I'd love to get outside of VSCode fulltime but where I work today uses Docker for development and it's a complete pain in the ass to connect text editor plugins with services running on a remote host. VSCode has this out of the box, so it wins. My next job, I'll be sure to press for this level of detail about the development experience.

I've heard plenty of people say this and I just don't understand it. I use vim bindings in VS Code 95% of the time but the 5% of the time that I use real vim, it all works exactly the same

How deep have you gone into vim?

Admittedly it's been a while since I tried vscode, but when I did my experience was that vim's functionality is a superset of what's available in the plugin. Especially if you learned on the plugin, vim would generally work the same as vscode.

The issue was the other way--there was functionality missing in the plugin, or sometimes when you tried to compose more complex operations they didn't work or worked strangely, etc.

Like, if you're used to working in C you won't see the advantage of a C++ compiler, but if you've spent 15 years working in C++, you're gonna feel pretty hamstrung by a C compiler.

Can you give me an example of something that doesn't work correctly? I'm not an expert but I'm pretty sure I know all of the movements and basic verbs and they all seem to work fine to me. I believe you that there are missing features but I'm wondering what I'm missing out on

I've got the VSCodeVim extension installed, some other people have mentioned one that is backed by the neovim folks so maybe that one is better.

imap/nmap don't seem to work -- I think I'm an intermediary vim user in the sense that I don't have all the shortcuts memorized. So it can be useful to just throw together a macro to encode an idea like "change the parentheses to brackets around this variable and then go to the next search result."

I'm sure there's a built-in command for this sort of thing but I don't have it memorized, so what I'll sometimes do is just perform the transformation manually once, keep track of which keys I hit, and then nmap that to some random key.

Before, my gripe was that visual mode didn't work, but they added that (yay!).

Are you familiar with vim q macros? It's a similar thing but you don't need to use maps/remaps to use them: q<letter> to start recording and q (in normal mode, so <Esc>q sometimes) to stop recording. Then you can rerun the macro with @<letter> (or @@ is rerun the last macro). (Even fun things like <count>@<letter> work to rerun the macro a number of times.)

VSCodeVim seems to support q-macros just fine. The lone silly missing bit is that VSCodeVim makes it slightly tougher to save/reuse q-macros than proper Vim [1]. In Vim those letters are the exact same "registers" as copy/paste so that you can record a macro to register 'a' with `qa…<Esc>q` and then if you want to save that macro for later you can just paste it into a document somewhere `"a` (paste register a) and pull the macro back in with the right motion and yank to the register you want (`<motion>ya`). VSCodeVim unfortunately uses separate registers for now and it is a bit more work to save/restore q-macros.

[1] https://github.com/VSCodeVim/Vim/issues/1658

I should get used to q macros, they are the right way to do what I like to do.

Unfortunately before hearing about them I mapped qq to 'quit' and I'm afraid the muscle memory is just stuck there now.

When I was a novice first starting vim I was given great advice that I followed for many years: avoid custom mappings. It's tough to learn vim if you confuse its mappings.

When I was an intermediate user of vim for several years I had drastically custom mappings because I thought I knew enough and knew better. I thought I had a good excuse, too: I was using a different keyboard layout and I might as well remap everything.

As an aged user of vim, I can't call myself "advanced" or an "expert" user I don't think, I've returned to the wisdom of the sages: avoid custom mappings. I still need some moderate remappings for my keyboard layout but have come back around to "the less I remap, the better".

You can do equivalent configuration with the extension settings but I can see how not having imap/nmap could be annoying. However, macros work just fine. I use them all the time. Press q and then another letter to start recording a macro for that register. Press q again to stop recording. Then you can type @<letter> to replay the macro

Steve Losh is also the author of Learn Vimscript the Hard Way, one of the best resources for writing Vim plugins.

https://learnvimscriptthehardway.stevelosh.com/

I love Vim. But I have two problems with it:

1. When opening a file that is already open in another editor in another terminal, Vim gives me many options, but it doesn't give me the option to kill the other process (or ask that process to save its buffer and exit).

2. My .vimrc should really follow me around automatically. Too often I find myself installing a new machine and missing my settings. I don't know how it should be implemented, but this is something that should work. Edit: if SSH can pass the DISPLAY variable around, then it could do the same with (a key to) .vimrc. Once a .vimrc is associated with an account, it will stay there, so if I log into the machine from the console, I should have my .vimrc (this also happens to the .Xauthority file, although less useful). This could also apply to other settings, of course. And it would be even better if my Vim binary followed me around too, but this is perhaps too futuristic.

A .vimrc is literally one file, and we've come up with lots of solutions for moving dotfiles around easily. Some jank, some not. But it is a hundred million miles out of scope for vim to implement some kind of sync. That would require accounts, databases, all kinds of tedious details an OSS project does not have the resources or volunteers to do.

Vim can edit files over SSH.

Invoke your local editor and edit the remote file. Additional benefits: no lag or delay in your buffer and editor, and you can save locally should the remote session crash.

(This presumes a direct SSH connection, e.g., no bastion host, though that can be addressed via tunnelled connections.)

an option to have vim use a url for the vimrc?

  git clone https://my-dotfile-repo
  ln my-dotfile-repo/.vimrc ~/.vimrc

Done.

> an option to have vim use a url for the vimrc?

Is copying .vimrc whenever logging in for the first time too much work?

Yes, plus you’d need to update it on all machines on each change.

Computers are perfect automation machines. Why embrace useless toil?

I was thinking that perhaps SSH should do this the way they also pass X11 credentials around.

> But it is a hundred million miles out of scope for vim to implement some kind of sync.

This doesn’t hold true in 2022. People expect their settings to follow them around automatically.

I don't disagree, but some of the great parts about vim are its self-sufficiency and reliability. It's awful when your editor won't open because it's trying to write a log message to a drive that was disconnected or checking for updates but the network is extremely congested.

One could make a command to check some central registry (or, what the hell, maybe a .vimrc blockchain) but typing that command would be about as much work as the curl/wget/git solutions proposed elsewhere.

Not the kind of people who use vim.

This is a tautology. By this logic vim is “done” and should forever remain in stasis.

My .vimrc should really follow me around automatically.

So it’s Vim’s fault because you don’t know how to sync your dotfiles?

Depending on your setup, there many solutions to this problem.

Start here: https://dotfiles.github.io/

Hm. At first I was pretty reluctant about settings "following" users, but a good Vim feature might be built-in syncing to some web service (DAV, S3, git, etc.). Run some function when you start (like fetchsettings) that will query for endpoint, username, password, and boom.

Something like that would be a bit better than what I'm doing now, which is just keeping a dotfiles repo that lives on github. Since password authentication is no longer allowed, and I need certain config stuff in there to stay relatively private, I have to do the public key dance to get started. The one benefit there is allowing diverging changes on different machines, and good control of what you push back to the store.

I just have my .vimrc and plug-ins in a Github repository. I also have a minimal, no plug-ins required version.

Now that I think of it, maybe I should put it on my website so I can curl it onto a server if there is no git available.

You can just curl main.tar.gz which has a predictable url

> When opening a file that is already open in another editor in another terminal, Vim gives me many options, but it doesn't give me the option to kill the other process (or ask that process to save its buffer and exit).

One potential risk with that is that it looks just at PID files, which may or may not be Vim. If you have a left-over swap file from a week ago after a reboot with PID 666, that PID can now be anything (including another unrelated Vim process!) It's actually kind of tricky to implement that reliably.

That said, you can probably implement something like that through the SwapExists autocmd.

Your second point seems more like some system design issue rather than a Vim issue per se. The problem also exists for your zshrc, tmux.conf, htoprc, and lots of other things. I don't think it's something Vim really needs to solve, but rather the system.

Setting up vim (and other shell setups) have been the easiest things ever and this does it for me:

https://github.com/Aperocky/unix-setup

I had to do it several times over the years, even have a shell file that would install all the plugins straight from git. The process take no more than 5 minutes and I'm right at home in the terminal of the new machine.

I’ve setup nix home-manager such that, if I clone my dotfiles repository and setup home.nix (link it into place and make any machine-specific edits necessary), then home-manager will install a predictable version of vim, clone my plugin manager into the right place and symlink my vimrc into the right place. Then, on first launch, all my plugins install themselves and I’m ready to go.

The problem is that whenever you want to do a quick tweak, you have to do a `home-manager switch`, which can take a good 15 seconds or so. It's not the end of the world, but it's a very annoying bit of friction. It's particularly painful if you're trying to quickly test out changes that you're not confident of and iterate. This is compounded by the fact that home-manager currently doesn't work properly with the new flake based profiles (https://github.com/nix-community/home-manager/issues/2848).

Yeah, I don’t have home-manager generate configurations for vim. I have home-manager generate a symlink to my version-controlled vimrc. This way I get the quick setup benefits of home-manager without the slow reload times.

Incidentally, I just polished my script for working around that issue: https://github.com/fiddlerwoaroof/dotfiles/blob/master/scrip...

I’ve found #2 is just not that practical. Too many plugins just aren’t that portable because they depend on underlying binaries (LSP support in Neovim for example).

Maybe minified, portable vimrc but even then, it makes me wonder, why not just copy all your dot files for your user?

I'm not sure what you mean by "automatically" but there's no reason you can't put your configs in a remote git repo and git clone/git pull if you have a new home directory or if you want to update your config, respectively.

for #2, Take your .vimrc. Put it on your personal domain or github or whatever. Make it publicly accessible. Use a unique combination of words in comments so it shows up in the search results for "goobleydook salamander".

Vim supports reading s file over scp. Using your local vim to edit a remote file preserves your settings.

vim scp://user@myserver[:port]//path/to/file.txt

For 2 I use LocalCommand directive in /.ssh/config to copy some files to the remote machine, including .vimrc

Related threads - two different homecomings:

Coming Home to Vim - https://news.ycombinator.com/item?id=4218575 - July 2012 (118 comments)

Coming Home to Vim - https://news.ycombinator.com/item?id=1710702 - Sept 2010 (121 comments)

Coming home to Vim - https://news.ycombinator.com/item?id=1619544 - Aug 2010 (34 comments)

* Coming home to Vim* - https://news.ycombinator.com/item?id=329525 - Oct 2008 (12 comments)

To me, the draw of Vim is the editing paradigm—modal editing, default key bindings, and complex commands.

However, these things can be replicated with Vim emulation. What is the benefit of using Vim proper these days?

> What is the benefit of using Vim proper these days?

Not that much, objectively. Many people enjoy its low resource usage, but most developers use machines perfectly comfortable with VSCode & Jetbrains. There's the startup time, which I don't really see as an issue for other than quick ad hoc file edits. Some people just like to stay in the terminal. It's mostly a matter of individual taste/preference.

The one thing I would point to as a real (if minor) benefit is the UX consistency - since everything is a buffer, keybindings are the same for plugin-enhanced UI elements as they are in regular file buffers. Even though I'm an nvim user, tbh I'd much rather have a true GUI, if they had been better and more consistently designed.

I have used emacs, IntelliJ, VSCode etc in the past (some for lengthy periods). I settled on nvim, not because it's particularly superior (and I'd prefer to ditch the terminal legacy), but just for the sake of settling on one thing I get to know well, and that I'm pretty sure will be around for longer than I will be. I have other things I'd like to spend my attention budget on.

How someone dumped vs code for Neovim: https://dev.to/casonadams/ditch-vscode-for-neovim-25ca

In my experience vim emulation is great, almost as good as using native vim for keybindings, navigation etc but still not so comfortable. Like cuddling someone you love wearing blizzard clothing - better than no cuddle for sure but not the cuddle you'd choose as your favourite.

Depending on what you're doing, the native vim plugins might well be vastly better. I swear by YouCompleteMe as a wrapper for clang-complete for navigation of a C codebase. The autocompletion is pretty good too. I Haven't seen anything better with any other editor/ide vim key bindings or not.

I'm sure if you work hard enough at your s-exepression configs emacs can be as good if those are the keybindings you know and love. But why look elsewhere? <- Not rhetorical, genuine question - have you found a reason?

> But why look elsewhere?

I don't know what I don't know, so that's why I ask. My JetBrains IDE does so much out of the box, I figure people give up all these features for a reason. Beyond vanity and too much free time, of course.

I was an ardent JetBrains user for years, and still enjoy their software. But I transitioned fully to NeoVim and there just isn’t anything I had to give up. It took a little more modification but the initial cost resulted in a much faster editing process than with GoLand. I have every single feature I regularly used with GoLand, but my editor is faster to load, consumes less memory, and I can progress at-least-as fast, if not faster by now.

Yeah I found Java really needs full ide support and yes that absolutely qualifies as a blizzard where I'm cuddling up to vim bindings on whatever the team chose for their ide. Eclipse wasn't all bad last time I did this but I'm someone who doesn't enjoy Java as much as some other languages in part for this reason - people who disagree with that aren't wrong.

But I've also never tried to use vim as a java ide and it could be great for all i know..?

> My JetBrains IDE does so much out of the box

That's exactly what I don't like about it. I'm a simple guy; I like simple editors. I will spend more time turning off things in JetBrains and VSCode that I find distracting and annoying than I will spend on setting up Vim to add some features I want like LSP support.

For me, I'm not interested in Vim's modal editing. But I use Neovim daily (mostly in insert mode like a noob). The reason for this is that Neovim blows every other text editor out of the water in two areas: time to launch, and multi-language syntax highlighting.

If I'm in the command line and I want to edit a text file, VS Code takes 4 seconds. Neovim takes 400ms. I installed vim-polyglot and it has syntax highlighting for even weird config files. I don't understand why no one is competitive with Vim by these metrics.

Vim can be used in easy mode, where you have no modal editing. Just start vim with the -y option.

- I love the keybindings, but the draw for me is mostly in the way it handles splits. Being able to say "split this window horizontally/vertically with this other file" in very few keystrokes is the best thing since sliced bread to me

- That said, I do love the keybindings, and I've not found a single vim emulation that doesn't feel wrong within a few minutes of usage. It's very, very difficult to get a realistic vim emulation mode, to the point that I'd rather not try to use it in another editor

>>What is the benefit of using Vim proper these days?

1. Editing files on machines, where you can't use vscode remote editing.

2. Leetcode grinding. Many companies allow only vi for onsite interviews. Some companies will prevent you from using features of vi like ctrl-n and macros. So might want to practice with the bare minimal feature set.

3. General text heavy lifting, if you are aware of how to use Macros.

vscode has a ssh plugin that makes remote editing of files and projects quite easy. I use it all the time.

Hey, so this article is 12 years old. VSC didn't exist yet (2015).

I used vim because it was installed by default on just about every modern Linux server, so as an admin it was much simpler to just use vi (less easy to fat-finger a config file due to the modal).

But I wasn't porting my personal config around 100's of Linux servers, unless when absolutely necessary [not every admin wants the same config].

As far as having a huge ecosystem with vi - has anyone actually done a comparison of number of 'things' that make up an ecosystem and active users between VSC, emacs, vi?

I know reddit isn't a good sample size, but looking at subbed users:

- vscode 95k - vi 151k - emacs 62k

I'm not doubting that vi would have the larger community, but I'd have expected emacs to be larger than vscode on reddit but it is not.

> I was using vim like a glorified nano

I daresay that most nano users use nano like a "glorified nano" too. I wouldn't blame nano for this.

Nano can actually be a pretty slick little editor if you're willing to dive a bit deeper.

Dark patterns in mainstream IDEs, Jetbrains & Microsoft, are extremely common.

Jetbrains actively forces developers to avoid the terminal for vendor lock-in.

Microsoft, ha. Embrace, extend, extinguish, (first Python, now Copilot) isn't new.

Sadly, commercial software turns success into "selfish dark patterns," at the drop of a hat.

I've an extremely strong urge to go to Vim.

The quantity of work won't be small however. Setting up graphical debugging, refactoring, inheritance visualization, will be an enormous mountain.

I'm not sure I'll ever use Vim for JVM languages. JVM languages lend themselves to enormous complexity.

Likely because the IDE enables it.

The article is 10 years old. Hopefully by now he has found out how to disable Vim's smart indenting of HTML files!

He was barking up the wrong tree too, as HTML indentation is controlled by 'indentexpr' and not 'cindent' or 'smartindent' (and was in 2011 too). These options are kind of legacy from back when Vim was mostly just an editor for C code and before there was anything like VimScript so indentation had to be in Vim itself, rather than a runtime file.

It's unfortunate; I still see people confused by it today.

now someone needs to write nvim version of this, because some plugins have arguably better alternatives (fzf, nvimtree), you have ton of lsp clients, each with their own blows and whistles, treesitter and plugins a working on top of its tokens, also there are far more options to disguise vim as the slickest gui editor you've seen

It just shows that ten years some plugins have come and gone as have many GUI text editors however Vim endures

From 2010 but very well written.

If memory serves me right, this is the blog post that got me into vim when it first made the rounds.

Prior to that I was just another developer googling "how do I quit vi."

Same—this was the article that got me over the hump and started using Vim.

Also, his .vimrc file is epic. It’s a little dated now but it shows how deeply Vim can be customized, in ways that most editors cannot.

Corrected the title.

i like modal editing but i don't really care what editor it is. as long as it supports my editing habit, i'm fine with it.

edit: i also keep the binding as close as vim's vanilla as possible. and that's it.

Reply on news.ycombinator.com