[modernerd]

If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors like https://helix-editor.com/, or new native GUI editors like https://zed.dev/ ?

It's impressive to see what the Neovim community has built — preconfigured setups like https://nvchad.com/ are especially wild. But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed, which are pretty great out of the box, and which were built to be used as rich development environments instead of extensible text editors.

I've spent months tweaking Neovim/Emacs configs in the past and I ultimately end up conceding that I'd rather spend that time hacking on projects instead of my editor config. I do feel the pull of these editors, though. I'd love to understand what those who stick with them are doing differently, other than perhaps being more susceptible to sunk cost fallacies. :-)

[yjftsjthsd-h]

> If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors like https://helix-editor.com/, or new native GUI editors like https://zed.dev/ ?

VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks. Also for my personal use, everything that's not vim suffers from being not vim; it would cost me effort to switch for no clear benefit, and I'd still need to retrofit the same control scheme into whatever it was because the muscle memory is too strong, at which point I might as well just use actual neo/vim.

> which were built to be used as rich development environments instead of extensible text editors

> spent months tweaking Neovim/Emacs configs

I think part of the difference might be of usecase; if you want an IDE, use an IDE. If you needed to spend that much time bending the tool to what you want, maybe it wasn't a good tool to use. When I open vim, it's because I want a text editor, and it provides a text editor.

[johnfn]

> VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks.

Perspectives like these (and others in the thread) remind me that there exists a separate cohort of engineers from people like myself which have absolutely polar opposite views. I respect your opinions, though I couldn't disagree more with them! :)

Well, except the bit about VSCode having "spyware". That's not true, and it weakens your point. It does have telemetry - I suspect that's what you mean, and you should just call it that instead.

[jrm4]

No. Microsoft's general reputation for spying on its users renders "spyware" a reasonable shorthand for what it either does now, or perhaps is reasonably likely to do at some time in the future.

I would fall back to the softer "telemetry" ONLY IF they were to provide some sort of genuinely reliable affirmation that it's not spying, which I don't think they could do today absent legal or other generally obvious incentive.

[johnfn]

I mean, you can say whatever you want - you only diminish your own argument by doing so. It's like the boy who cried wolf - if you keep shouting "spyware" with no true evidence of spyware, then by the time that "spyware" actually is happening, no one is going to care.

> what it either does now

Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.

> perhaps is reasonably likely to do at some time in the future

An imagined hypothetical does not help your argument.

[yjftsjthsd-h]

> Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.

Well, yes, of course Google would say that. If you ask DuckDuckGo to define spyware, it offers these:

> Software that secretly gathers information about a person or organization.

> programs that surreptitiously monitor and report the actions of a computer user.

Which of course is exactly what VSC does.

[CrendKing]

That's wrong. They key element of "spyware" is that it monitors and reports outside of it's own realm, and cause damage with the data. Like a keylogger logs keys even it's not the active program. What VSCode does is only monitoring user action within VSCode for technicality. Until you can provide evidence otherwise, calling it "spyware" is act of defamation.

Also, if software with telemetry is spyware, there is no mainstream browser clean. Feel free to use forks like Tor Browser or VSCodium if you like, but expanding the scope of spyware unreasonably only gonna cause confusion to average people.

[jsf01]

Even the FTC struggles to define spyware. But I think you’re right that a disagreement on the definition is at the heart of all of this. I wouldn’t be so overconfident in asserting that spyware is defined in your particular way here, though. There isn’t exactly a consensus! VSCode is certainly not to be lumped in with password stealing keyloggers, but because they continue collecting telemetry data even after you explicitly disable it, VSCode does fall under the “collecting data without a user’s knowledge” category of spyware.

[jrm4]

I'm very comfortable calling ALL OF IT spyware until something like the GDPR cookie thing exists for it. (or they voluntarily make such a statement BEFORE you use it)

[jrm4]

Calling spyware an "imagined hypothetical" re Microsoft is like calling "too hot coffee" an "imagined hypothetical" for McDonalds.

They've already done it a bunch. Are you naive enough to 100% believe their pinky swears?

[johnfn]

Sure, let’s have any example of this by any reputable news source then.

[seti0Cha]

I have a tangental concern, which is that all things microsoft these days seem to be evolving towards an advertising platform or a subscription. The way they keep adding integrations into their other stuff is understandable, and doubtless convenient for many people, but I can't help but think that someday after they are deeply embedded in the workflows of large swaths of the development community a message will appear in your editor suggesting an upgrade to the pro version of some tool or plugin and the freemium experience will have arrived.

[kweingar]

Lots of big tech companies (including mine) let their devs run VSCode on company machines. If there was a concern about spyware, I feel like all of those security teams across the industry wouldn't have signed off on this, especially with billions of dollars of IP at stake.

[sophacles]

Like log4j!

[kweingar]

I think there's a bit of a difference between a bug that went undiscovered for years and vetting third-party software to see if its telemetry compromises your employees or IP.

I mean, sure, if you want to avoid log4j from happening, you can write all of your software from the ground up in-house with no third party dependencies (or audit every line of code for every third-party program you do use), but I don't see how that's relevant to a discussion about whether VSCode is compromised to a degree that other editors aren't.

[sophacles]

Ah telemetry - you mean software that sends back information about what I'm doing to some 3rd party? Unlike spyware which is software that sends back information about what I'm doing to some third party.

Totally different, got it.

[johnfn]

I said this to someone else, but spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.

[kingofpandora]

Why does Google get to decide that software has to "hide on your device" and that it has to steal banking information or passwords to meet the definition of spyware?

[sophacles]

I don't want MS to monitor me. Anything that enables them to track me better is sensitive because I don't want to be monitored.

[CrendKing]

No one stops you from using VSCodium. But associating a software with spyware (a black/white action) should not but tied to how much telemetry (a spectrum) they collect. It's about what type of data they collect and what they do with the data. If they deliberately use that data to cause any damage (black/white), you can call it spyware. But if they only use that to improve their software, no, you shouldn't.

