> The amount of work needed not only to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
"This airplane is the choice of professional pilots! The first thing we advise you to do is turn the yoke upside down, it's much more ergonomic like that. Also, you probably want to rip out the altimeter and replace it with a custom one that has more features. And bring your own GPS unit and tape it to the windshield, because this plane doesn't have one by default. And of course, remember that unlike in your car, 'left' actually means right in this plane. This is the professional way. Ah yes, when you fly over Canada, you will see a blinking warning sign telling you that you're out of fuel. That's just a small glitch caused by metric/imperial confusion. It has been known for 23 years but we haven't quite gotten around to fixing it yet. Don't worry, this plane is still excellent for professional pilots. If you feel otherwise, you are probably not a real professional."
More that you want to carve a bowl out of wood. Vim is like a knife that with some modifications you can turn into a carving knife. VSCode is like a chainsaw that has attachments that have been made for it and it also has bowl carving attachment.
If you don't know your tools, then you can easily mess the knife modification and not end up with a carving knife. The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
So it is more like trading initial speed with more precision, but also being able to do more after the initial learning curve.
> The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
This is where your analogy breaks down for me. The "chainsaw" (VSCode) is absolutely perfect for the tasks I'm using it for. When I write Python code, the Python extension gives me exactly what I want. That's because the environment it creates has been fine-tuned based on feedback from thousands of users with similar requirements to my own. There's no need for me to modify anything, any more than I modify my car or my trousers. It's simply ready for me to do professional work, and whenever I have special requirements, I know that I will find an extension that caters to them also. I don't need or want to reinvent a wheel that has been invented hundreds of times already, and polished to perfection through more man-hours than I could ever hope to invest myself.
You get exactly the same functionality with (neo)vim plugins.
Only difference is that because vim has been open-source for decade, there are many many more plugins, and hence the choice is harder to make. VSCode also helped improve the (neo)vim experience (e.g. language servers)
Comparing VSCode and Vim is like comparing a standard calculator with an RPN one.
> Only difference is that because vim has been open-source for decade, there are many many more plugins
No, the main difference is in the quality of plugins, not in how many there are.
For example, Rust-Analyzer provides an official VSCode extension, which is professionally maintained by members of the Rust core team. The extension is part of the Rust-Analyzer project itself, and can be installed with a single click, at which point it just works.
For Vim, you have to manually download (and update) the Rust-Analyzer binary, install a third-party plugin, configure them to work together, and hope (1) that the whole thing doesn't break when the plugin or the language server is updated, and (2) that this concoction provides a tiny fraction of the functionality that the official VSCode extension does.
FWIW, I just needed to install the default nvim-lspconfig plugin (it's provided by the Neovim maintainers, and it doesn't do anything besides provide default LSP server configs for a lot of languages to the builtin Neovim LSP client), paste in the keybinds recommended by the README, and call lspconfig.rust_analyzer.setup in init.lua. Configures itself to start whenever rust_analyzer is in PATH. Seems to work well enough! I don't think it's missing any functionality.
I agree with your main point, you have to do quite a few things to configure these plugins and some of it is not straightforward.
However, I program rust using the lunarvim default configuration for vim and it has been very straightforward. I have all features I need to program comfortably and I didn't need to configure anything, the defaults were good enough for me.
So that doesn't mean that vim cannot have the same easy of use if there exists some sane default configuration you can just install.
I am happy with it and not going to change to vscode or something else.
I'm a vim user, but only because of the keybinds. I use VS code an equal amount because I often get too frustrated trying to wire the disparate vim tools. The never ending fiddling and 30-step process to get the equivalent of one click in vs code is exhausting.
The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
One of the tips in The Pragmatic Programmer is "Achieve Editor Fluency", wherever it's Vim, VS Code, or Sublime Text. I use IDEA for java code because in my job, I browse code more often than I edit it, and IDEA is nice for that. I also use WebStorm for the JS part because it's also good for that. But I invested my time into VIM because I can do everything above with it and even more. I don't want my editor to become an IDE, I want it to be powerful in editing and allow for integration, as there are slews of tools that work with code and text.
You should invest in your tools, be it Vim or VS Code. I chose Vim and Sublime Text because of their speed, and JetBrains' IDEs because of their code analysis engine. You may have different criteria, but try to follow the tip.
I do exactly what you described and indicated that clearly in my post.
What I'm perturbed by are the people who take it to extremes, and are happy to spend hours a week tweaking things, and can't fathom someone else might not enjoy doing the same.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
It's worse than that, it's a religion. Many of them truly seem to believe they're achieving a higher "hacker rank" or something, while most of it is just tedium and very low level learning.
It's rarely learning huge, game changing concepts. Frequently it's just chasing obscure docs to obscure forums to obscure repos for stuff some PhD student half baked a decade ago on their way to their biochemistry thesis.
Guess what, I work in DevOps, that's just my dayjob, anyway, I don't want to do it as a hobby in Vim, too :-))
And I say this as an "also Vim user". I.e. I use Vim and I've used it for more than a decade, just not exclusively, best tool for the job and all that.
For what it's worth, the 'VSCode-level' functionality in my init.lua has probably required roughly a few hours of maintenance over the ~7 years I've been using Neovim. The LSP setup is just a matter of finding a plugin manager (or not), installing the lspconfig plugin, pasting in the config from the README, and inserting a single line that contains the name of the language server you want to configure.
It can definitely lead you down all sorts of twisty paths if you look at other people's elaborate configs and decide to do that sort of stuff yourself but it's very pleasant/low-maintenance if you stick to the basics (meaning roughly what people do with VSCode). It takes me roughly a few minutes to configure Neovim for a new language :)
(Of course, there's some other stuff in my init.lua that I've put there for fun, like clipboard and window management scripts, but that's not strictly necessary. I've spent a bit more time figuring out the Lua API to write these, but I personally think it's worth it for the extra ability to mold the editor to my needs).
> No, the main difference is in the quality of plugins, not in how many there are.
I don't think that is true. If you browse the vscode marketplace and search e.g. for python [1] you literally get hundreds of plugins. If you scroll down only a bit, you quickly end up at plugins that only have a few hundred to a few ten downloads. I highly doubt that the quality of those plugins is better than the plugins for (neo)vim.
For your Rust-Analyzer Plugin example: I can install Rust-Analyzer with Mason in a few seconds as well and then (if you have lsp-zero [3] installed) it also just works™.
But I agree, keeping a vim configuration up to date is akin to a hobby (which I by the way enjoy quite bit).
That's just plain untrue. Vim always kept its own rust-analyzer binary and prompted me to update it. I use emacs now and actually have to update it myself
If what you need to do is cut down bunch of trees then chainsaw is exactly what you need. No one in their right minds would start with a knife and start building it into a saw and then attach a motor to motorize it. Mind you we were carving a bowl, but as per Internet argument you completely dismissed the use case and inserted your own.
If VSCode does exactly what you need out of the box exactly how you want it to do it, then you are set and you should use VSCode.
The problem is that Vim can be used to create config files and source code files among other things. VS Code can be used for very much the same things.
The output of both tools is practically the same thing.
The niche of things Vim can do and VS Code can't is tiny and constantly decreasing.
It's always been like this. Vim is an editor, and so is Sublime Text, Emacs, VS Code, Geany, Kate, Notepad++, and more. What sets vim apart is its ubiquity (it's been on every Linux box I touched) and its philosophy of editing text (modal editing). Apart from that, it's a matter of preferences and practicality.
I can think of a few YouTubers who would and probably have done just what you described. Now that I say that though, I realized you used the phrase "right mind" and I don't think I'd count many if any in that cohort.
Nah vs code is a multitool with both a hook blade (the knife younuse for carving out a bowl) And a chainsaw....
Slightly more unwieldy in that specific narrow use case than a plain hook knife but you don't need a second tool to cut the log you take the wood for the bowl from...
In other words, it's a tool that let's you do near anything with minimal modifications whereas vim is a tool that requires significant modification just to do Any task other than looking at it.
Yes. The advice to turn the yoke upside down is supposed to reference remapping Caps Lock to Escape, without which Vim destroys your pinky on a standard keyboard. But it's the choice of professionals, so what can we do?
I've been using Ctrl-[ instead of Esc for so long that I forget that a lot of people don't know about it. This may not be convenient on non-English keyboard layouts.
small fun fact:
I switched to this when the escape key was taken from me (thanks again NOT apple)
After switching to a newer MacBook that has the escape key I did not start using that again, but stuck to the Ctrl-[ as it just works.
I'm playing into the joke here, but on most terminals, alt + <key> will actually be sent to the program as <esc> + key. You can use this to avoid pressing escape in Neovim.
+1. I mainly use this approach. If your next intended move is to go to the next line, Alt-J will exit insert mode and go to the next line immediately.
Also the same for Alt+w/W/b/B, Alt+o, Alt+0, etc etc and it's just a matter of using your left thumb at the same time as navigating.
Nice, I didn’t pick up on that one. And I do have Caps Lock mapped to remapped to Escape haha.
If any vim enthusiasts haven’t read this history before, this article [1] provides a good overview of how ex/vi came to be. The photo of the Lear Siegler ADM-3A keyboard used by Bill Joy largely explains the odd choice of keys.
Trick for those wanting caps lock to be compose instead: ctrl-c also works as escape, and has historically been slightly faster due to sidestepping the escape timeout.
There is a timeout on multi-key mappings, so if you need to type fd0 you type f, wait 'timeoutlen' (1 second by default apparently), then type d0.
That's a pain, but it doesn't come up often. In return you get quite a lot of functionality (due to vim being modal) without having to move your fingers beyond the letter keys, which is quite relaxing.
Like many things in our field, we try to justify our choices, and because generally folks in our field holds high standards about themselves, we should justify as the only right way. What in reality, it is all about user preference.
In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.
I take it you've never played a fast game with keyboard controls? :-)
They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.
Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.
In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.
Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).
As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.
That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).
Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.
The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.
Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.
For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.
Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.
The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.
Did you read my original comment? I literally mentioned QWERTY as another example of backwards compatibility screwing everyone over.
I use QWERTY because I have to, I don't like it and I can't do much about it in practice. People frequently defend Vi's HJKL vehemently - just like - if I'm not mistaken - you, presenting it as a superior option for some reason.
I actually switch back and forth and I've thought many times about remapping u and l and j and k... you know what, maybe I should just bite the bullet.
HUJK instead of HJKL, basically WASD moved to the right :-)
Yeah. I actually find that no highlighting in some ways helps you understand the language better. Because you have to parse it, not rely on the highlighting to do it for you. When I was learning Rust, I spent a year writing Rust in vanilla vim which is by some accounts insane. But I did it for the uh immersion. And I’m happy with the result.
I do use Zed for working on projects when on my home turf. It’s just that I’ve sworn off wasting time configuring Vim everywhere. That too is advantageous because you have to have a much more thorough knowledge of the vim tool instead of relying on plugins to make it work for you. And vim is everywhere.
The thing is, using a plugin like ‘surround’ Is just so nice. When you’ve chosen to use a pleasant and powerful editor, I don’t see the benefit in depriving oneself of further pleasure and power.
I use vanilla vim when I have to ssh into a server and work on some config files. As such, I much prefer it to nano, and it's installed, or easily installable, on any Linux server.
For that use case, it's absolutely great. No complaints.
I spent years and years enjoying using vim for the same purpose when I was a sysadmin. I was absolutely disgusted beyond belief to find out people actually used it as their daily IDE when I became a developer.
Let's not forget that vim isn't really designed to be an IDE, though. People just like the editor so much they want an IDE with it. Unfortunately using vim itself for that is the wrong choice. The correct choice is emacs with evil mode.
The correct choice is to instead use something that doesn't require a really long time to both learn properly and modify until it's decently functional, even including premade distributions for it, and just using something to get the job done so that, you know, you get the job done instead of preparing to get it done and not getting it done.
Referencing the Gimli glider. But does vim have any analogous issue? In matters of technical correctness FOSS is usually the more exacting. You won't find a 1 TB hard drive full at 931 GB of used space on Linux, for example.
This was supposed to parody how some of Vim's default shortcuts just flat out do not work on non-US keyboards, because e.g. typing [ requires pressing AltGr+8 on German layouts, but Ctrl+AltGr+8 is not the same thing as Ctrl+[.
And yes, it was also a reference to the Gimli glider.
I'm Czech and I use the English layout with UCW accented letters accessible via AltGr. It's much more convenient than tke standard Czech keyboard, even outside of Vim.
"This airplane is the choice of professional pilots! The first thing we advise you to do is turn the yoke upside down, it's much more ergonomic like that. Also, you probably want to rip out the altimeter and replace it with a custom one that has more features. And bring your own GPS unit and tape it to the windshield, because this plane doesn't have one by default. And of course, remember that unlike in your car, 'left' actually means right in this plane. This is the professional way. Ah yes, when you fly over Canada, you will see a blinking warning sign telling you that you're out of fuel. That's just a small glitch caused by metric/imperial confusion. It has been known for 23 years but we haven't quite gotten around to fixing it yet. Don't worry, this plane is still excellent for professional pilots. If you feel otherwise, you are probably not a real professional."