The promise with Vim (and Emacs) is you'll never need to switch to something else, and the skills are transferable (script with Lua, keybindings very often available in other apps). Interestingly it has helped me most with cli stuff, I can edit command lines much quicker and have even configured a keybind my shell to open the command line in Vim for editing.

If a terminal-based workflow is not your thing it's a tougher sell.

If you're a lifelong programmer the time it'll take to be proficient in Vim is a drop in the bucket in the grand scheme of things.

A tool that can last a lifetime and be used for any programming language at that.

It's just a trade-off between optimizing for the short-term or the long-term.

> If you're a lifelong programmer the time it'll take to be proficient in Vim is a drop in the bucket in the grand scheme of thing

I just don't see it? I spent a good 6 months only using vim to see if I could get it to stick. Then I took a year break. After the break I forgot nearly every shortcut I was using minus a select few. I never got to the point of even matching my efficiency in other editors, let alone surpassing them.

6 months alone is already more than what I would consider worth in regards to time spent learning a tool for the little gain I see it bringing over just using intuitive, albeit less efficient, alternatives.

I mean, it's kind of expected to forget about them if you took a break for a year after having used it for 6 months?

I do think 6 months should be enough to see some benefit in your workflow (like ci" to delete everything between "" and go into insert mode or Ctrl-O to go back to the last place you jumped from).

But I guess it depends on how you practiced, and if you look at those 6 months I'm sure you'll see that the time spent on actually learning Vim (struggling to learn these efficient editing patterns) was much less than you'd think.

With a tool like Vim I don't think it's enough to just use it, but we need to put conscious effort into it to learn it properly.

I spend most of my time inside a terminal and have my shell configured so line editing is as much like Vim as possible. Also configured Vim modes everywhere else possible.

Also, although historically that hasn't really been part of the Vim ethos (compared to Emacs at least), you're expected to mold your editor over time to suit your needs exactly.

If you value your time that way, you should re-consider (neo)vim. I learned vim in the late 90s. I still have stuff in my config from that time period, that still just works. It's an up-front cost yes, but I see it similar to a carpenter learning to use a hammer - it's a skill that carries forward for at least a quarter century.

In the same time period, I've watched plenty of my cohort jump between IDEs and "modern" editors as they come and go (jetbrains, visual studio, textmate, sublime text, vscode, the various storm ides, etc etc). They all have to put time and effort into getting comfortable and proficient in each of these environments. That time adds up to be more than my initial vim investment.

Now I'm one of those folks that likes to master my tools and craft my own tools as well, so I've continued to invest time in my vim mastery. The same argument applies here too: that time is cumulatively increasing my skill at the tool rather than getting to the same point with various tools (cf the old interviewing dilemma: does this person have 5 years of experience or 1 year of experience 5 times). It means that some years I don't spend any time thinking about my vim setup, and other years I'll throw a few hours at it - importantly, this happens when I want not when the tool decides to release a new version that breaks things, not when theres suddenly a new great thing I have to use to keep up.

In summary - from a time/effort efficiency point of view for the course of a career: vim wins because the tool was there when I started, and its still here long after the "better" alternatives have come and gone (or faded into obscurity).

It's a weekend of learning for a tool that you use your entire life. Any computer scientist should realize the power of amortization.

I'm a dev that spends 90% of his computer time with a JB IDE open and I'll give you my perspective on it. It just works out of the box (or with a couple of 1-click install plugins) for practically all my use cases.

* I mostly write Kotlin/Java for backend, desktop and Android projects. JB has that covered: Gradle integration, refactoring, navigation, dependency updates, documentation viewer, visual git log/diff/merge/rebase/blame, visual Android layout editor, visual JavaFX/Swing layout editors, run configurations, step through debugger that shows current variable state on top of my source code, all the android resource/variant stuff, test runners, trigger tests from source code, tool windows for docker (compose) or other services and probably much more.

* I do C/C++ development on some projects in Clion which has most of the stuff from above but :s/Gradle/CMake/g.

* Aside from the above I also use my IntelliJ Ultimate for Python, Ruby, Golang, Rust, Markdown, Mermaid graphs, Kubernetes yamls and Terraform hcl files, Lua and probably some more. All with the excellent IdeaVIM plugin so I have my modal editing and ex commands.

I gladly pay $600/year for all this. If I have to spend one day (likely more) on configuring vim/nvim to even do a subset of what I mentioned, then JB is cheaper.

So, that is why I switched from years of Vim use (and a couple years of Emacs before that) to JB and I haven't looked back. I don't see why I should artificially limit myself to vim/terminal only when JB+IdeaVIM gets me the best of both combined.

Purpose built tools like jet brains IDEs are super nice. What I like about an OSS terminal based editor is that all of the languages, frameworks, etc you listed above may change in the next 10 years. Or 5 years. And again that many times during my career. I'd rather not have to retool each time that happens. I like being able to jump into some area thats new to me, like data science or graphics, and have my existing tools just work (other than proprietary stuff like iOS dev).

You're paying about a minute every time you have to wait for your IDE to start. That quickly adds up.

<15 seconds, yes. Once a day in the morning when my machine boots and I'm brewing my coffee.

I've had systems were the IDE starts up after the OS boots and the OS is only shut down for security upgrades every few months.

Different workflows.

I do not know how your brain is wired, but vim is certainly not a weekend's learning (speaking from experience).

True, it was like half a day of extensive coding for the basics, a bit of cursing, then about two weeks of settling in and then a few hours over a couple of months, when I did heavy extension and configuration.

Bonus: my window manager has similar keybindings these days

Yes, do it this way. When I learned vim, I just went to work and decided to use it one day. The only thing I did was get on Stack Overflow and look up how to turn off the arrow keys, so I would have to use hjkl.

As you said, by the end of the workday I was very comfortable with basic vim use.

Print a sheet of basic commands, tape it to your monitor and off to the races.

While a weekend is quiet an exaggeration (2 weeks of 1h/day practice is more likely), the point of amortization still hold.

I absolutely want to learn VIM but saying it's only a weekend is plain misinformation. We're definitely looking at months of gradually building new habits.

Agree, and I would add that it's not just habits, it's committing to rearchitecting your workflow. Do you use things like debuggers, linters, refactoring tools, project management tools, etc.? Get ready to learn totally different tools (usually)!

I'm a committed (neo)vim user, but I readily admit I only got over the hump because I thought it was cool and hardcore and typing is easy for me. There's no question it's been worth it for me, and I would argue it's probably worth it for most people and better for the software ecosystem as a whole (GUI tools don't compose), but still I think trying to say one's better than the other is too narrow a view.

I think the difference between your and the other opinion is what does "learn vim" mean?

Is it enough to know how to enter insert mode, make an edit, then save and quit? That's easy enough to learn in a weekend.

Or is it learn how to edit efficiently using the various vim commands? That will indeed take much longer than a weekend.

(Even getting it configured just the way you want to will probably take more than a weekend...)

You're correct. I learned enough VIM to use it as my Git commit message editor. Beyond that... it's a journey as you said.

> Is it enough to know how to enter insert mode, make an edit, then save and quit? That's easy enough to learn in a weekend.

That's Notepad level usage, you don't gain anything from it.

I wouldn't say so.

The basics are very simple. You just get used to formulate a (weird) sentence of what you want to do in your head, abbreviate it and then learn (or configure) the buttons.

The problem here is the "just" word. To you it's "just" (as in a day or two), to me it's "I have to learn to think in a new way and that will take a while".

Filter bubbles, dude. ;)

True, I love to learn and especially learn new ways to think.

Everything is just a just for me ^^

You don't need to be super-optimal to use Vim. I've used it for decades and I don't care about being optimal or what to "save effort" in terms of efficiency. I use it because I like it. :)

It's much more than 1% though.

That's a claim no real study ever has measured to any truly scientific degree.

So it's just a claim.

Just as 1% is just a claim. At least my claim is not as absurdly specific.

I think you can be productive in an IDE. But when it comes to vim (have been a vim-only user since 2013-2014) there is not a comparison really.

Every time i do pair programming, i always get the "wow how did you do that?!?" response. It's just SO much ahead of an IDE in so many ways. Modal editing (imho) is far superior to "just insert mode" style of text editing.

With neovim (and vim + coc before that) i get 95% of what an IDE could give me, and the last 5% (like some obscure refactoring stuff) is something is would probably never use.

TLDR. I think learning vim is like learning SQL. It's a cross language tool, that will massively benefit your entire career.

Easy. You can have vim bindings in both, while still retaining modern tooling integrated within.