[modernerd]

> and you should just call it that instead.

And then turn it off using the built-in setting:

https://code.visualstudio.com/docs/getstarted/telemetry#_dis...

[yjftsjthsd-h]

   - https://www.roboleary.net/tools/2022/04/20/vscode-telemetry.html
      - "It looks like you cannot shut telemetry off 100%. These settings will
        opt you of most data sharing scenarios; but not all data sharing
        scenarios."
      - Apparently even VSCodium can't kill it all
         - https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetry

[aeze]

You could also, if you wish, audit the telemetry events and determine if it's worth turning off - or decide that it's okay with you that they're using that data to improve their free product.

https://code.visualstudio.com/docs/getstarted/telemetry#_vie...

https://code.visualstudio.com/docs/getstarted/telemetry#_gdp...

[yjftsjthsd-h]

I could also just decide that it's okay to use a free editor that doesn't report on me in the first place. I don't need to audit exactly what information vim sends off and evaluate whether it's too much, because "none" is really easy to decide on.

[MichaelCollins]

Searching for excuses to let the company's product spy on you sounds like a huge waste of time.

[j-bos]

Vscodium is pretty great though.

[cercatrova]

I use VSCode since switching away from Neo/Vim because things just work. I don't have to install a bunch of plugins like I used to where I don't know what works and what doesn't work with each other. For example, for Rust, I go to VSCode extensions page, click install on rust-analyzer, and that's it. I don't have to set up an LSP, syntax highlighting, etc which are each their own plugin on Vim.

[justinpombrio]

That's funny, I just switched from VSC to NeoVim because things just work. The C++ LSP bindings for Vim were easier to set up, faster, and more reliable than my setup in VSC. Though I imagine these things vary greatly, since C++ and C++ tooling is enormously complex and varies from codebase to codebase.

[ii41]

I just want to express why I sometimes prefer things that don't "just work". I love VSCode. I use (neo)vim just because I am used to them (started using them before VSCode was around).

Firstly, not "just work" means there will be no features to suddenly appear and "help" me. When I start to use a new IDE I never know what inserting "{" does: Will a "}" also appear? Will it start a new line? Will it cause indentation to change? Will it insert a whole snippet? How do I just insert a "{"? An IDE usually comes with lots of "helper" features like this, and questions like these add up. The result is that I never know what happens when I press a key and get agitated when the result isn't what I expect. If I set up everything myself this doesn't happen. (neo)vim is pretty bad in this sense actually. The default formatoptions and filetype indent plugins are pretty annoying, and the "J" normal mode command has behaviors that surprise users and cannot be turned off (you can remap it for sure), but by the time I met VSCode I got familiar enough with them already... I recall VSCode's default was pretty clean. IDEs are absolutely the worst.

Not "just work" also means that I know how to change something if it steps into my way, since I set up everything myself. If I have to edit a file with special formatting rules that I need to follow, I know where to change auto formatting rules. If I have to read some generated code or code from dependency libraries, I know where to turn off warnings from linting. Since rust-analyzer is set up by myself, if one day I find that its version or config is not compatible with this new project I am starting to work on, I know immediately how to change it. If my whole setting up effort is "clicking a button", it becomes harder for me to find where the change needs to be made. Such things are not just "if"s actually, but happen pretty often from my experience, often enough to make me think it's better to set up everything myself than to figure things out each time.

[peppermint_tea]

on linux, kde/kate is pretty good... I switched back to full tmux+vim lately to get even better with vim, but I find that kate is the perfect mix between an ide and a terminal based editor. makes me think of notepad++ with a few extra goodies (files on the left, terminal below etc...)

[cassepipe]

Last time I tested Kate's vim mode the g letter did not work in insert mode. Kate looks great but seems even more overwhelming to configure than Vim

[wyclif]

Hmmm, did some of the mappings change with this release? Now hitting CTRL-B (I do that a lot in NERDTree) gives me the "E5248: Invalid character in group name" error.

[d3nj4l]

If VSCode "sucks", then isn't it weird that the vast majority of people seem to love and even prefer using software that "sucks", including GP?

[yjftsjthsd-h]

I'm not sure how you'd know that; since vim, emacs, and other more traditional options don't include telemetry we don't know how many people use what editors. In any event, Windows remains the most-used (desktop) OS, so I've long since acclimated to people living with the suckage.

[Winsaucerer]

There's some data here that can help give a clue: https://survey.stackoverflow.co/2022/#most-popular-technolog.... It does look like vscode is the most used by a very large margin.

[yjftsjthsd-h]

Scrolling up, the same sample put NPM use at 65.17%, so I feel pretty comfortable calling it sample bias.

[Winsaucerer]

The data is no doubt biased, but given just how far ahead vscode is, it would need to be a very heavy bias to see vim/nvim come out ahead among all developers (however we define that). It gives us some information, but I agree doesn't tell us what the proportion is among all developers.

[bee_rider]

Popularity is not a great metric of goodness, unless we want to come to terms with the fact that Limp Bizkit records are around 3x as good as VSCode (and that's despite the fact that they aren't even charging people for VSCode!)

[malikNF]

In addition to programming, part of my job involves doing linux admin stuff, when I login to a server I expect vim to be there, and if not it takes a few seconds to install it.

I usually try something on my local machine and switch to the server and do this back and forth and sometimes the other way around, I have a test server where I test something before trying it on my local machine. Having the same text editor on all of these environments mean I don't have to context switch much, also I have my own custom config which I have been improving over the years and the fact I have multiple vim instances running right now and they are all consuming less than 120MB memory and the fact it responds really really fast is a really nice addition.

When I first started using vim I remember I asked one of my friends the following, "what the hell is wrong with people, why do they love using this god awful garbage" I remember my friend asking me to keep trying for a little while longer. Thank heavens I took his advice, I can't really remember when it happened but one day it just made sense.

Then I saw a neovim config file, and how good it looked with lua scripting, changed my old vim config in to a neovim one, and now I use neovim.

(plus I still have trust issues with a certain multi billion dollar company)

[jasonpeacock]

Because when I started using Vim, VSCode and Helix weren't around. And now I know Vim (Neovim) very well and it does everything I need - I'm productive with it and it's lightweight.

I don't want a full IDE/graphical editor. Eclipse is a mess, I'd use a JetBrains product first, but now we have VSCode as an alternative. Atom was hot for a while but has lost popularity.

Of the (linux) terminal text editors, the choices were mostly:

* Emacs * Vim/Neovim * Nano

And I prefer Vim over Emacs, I really like the modal experience.

I don't spend a huge amount of time tweaking things, I use Neovim mostly stock with some useful plugins for convenient shortcuts. Though I admit that getting the new treesitter/language server integrations working was annoying, compared to the original regex-based syntax highlighting.

My goal is not to recreate an IDE experience in Neovim, I just want an efficient text editor that is syntax-aware.

If I wanted an IDE then I'd use an actual IDE.

[jesperlang]

Why? Here are some reasons in no particular order!

* +20 years of muscle memory

* Total customizability, when you get good at configuring and writing small scripts it feels like you can do anything. VSC feels like it's all about plugins

* On the fly remaps. E.g writing latex and quickly add insert mode remaps for things you are currently writing about ":imap CO2 $CO_{2}" for a prettier version of CO2 as you type. Playing around with Zig? With ":map ,t :w<CR>:!zig test %<CR>" you can type ,t and it saves and tests the current file.

* Write simple scheme files for pattern matching with Treesitter to conceal unnecessary clutter in some programming languages

* Snippets, other editors have this as well but with Luasnip I program every aspect of how it works exactly as I want it

* Even with a bunch of plugins it starts in less than 100ms

[massysett]

I was not familiar with Helix or Zed, so I took a look at the links.

Both webpages prominently state that the editors are written in Rust. This reduces my interest in both projects.

As a user, I do not care what language my editor is implemented in. Maybe I want a fast editor, or maybe I want a feature-rich editor. The closest I would come to caring about this is if I want an extensible editor - can I extend these editors using Rust?

Lacking any explanation as to why I should care that the editor is written in Rust, the conclusion I draw is that the creators of the editor were interested in an exercise in writing an editor in Rust - which I'm sure is a wonderful learning experience for the creators, but I don't see why that would make me interested in using the editor.

[benreesman]

I don't get along very well with the HN Rust Community (and I think I'm even less popular with them than they are with me), but fair is fair and the Rust folks have been absolutely revolutionizing the modern terminal experience.

Put differently, I take the opposite view: seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool. Something like 70% of the command-line nix packages in my home manager are written in Rust.

[epage]

> seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool.

I maintain clap, the most common CLI parser for Rust. When soliciting feedback on changing some of the `--help` formatting, a piece of a feedback I got from a couple of people was some of the distinctive look told the reader it was written in Rust and using clap and "that means a certain baseline of quality and behaviour".

[norman784]

For me the thing is if is written in rust it has more chances to get more contributors, besides all the rust benefits (fast, performant as if it were written in C, but without the worries of the memory issues).

Also just because I use rust, I could contribute, for C/C++ editors I will not be able, maybe I'll also give a chance if the editor were written in Go, but no other language, all the others are slow.

Also rust IMHO has a few apps (including commands) that are worth checking:

- Helix - Alacritty - Wezterm - Nushell - Zoxide - Starship

Then are others to replace grep, and other commands that I cannot remember from the top of my head.

[cercatrova]

> This reduces my interest in both projects.

That's funny, it's the opposite for me.

> As a user, I do not care what language my editor is implemented in.

I do care. I don't like using Electron apps, even if I have to grudgingly use them a la VSCode. If an app is in Electron or some other slow framework like a Python GUI, my interest immediately drops to zero. If it's in Rust or some other low level language, at least I know it'll be fast.

[modernerd]

Don't let the “built|written in Rust” taglines put you off either project.

Both are fast editors built by passionate teams offering compelling out-of-the box experiences. They're worth taking five minutes to download and try (or apply for the waitlist in the case of Zed).

[CrendKing]

Think this in a jokingly way: since only smart and dedicated people can master Rust, software written by these people must be good most of the time. Just like how literate people in ancient societies are mostly elite class. You don't expect a peasant to write a history book.

Of course, same as how our societies develop, when Rust inevitably become more popular, this perception will no longer hold. One day, Rust will join amongst C and C++ and become tool for everyone. Until then, "Written in Rust" is just a cheap but effective differentiation ad.

[dominotw]

> As a user, I do not care what language my editor is implemented in.

Perhaps its a proxy for speed. You don't want your editor written in python.

[denvaar]

Average joe-schmoe Neovim user here. My goal is not to emulate VS Code and other similar software. I enjoy Neovim for programming mainly because...

- First and foremost, I love the text editing features Vim has (eg. the movements, modes, keys etc). It just feels great on my hands.

- It's minimal. Well, you are free to make it as minimal or as bloated as you would like to ;)

- For me, it sort of gamifies text editing. I don't claim that using Vim makes me x-times more efficient at programming than someone else, but I do enjoy the thrill of learning a new, quicker way to make some changes.

- Vim/Neovim offers me a seemingly endless amount of things to learn. Some may see this as a negative thing, but I see it as a feature. It's truly like a skill or a hobby. You can learn the basics and be perfectly fine, but you can also dive deep into more ways to improve. I love this.

- I love how configurable it is, and also that you can actually learn about how it works.

- Also if I'm being honest, I feel like a myself and a lot of other Neovim users are basically masochists to some extent.

[modernerd]

Agree that it gamifies text editing – vim motions are fun, even though I largely don't miss them in VS Code, or I use a vim extension when I do.

> …myself and a lot of other Neovim users are basically masochists to some extent.

It's great of you to say this, and heartwarming to see a sense of self-awareness on HN.

It's easy to rationalise our tech choices away (vim = speed, efficiency, freedom!). It's harder to admit that we may have chosen our tools simply because it's fun to walk a learning curve that runs sharply from pain to joy. Of course we could pick an easier tool! But then our path runs from apathy to apathy! And we'd be making it alongside people who think tools are just tools, instead of within a counterculture of likeminded people who think that tools are _everything_.

Maybe I should give neovim another shot…

[stoplying1]

Helix is just very, very excellent. I've spent less than 5 minutes total configuring it and I really have virtually not a single complaint and there's WIP for the niceties that aren't present yet (sidebar/treeview, etc).

I installed it, had some LSPs already on path. I configured it to show LSP messages and that was about it. It's very cool how gosh darn productive I can be, in such a short time due to the command palette built in.

Seems like folks are taking note too. There's a few intro videos on YouTube that do a good job posted in the last few weeks; apparently some big Vim-guy streamer checked it out last week. Active Matrix room and constant code improvements. And native nix flakes support too ;)

Btw, I find it a bit weird to include VsCode and Helix here together. Helix is perfectly usable as a Vim replacement for all basic text editing tasks, and a superior zero-config alternative in countless other scenarios.

[modernerd]

I'm looking forward to a treeview too!

https://github.com/helix-editor/helix/pull/2377

And subsequent icon support:

https://github.com/helix-editor/helix/pull/2869

> I find it a bit weird to include VsCode and Helix here together.

I work with people who declared config bankruptcy, switched from Emacs/Neovim to VS Code, and are perfectly happy and (maybe even more?) productive as a result.

VSC is not in the same category as vim but it seems to appeal because it's a halfway house between vim/Helix and a heavier IDE. John Carmack even said something similar about VSC in his Lex Fridman interview:

01:11:31.060 And I am super happy that that seems to be winning

01:11:33.540 over even a lot of the old Vim and Emacs people

01:11:36.140 that they're kind of like,

01:11:37.140 hey, visual studio code's maybe not so bad.

01:11:40.060 I am, that may be the final peacekeeping solution

01:11:43.260 where everybody is reasonably happy

01:11:45.620 with something like that.

https://karpathy.ai/lexicap/0309-large.html

[OkayPhysicist]

For a perspective that hasn't been shared all ready, I like modal editing because I A) don't like to use the mouse any more than I have to and B) have awful memory when it comes to complicated chords of keyboard shortcuts. Except for the bare basics (switching modes, jumping to the start and end of lines, etc), I heavily rely on much easier to remember names of commands to interact with my editor. Like toggling line numbering: I'm sure there's some ctrl-alt-F4 esque chord to do it in VS Code, but that'll be much harder for me to remember than :set number.

For similar reasons, I prefer the command line to GUI-based applications, that all seem to be built around either a love of clicking through a long series of cascading menus, or memorizing obtuse shortcuts. TUI applications like Vim integrate much more readily with my other command line tools, so it creates a much more seamless workflow.

[esclerofilo]

> but that'll be much harder for me to remember than :set number

You could also do Ctrl+P on VSCode (or Ctrl+Shift+A on a Jetbrains IDE) and search for "line number". Command based interfaces are no longer unique to CLI tools.

[ar_lan]

> why you chose it over VS Code

VS Code has always felt clunky to me. It always felt like a halfway house between the speed and simplicity of Vim and the maximalism offered by JetBrains IDEs. I also just generally don’t love GUI apps for code because I desire to be right in my shell.

NeoVim offers LSP, Tree Sitter, DAP, and easy extensibility to reach full parity with any IDE, but with the benefit of it being:

* Faster (both in processing speed but also in my workflow). I can navigate significantly faster in Vim than I can in any other editor. * More familiar, to me.

I can’t speak to Helix as I’ve never heard of it, but in general, the Vim community is very strong and long-lasting - it’s been a top tier editor for the past few decades and will likely continue to keep that place (albeit NeoVim is the currently favored flavor for me).

Beyond that, the extensibility of Neovim is unmatched in VSCode.

I also do most of my development in a VM and VS code remote shell is significantly slower for me than just ssh + neovim.

> huge amount of work, hoop jumping, and fragility to reach parity

This seems inaccurate. Maybe it’s because I use NixOS but my editor experience is literally the least fragile piece of software I use. I’ve ran into far more issues in both GoLand and VS Code than I have in Neovim. Perhaps because Neovim is less of a walled garden?

It took me about a weekend to properly learn Lua and how Neovim works, and after that, I was set.

> spent months tweaking

I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all. I don’t really touch my editor config unless I need to install a new LSP server - it always just works.

—

At the end of the day, the best tool is the one that enables you to be most productive. I find almost anything outside of the terminal clunky (the main exception is my browser).

[modernerd]

Thanks, some helpful insights here. (It sounds like the summary is, “set it up and don't fiddle with it too much.”)

I agree that the neovim community is great and neovim is of course very hackable, although there's always room to improve: an API for terminal UI would help a lot when writing neovim plugins and make everything feel more consistent, for example.

> I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all.

I built a neovim config from scratch, used built-in docs, community support, and well-known extensions when needed. I wrote small Lua plugins when I couldn't find extensions or workflows that worked for me. And I had fun doing it!

I got something good in a weekend, something very decent in a week or two, but still had a lot of gaps between what I had and what I wanted (session save, restore and quick switching; a Magit-like staging and forge management UI for GitHub CLI -driven PR management; invoking and managing long-running terminal processes from the editor; find/replace in large numbers of files across big projects with something more intuitive than a quickfix list; linting with something lighter-weight and easier to configure alongside LSP servers than ale; quicklists for LSP issues; a simple test runner with quicklist for errors; I can go on…).

After trying out extensions for some of those things but finding nothing that fit the bill, I played with Emacs and had a pretty similar experience there (weeks of work just to reach parity with VSC+a few extensions). I concluded I was wasting my time — it was pretty clear I was after an IDE more than a text editor at this point. VS Code seemed a nice in-between option. There are things I miss from vim/Emacs (speed, keyboard-driven workflow, getting to enjoy and celebrate editors with a community of likeminded weirdos), which is why I tend to get sucked in by these update announcements and discussions. But for the most part VSC is fine.

[alwillis]

If you use Neovim, can you share why you chose it over VS Code

Every time I try VS Code, I get frustrated within 10 minutes and close it.

It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.

I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?

But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed

I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.

I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:

* TreeSitter * LSP Diagnostics * LSP Trouble * LSP Saga * Git Signs * Git Gutter * Telescope * NvimTree * WhichKey * Indent Blankline * Dashboard * BufferLine * Lualine * Lightline * Neogit * vim-sneak * Fern * Barbar * Scrollbar * Mini

In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.

Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.

Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.

[jofer]

I can't really agree that VS Code or Helix are "great out of the box". I haven't tried zed. VS Code feels really awful to me (note: this is probably just me) without weeks spent re-configuring it. Even then, it's _way_ too heavy for my laptop to run reliably. Maybe my brain just works differently, but I feel like VSCode fights against me at every turn. Helix is nifty, but also feels like it gets in my way more than it helps.

I've never understood the advantage of "rich development environments". The refactoring tools and other fancy aids seem to never work. I wind up using regexes + manual intervention anyway. Also, I don't want to use git through a gui. Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.

Syntax highlighting, linting, completion, and docs are all nice, but I have that in vim. I can run vim in the dev instance I'm ssh-ed into (which is 99.99% of how I work, anyway -- my work laptop is ancient and they won't replace it). I just can't see what those tools add, even for very large codebases.

My configuration for vim began in the 90's. I've never put that much work into it at any one time, though it has grown quite complex over time. There are a bunch of plugins I use manged in the config file. 90% of the functionality I need works without those plugins, but even when I need to install them from scratch it's easy to go from "scp config file over" to "full setup" with one command.

So in summary, I use vim because it's part of a larger set of standard unix-y tools that are heavily ingrained into muscle memory. The biggest advantage of vim in many ways is that it's a relatively rich environment (e.g. linting, syntax highlighting, doc hints, etc) that I can ctrl-Z to immediately be back in the terminal with. Other than that, it gets out of my way, and I don't think about the editor at all, I think about what I'm doing (decades of muscle memory helps a lot, though -- I'm incapable of not using vim keybindings to edit code, I think).

I should move over to neovim, but mostly haven't yet. That's more due to a couple of weird plugins than anything else, though.

[dm319]

> Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.

People talk about vim nit being an IDE, but I think a lot of people think of the unix command line as their IDE.

[reidrac]

I have been using vim since the late 90s, although the experience back then was much different. I don't think I really used plugins until around 2010 or so, and I was more into gvim until I moved to tmux + vim combo around 2016. So my nvim setup is not too fancy (sometimes I try plugins, if in two weeks I don't use them -or I don't even remember how they work-, I uninstall them).

Moved to neovim because it felt faster than vim 7.x and it was fresh and exciting (couldn't believe the progress the project was making in a short period of time, compared with vim). Then I stayed because of the native LSP support and nvim-metals (among others).

Things work, to the point that I'm not really using the editor but editing (if that makes sense). It is completely invisible to me. It is my editor.

[sophacles]

Similar story here. I often liken it to a musician with their instrument, or a master blacksmith with their hammer - at some point the tool stops being a separate entity and becomes an extension of the person wielding it. I think the ability to have this comes from the fact the fundamentals of the tool are stable across decades.

[zimpenfish]

> If you use Neovim, can you share why you chose it over VS Code

Just about 30 years of muscle memory for ed, then vi, eventually vim, and recently neovim. Also because one flavour or another is pretty much guaranteed to be available on any server I log into - as a contractor, it's handy to know there's a (to me) usable editor wherever I end up.

> I've spent months tweaking Neovim/Emacs configs in the past

I had a brief spell of Emacs madness at uni but then recovered and I've had pretty much the same vimrc since picking up vim modulo adding things like go-vim and surround in the last few years.

[Grimburger]

> pretty much guaranteed to be available on any server I log into

So is nano, the original comment hits the mark, why exactly can't you use a proper code editor via ssh? There's very little reason these days. Haven't used a terminal editor for a decade despite doing tons of work that many would instinctively reach for the same job.

VSCode and pretty much every other equivalent has modal editing if that's the sticking point here.

[zimpenfish]

> nano [pretty much guaranteed to be available on any server]

Having just checked 5 of the servers I'm currently logged into, nano is missing on 3 of them. Although one of those 3 is cygwin which is weird in the first place.

> why exactly can't you use a proper code editor via ssh?

Well, vim is a proper code editor. If you mean VSCode, it's not available everywhere; been at plenty of places where installing/using non-approved software on work machines was forbidden. Also, and this is a minor point, kinda, but using (n)vi(m) remotely rather than VSCode gives me one/many windows fewer to manage on my local end - everything currently lives in iTerm2 and I only have one app to wrangle. Using VSCode would give me another one - unless it can do terminal emulation as well these days?

[ar_lan]

What exactly is a “proper code editor”, and why does Neovim not fit the bill there?

[Blackthorn]

The reason I still use emacs over helix or zed: elisp.

Not because I particularly like the language. But because I like that I can write something in a language that executes and accesses pretty much anything the editor can do.

Does helix or zed have the ability to do that? I didn't see it on their landing pages. What are the extensibility stories for these editors?

[tomjakubowski]

Don't know about hex/zed but Lua in neovim is just about as pleasant to use as Elisp is with Emacs. It's not quite the same thing since neovim's still largely written in C, where Emacs is largely written in Elisp. But most of the editor's features (including text manipulation) are exposed to Lua.

Lua is a nice language too, just lacking the stuff that makes the Lisp nerd in me happy.

[lc9er]

And you can use Fennel to hack Neovim, if you want to stick with a lispy language.

[tomjakubowski]

Neat!

[modernerd]

Zed and Helix are both pretty new.

There's demand for plugin frameworks/scriptability in both but neither of them support it yet. I fully understand why people who need to script their editor are sticking with [neo]vim/Emacs — there are very few other options at the moment.

https://github.com/zed-industries/feedback/issues/388

https://github.com/helix-editor/helix/discussions/3806

[celrod]

I use emacs. I have little desire to customize configs and spend hardly any time on it. Checking now, I haven't modified it since June, which means I haven't even installed any new packages (the equivalent of VSCode extensions) since then either.

Maybe I should spend more time on it, but my settings work for me and I can't really be bothered/find coding projects much more alluring than editing a config.

Why emacs, then? Mostly that I like the keybindings more than anything else. Emacs extensions in vs code are a poor imitation at best. I'm not really into modal editing either. Maybe I'd just have to spend the time to learn that, but I'm quite productive with emacs, so I don't see the incentive. I have keyboards with thumb clusters, so it's comfortable and quick to press key combinations in parallel. Switching between modes and executing key presses is inherently serial in comparison. I assume with practice I could get very quick at that as well -- after all, typing is also serial, but can still be fast. I just don't see any value proposition to switching.

[rmolin88]

Neovim is extensibility and versatility. If you want a rich development environment, you can put in the work, or use one of the many preconfigured environments, and turn neovim into that.

If you want a bare ultra fast, terminal text editor, neovim is that out of the box.

If your only after LSP, tree sitter, embedded terminal, neovim's got your back.

Basically, neovim embodies the beauty of Linux. Use and pay only for what you want.

[jez]

As a Vim user I particularly liked this tweet thread on the topic recently:

https://mobile.twitter.com/hillelogram/status/15676069643974...

The central point of the thread was that VS Code is designed to be extended by dedicated editor extension developers while Vim is designed to be extended by basically all users of Vim. There are tradeoffs to both approaches.

[rockwotj]

I enjoy a terminal workflow, and helix doesn't actually have vim key bindings and many years of vim use is hard to switch.

EDIT: I'm also a tmux user and I can't live without a replacement for this plugin: https://github.com/christoomey/vim-tmux-navigator

[norman784]

Check wezterm, it has something similar to tmux splits and it's nice.

[ar_lan]

Kitty also has this feature built in!

[norman784]

I should try it, I read a lot of users that like kitty in the unix porn community, but never gave it a try.

[ar_lan]

Overall, I like it. I enjoyed WezTerm as well, but found that it suffered incredible lag in Neovim. Honestly, if not for that, I probably would use WezTerm full time. But kitty does have some significantly nice features, especially if you use ssh a lot (which I do).

[rockwotj]

Will do! Currently using alacritty and enjoying that

[alwillis]

+1. WezTerm is incredibly well done.

[jefftime]

I actually loved Helix, but moved from it to Neovim for performance and customizability reasons. Helix becomes unusable with multi thousand line files, but I imagine it's something that will eventually be solved as the project matures. The customizability of Neovim is incredible, and I'm looking forward to trying Helix again when it has a plugin solution

[Beltalowda]

I like "simple" editors: just text, completion when I ask for it (instead of popping up all the time), no distracting UI chrome, simple syntax highlights, etc. "Simple" is a bit of a misleading term, because even "stock Vim" (or Neovim) has a lot of IDE-like features. They just don't get in your way by default.

I tried VSCode, and after several hours I still hadn't turned off all the features that I found undesirable.

For me, personally, that nvchad thing seems horrendous. I don't know about Helix; maybe it's better, but I can't be arsed to check it out as I don't expect any productivity jump to be worth the effort.

[3836293648]

Helix has segfaulted within minutes every time I've tried it. Despite being written in rust. It might be better now, but they've already lost me.

I switched away from VSC because I grew frustrated with the constant lag and terrible loading times.

The modern native stuff is either MacOS only or a proprietary newcomer, leaving me with no trust that I can stick with it long term.

And I'm a Nix user, so neovim doesn't randomly break for me, all versions are pinned. And if stuff does break when I chose to update my pinned versions it's trivial to rollback.

[agency]

I use VS Code for my day job because I can't be bothered to sink that much time into configuring my editor these days. But I recently setup NeoVim to play with Clojure since the most popular VS Code Clojure plugin (Calva) interacts poorly with vim keybindings. It was surprisingly easy to get setup (used the Conjure plugin) - NeoVim has come a long way in the years since I had last played with it.

[musicmatze]

> If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors [...]

I am using vim/neovim for almost 15 years now. I was introduced to vim within _days_ after I started programming. I have a workflow where I open and close my editor several times per minute (although I'm now slowly moving away from this workflow) - startup speed matters a lot for this, of course. I never bothered to learn another editor or IDE because of the speed I get with (neo)vim. Moving my hands away from the homerow for interacting with IDE features just feels like driving a Porsche in a 10mph zone. I have muscle memory in my hands for over 10 years now!

I switched from vim to neovim at around neovim 0.5 mostly for ideological reasons, but I stayed for lua based plugins and a IMO better community. I rewrote my complete neovim configuration (which I took over from vim of course) about a month ago to be pure Lua and to be more streamlined... I don't consider this work or hoop-jumping at all, but optimizing my editing environment to safe time when actually editing source code (or emails fwiw).

On a side-note, I also use vim-ish bindings for everything else, for me DE/WM, Email client (which uses neovim to write emails actually), etc etc. I just don't see a point in un-learning all this.

[qbasic_forever]

I don't need parity with VS code. If I want LSP and all kinds of distractions, binging and bonging, and crap jumping out and highlighting at me... I'll use VS code (don't get me wrong, sometimes those distractions are useful).

Sometimes I need a terminal text editor. Something to quickly edit a config file, or perhaps even write something more substantial. Vim and Neovim are perfect and available on pretty much any machine which you'll have a terminal open to access.

[BeetleB]

I know you asked for Neovim users, but as an Emacs user, I'll respond:

> If you use Neovim, can you share why you chose it over VS Code

Who said you can't use both? Neovim is a text editor, and VS Code is an IDE. There is overlap, but they serve different purposes.

I use Emacs because it has a lot of capabilities that make little sense in an IDE. I don't think many people use VS Code for reading email, for example.

And I use VS Code when it's more convenient than Emacs (e.g. debugging).

[ptato]

Modal editing in VS Code is not good enough. I still use it for certain things. Just not the bulk of my programming.

When helix is more ready, I will probably switch to it.

[norman784]

I use both, there are certain nuances with helix right now, like exploring the project structure, there's a sidebar in the works, but is not ready yet, also when you need to create new files I find it easier to do it in vscode.

[jerpint]

I really like working inside a terminal, and I like being able to navigate seemlessly between code tabs and terminal tabs as though they are one. I can do this easily in vim+tmux, I can't do this easily in IDEs where the mouse is considered first-class. I do miss certain features of IDEs, but being able to toggle between shells, tabs and code is my killer feature.

[peppermint_tea]

I just switched to this setup now... Before, I was using kate (which is very nice) but I switched exactly for the reason you've mentioned. terminal and editor in the same place.

[scelerat]

Kinda just like the modal editing of vim and the features and improvements upon it by neovim.

These days I've been using the LunarVim suite of neovim enhancements and I like it quite a bit.

https://www.lunarvim.org/

95% of my coding workflow takes place in the terminal (along with tmux and iTerm2) and neovim fits very nicely there.

[benreesman]

vi (and in different ways, emacs) were designed for optimal editing productivity on low-bandwidth connections and low horsepower machines.

This created an imperative around efficiency per keystroke that, somewhat shockingly, remains the most thorough and successful mainstream attempt to get the most from every keystroke.

With modern technology and decades more experience it seems inevitable that someone could do better today (though even with those benefits not everyone is Bill Joy), but I’m not aware of anyone who has successfully attempted to beat vi/emacs for the “will learn arbitrarily hard tools to be fast” crowd, which necessarily counts the “my RSI is so bad I need my money’s worth out of every key press” crowd, and several other big blocks of badass hackers.

People still use these tools because they still have the highest ceilings on the effort/power scalability curve. That doesn’t make them right for everyone, but it makes them right for a lot of people.

[ZeroGravitas]

I use Neovim because I used Vim before it.

I used Vim because every GUI editor was an ugly, siloed proprietary mess that was mostly just wrapped around a bunch of open source command line tools, while Vim was an ugly, open source, programmable mess that was mostly just wrapped around a bunch of open source command line tools.

[ibotty]

Because it's vim but better. I don't want an editor that uses, maybe, eighty megs and is constantly swapping!

[_kblcuk_]

I use Neovim exclusively for the past 4 years or so. Before that I used WebStorm + sometimes Vim for another 6 years or so. To this day I'm thankful to my colleague and mentor, who introduced me to the basics of Vim (you know, how to quit it and all that) saying "it get's pretty handy when you need to edit something on the server"; that was probably around 14 years ago.

WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition. The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.

At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line. And with resent native lsp & treesitter, it doesn't

I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.

Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs. Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.

So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.

[gorjusborg]

What are you attempting to do with all that config hacking? I've used vi variants for years with pretty much the defaults.

I also use vscode and other IDEs. Why make it seem like one has to choose? That's like saying 'why do you use a hammer, i like screwdrivers better'.

[__s]

I have a simple .vim setup which I can use across multiple machines: https://github.com/serprex/.vim (I know there's simpler out there; I haven't spent time pruning my config down)

I prefer sticking to full terminal UI

When I used vscode I was frustrated by vsvim's latency & missing features (macros tended to have holes)

I didn't start using vim until I'd been programming for a decade already. Before that I mostly used SciTE

You may be more susceptible to over tinkering. In the past few years the most I've tinkered with my setup was when I decided to try out neovim's lsp feature, where previously I'd been using coc.nvim

[bilalq]

I kind of take the best of both worlds. VSCode has a lot of functionality that Neovim lacks, particularly on rendering previews of things like Markdown and Mermaid. Even outside of UI stuff, VSCode's extension ecosystem has so much deeper integration with things (beyond the level of just text/code editing, I mean). The VSCode JS Debug Terminal is literally life-changing. No more needing to mess around with debugger configs for runtimes. Literally just run the code and it works.

Despite that, I still often feel limited by the vim binding plugin for VSCode. It's never a problem though, because Cmd+J toggles the terminal visibility, and I escape into Neovim there when I need it.

[dmix]

I was a Vim user for a decade+ and recently switched to VSCode 100% because the Typescript integration is unmatchable, no matter how hard you try in NeoVim (and I tried hard).

If you're a front-end dev there's really nothing better. Also the https://www.tabnine.com/ integration feels like magic, it predicts the next block you're going to type with scary accuracy. I'm excited to see where AI IDE integration goes.

But I still hate how VSCode is like a browser that will grind to a halt if you install (or misconfigure) too many extensions.

[bee_rider]

Yeah I don't see why one would try to reproduce the VSCode experience inside vim or whatever.

Vim or neovim inside tmux are really nice, though. You can just use the normal general-purpose linux ecosystem rather than learning an IDE.

[simonsaysso]

The sunk cost fallacy is real.

Most important to me when I started tinkering with him was the speed/feature tradeoff, and portability. I was working on 7 machines at one point doing pretty quick edits of config files and Python scripts, so launch speed and availability across different environments drive me to vim.

Now there are alternatives, but back in 2015 these were all in their infancy. And now I _know_ vim and it keep adding more features. The incremental cost of adding language server support is much less than the cost of learning how to move around VSCode, so my (neo)vim config keeps growing slowly but surely

[goffi]

- I have used vim for many years (15 maybe?), and once you have passed the initial learning curve (not so terrible, after you keep learning cool stuff even after years of use), it's useful for everything with the same shortcuts. I would actually spend more time learning something else like an new IDE. At the end, I have probably saved a lot of time by sticking to (neo)vim instead of following the latest trend.

- I like terminals because there is nearly nothing disturbing you, and it's usually quick to have something

- there are many little features that looks like nothing but are really really useful when you use them. I'm a big fan of C-a / C-x to increment / decrement a number, coupled with https://github.com/nishigori/increment-activator it's super useful (to change a boolean, a date, a number, etc). The "." to repeat last command, the "*" to search what is under the cursor are other great features. An occasional macro made with "q" may save a lot of time when you need to do a repetitive task, for refactoring for instance, and you can even repeat them according to some patterns with ":g". I'm not sure if those features have handy equivalents on other IDEs.

- I didn't spent that much time doing my config, just adding little changes here and there when necessary, over the years I've got a environment really adapted to my taste.

- I'm currently doing mostly Python, and vanilla (neo)vim is normally good enough, but I'm using Coc (https://github.com/neoclide/coc.nvim) for a little while, and it add a lot of helping stuff easily. Pyright + snippets are useful.

- when something cool happens somewhere else, you often have somebody adapting it to vim. I can use snippets and emmet which are occasionally very useful.

At the end, I don't feel the need to change, it works well, and over the time I could add some neat features to improve it (snippets, emmet, CoC, tagbar, etc). I'm not sure if changing to something like VScodium would worth the time to learn something new (and I like working with terminals).

[vlunkr]

What exactly is fragile about vim/neovim? I'd argue that they are incredibly stable, being as old as they are.

For another point I don't see being brought up, I love the .vimrc file. You can version control your entire editor config in one file. Other editors tend to spread config out across different files (one per plugin for example).

I've had to spend time configuring every editor I've used, but all that time is tracked and documented in vim. I can have everything set up instantly.

[mikl]

If you want to use Vim keybindings for the whole experience (not just the text editor panes). VSCode has plugins for Vim-editing, but not a complete experience. Helix has similar, but different bindings. Zed is still in private beta mode, so no idea what its like.

There’s others, too, but none seem to have a big and healthy community like (Neo)Vim.

[Faaak]

I use VSCode, but I installed the vim plugin which makes it handle like vim for user inputs. Best of both worlds IMHO.

[renox]

Nice customisation, but it still doesn't have the 'list of tab' vertical window that VSCode has, and I'll never switch to an editor which doesn't have this. Even if I find VSCode not very responsive..

[weaksauce]

you can use neovim inside of vscode. it's pretty alright with only a few things that are rocky. I like it. got that modern gui affordances with the plugin ecosystem and lsp baked into it hard but also the normal/visual mode power.

[modernerd]

Thanks, I use VSCodeVim at the moment because even though it's not using “real vim” under the hood the performance has been more consistent for me.

I revisit VSCode Neovim periodically but end up switching back after a day or so due to consistent freezing and cursor jitter (even with an empty nvim config and very few other VS Code extensions). I'll keep trying it out, though.

[wyclif]

For me the reason is mostly because of the speed of editing in Vim for me is blazing fast compared to what I can do in VSCode. Many of the most-frequently used Vim commands are just baked into my muscle memory at this point.

[AmpsterMan]

For me it's simple. My hands are already on my keyboard, and I already have my terminal open. For most of my programming I use whatever Jet Beans IDE my company has licenses for.

[tiffanyh]

https://v2.onivim.io

I was always bummed OniVim v2 didn't take off.

It was a native IDE but fully supported VS Code plugin system.

[dadoomer]

I've found the extra complexity of IDEs unecessary and detrimental to my productivity. I like to keep it simple: neovim with LSP and fzf in a tmux session.

[kgarten]

Neovim user here. I also use VS Code and especially the Jetbrain products for IDEs. Yet, Neovim is for me just an editor.

- I like I can use the same editor on any platform. I'm a wearable computing nerd having several HMDs and small devices (devterm, raspberry pie, etc.).

- If it's my own platform, it's easy to compile it. It runs in a console and most of my plugins work on embedded, desktop and server systems. (could even compile it and use it on my hacked google glass .. with a twiddler one handed keyboard :D ).

- I like the use of keyboard-only and mode switching. It's more an hobby than anything else. I also use qtbrowser and Nyxt.

Also growing up with a very different Microsoft ("Linux is evil communism"), I still feel uncomfortable using VSCode.

[divan]

I tried to use Helix and really liked it, but had to stick with Neovim because of Copilot.

[modernerd]

I also really like Helix. Looking forward to:

- Reload of files changed on disk: https://github.com/helix-editor/helix/pull/2653

- Autosave: https://github.com/helix-editor/helix/pull/3178

- Git/SCM support: https://github.com/helix-editor/helix/issues/227

- Extensions (potentially enabling Copilot support): https://github.com/helix-editor/helix/pull/2949

[fishywang]

vim, or at least vi, is something you can pretty much expect to be existing on any system you ssh into. If you are comfortable with vim, you have the editor part sorted no matter what system you are dropped into to debug/whatever.

[gkfasdfasdf]

neovim/vim are lightning fast, and since they are usually installed on remote servers as well it is nice to have a consistent experience editing files whether I am working locally or in a remote shell somewhere.

[threatofrain]

Helix is nice but Zed development speed appears to be a bit slow for my liking.

[dislikedtom1970]

besides being efficient text editor, I must say it's also a hobby for me. I just enjoy endlessly configuring it and writing little vim scripts.