[ilovecaching]

I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging. I am very glad that neovim is also making things EVEN BETTER with tree sitter and baked in LSP support.

So I get 98-100% of what an IDE gives me, I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel, it starts up instantly, and it's completely free and open source, not driven by a corporation, and there's decades of documentation on how to use it.

Edit:

I really don't understand the comments of "I will literally not spend a single minute configuring my editor". I guess it's the systems developer in me that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career.

I personally consider my investment into Vim one of the best I ever made. If dumb college me can do it in a few weekends, you can do it. I recently setup Emacs and got it to the same level as my Vim usage in about two days of tinkering just for fun. Then again, I suppose some people are just here for the money and want to clock in and clock out as fast as possible. I really wish I could share with you the joy of tinkering, learning, and growing your knowledge about how these wonderful machines work.

[blowski]

> I will never understand why people choose VSCode/Jetbrains over a terminal based editor.

I don't want to use my valuable time learning how to get vim working in some super-optimal way that's hypothetically going to improve my productivity by 1%. JetBrains consistently works well enough for me that I'm not going to bother switching. 90% of my life is spent thinking about how to solve the problem so the editor is not the main constraint.

[lambdaba]

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.

[lawn]

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.

[xboxnolifes]

> 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.

[lawn]

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.

[lambdaba]

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.

[sophacles]

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).

[ilovecaching]

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

[zorr]

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.

[escot]

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).

[xigoi]

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

[zorr]

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

[oblio]

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.

[mynameismon]

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

[OtomotO]

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

[ARandomerDude]

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.

[jethro_tell]

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

[unrealhoang]

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

[pdimitar]

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.

[camgunz]

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.

[lawn]

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...)

[pdimitar]

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.

[oblio]

> 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.

[OtomotO]

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.

[pdimitar]

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. ;)

[OtomotO]

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

Everything is just a just for me ^^

[kzrdude]

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. :)

[colordrops]

It's much more than 1% though.

[oblio]

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

So it's just a claim.

[colordrops]

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

[phplovesong]

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.

[roguas]

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

[DavidWoof]

I could ask the opposite: why do people choose terminal vim when you can easily add nvim integration to editors like VSCode and get 98-100% of what vim gives you along with much easier configuration of all those extras you mention like autocomplete, hover reference, refactor, etc.?

That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a feature in nvim still means researching and configuring it where in something like VSCode you open a new filetype, it asks "do you want support for this file", click yes and you're ready to go. I can spend a few days trying to get vim to work in the way I want it for a specific filetype/framework, or I can get 90% of what I want from VSCode in 30 seconds and still have vim navigation and command support.

[cylon13]

I find Coc.nvim plugins for neovim are virtually just as easy to set up as VS code plugins, VS code is a power hog and performs worse, and the vim bindings are rough around the edges with macros in particular. VS Code with a vim plugin is not a bad experience, but neovim+coc.nvim is just much snappier.

[DavidWoof]

That may be, but this is the first time I've heard of coc.nvim and I've used neovim for years. So I'll bookmark this and at some point I'll look into it and do some research and figure out how to configure it and compare it to competitors, but is all that really worth the very slight performance advantages we're talking about? I can't type 1000wpm after all.

Sure, VSCode is a power hog and it's slow, but I make pretty good money so the cost of a more powerful development machine is trivial compared to the opportunity cost of doing all that research. Some years I really enjoy learning all about new ways to configure vim/nvim, but I recognize that it's really not an efficient use of my time, it's just been something I do more for fun.

[cylon13]

Yeah I agree about it being something that's done because you enjoy it. Talking about what's an efficient use of time is so strange to me though, not to single you out in particular. It's like we're pretending our lives are so hyper-optimized that everything is a delicate trade-off. I spend a few hours here and there messing around with my setup because I want it to feel nice to use. It's not like I traded a couple hours of productive programming time for that. Sometimes I spend a few hours watching a movie.

For me a snappy editor experience, and vim in general, is about comfort, not optimizing for some theoretical top editing speed. I don't think I'd be a drastically worse programmer if I were forced to use windows notepad to edit code, I would just be more uncomfortable all the time.

[elpatoisthebest]

The 100% full reason for me was that I had a job where I needed to SSH into our prod server about once per month and tweak some files. I was so terrified every time I had to do it because I was afraid of vim and/or nano in those situations. So I decided to get competent so I trusted myself not to make huge mistakes.

After about a week of using vim it clicked and I knew I couldn't go back to Sublime Text.

As for VS Code, I do everything I can to keep Microsoft products out of my life.

[DavidWoof]

> The 100% full reason for me was that I had a job where I needed to SSH into our prod server

Statements like this are common, but they confuse two usages: (a) learning vi/vim well enough in order to use it in any unix environment vs. (b) using vim with a complete plugin/config suite as a primary development IDE replacement tool.

The former is IMHO an essential unix skill, but it's incredibly inefficient to try to use core out-of-the-box zero-plugin vim as a primary development tool. But once you start configuring an efficient dev environment, the GUI editors start to really outshine vim, and they still provide core vim functionality via plugins if you want it.

[elpatoisthebest]

That's a totally fair point, and I realize my comment wasn't really in the spirit of that original thread in the first place.

What I really meant to convey is that I dipped my toes in just enough to get familiar, and that was enough for me to get fully hooked on vim. I've spent lots of time trying to make Jetbrains/IdeaVim and VSCode/vim-plugin work for how I write code. Significantly more than I want to admit publicly...but I come back to the boring old terminal every time.

I am not trying to convince any person on this planet that they should use vim. In fact, when other developers at work ask me if they should try I say "No" 100% of the time. But Jetbrains/VSCode are a firm step down for my workflow.

[Fnoord]

You can use Sublime Text remotely though, just requires some effort to set up.

My issue with Vim is remote servers and containers never have my (awesome) config.

It still pays off to know some basic Vim keybinds. You can often use them in other applications and every once in a while some machine only has vi. That said I grew up with DOS, do ctrl keybinds feel natural to me. Its just nigh annoying switching from macOS to Linux given the position of ctrl/fn/alt/super are different.

[jambutters]

vscode is open source, there are forks(vscodium) where all the microsoft stuff is removed and you can audit it yourself if you think its sending tracking data back

[mekster]

Initialize git and commit on the dir before touching them.

[lc9er]

I used this combo for a while, but there was a period of time where VSCode updates would break the vim integration. This was a few years ago, and I’ve recently reinstalled VSCode for use with F#, since Ionide seems to work better than in Neovim.

[ylyn]

> I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel,

I can use VS Code in the browser: https://github.com/coder/code-server

> it starts up instantly,

I launch my editor once a day. Why do you need to keep killing and starting your editor?

> and it's completely free and open source,

OK, so is VS Code, or at least the OSS version, which has all the key features anyway.

> not driven by a corporation,

So this is your philosophy.

> and there's decades of documentation on how to use it.

Most of it out of date, probably.

> I guess it's the systems developer in me

Guess what? I'm a systems developer too! I also work on the kernel! But I use VS Code.

> that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career

VS Code is open source, so there's nothing stopping me from diving in if I want to. And it's also highly extensible.

Now that I've answered all the supposed benefits you list about (neo)vim, I have one question:

Can (neo)vim show text in two different font sizes? Or fonts? Like, what if I want my documentation popups to show up in a sans-serif font? No, don't tell me I have to open up the documentation in a browser or whatever. I want it in the popup.

[ilovecaching]

Linux newbies jumping into Microsoft's arms is still something I'm trying to wrap my head around.

[cercatrova]

Tools are tools. If they work well, great, if Microsoft tries to wreck VSCode for some reason, then people will switch.

[picardythird]

Emacs would like to have a word. But seriously, that would not be an important feature to me. Obviously everyone has their preferences.

[snowram]

Same reaction but in the opposite direction. I still do not understand why some people are that obsessed to dedicate a large amount of time learning a software that will sometimes make their life a tiny bit easier in rare edge cases. Every time I try to learn how to use Vim as an IDE, I just end up massively overwhelmed and never even come close to reach a fraction of my productivity on VSCode. The fact I cannot see the benefit where others can is frustrating.

[lambdaba]

Most people I know that use Vscode now are coming from TextMate -> Sublime Text -> Atom -> VScode.

Meanwhile my Vim go brrrrrr :D

Seriously, there's a huge benefit to not constantly switching and learning new environments (admittedly since Neovim / switching to Lua for scripting Vim there's been a lot new but all things the community wanted)

[mypalmike]

Seriously, there's no benefit to sticking with one environment. The right tool for the job. If you're doing Java for instance, no version of vim or emacs comes close to the functionality of the popular IDEs. With vi perhaps you can type more efficiently. With a good IDE, you can develop far more efficiently. For modifying bash scripts on remote machines, vim all the way.

[lambdaba]

I could agree with you a few years ago but since LSP and Tree-sitter the tables have basically turned, I'm pretty confident you can get _more_ IDE-type features in Neovim (albeit with some amount of effort, no doubt). But, again, you can tailor that exactly to your liking.

[rektide]

From a thread on minecraft[1]-

> it is intensely gratifying to build and improve the world around you.

For many of us, we expect we will be spending a significant chunk of our lives in the text editor.

Picking a dumb, inert, fixed, limited text editor is an apalling choice to some, versus picking something that has rich means of working the system (text objects, spellcrafting on the fly!!!) and infinite possibility (that flexible configuring, leader keys of possibilities). Picking a starting point where more is possible, where building & growing our world can be done- it's a path of lifelong struggle, but immense lifelong gratification, one where we will see our world florusihing and ourselves growing within in.

I personally resist a lot of the configuring & addition of plugins, am only an ok advanced vim user. But Im pretty ok at writing macros when i have a shitty chore, i make use of registers to handle reusable text- I appreciate having something much closer to a programming language than a input box at my back, and i keep slowly improving.

[1] https://news.ycombinator.com/item?id=31038449

[dotnet00]

One big benefit from my perspective is that due to being terminal based, vim makes it much easier to edit remotely and makes it relatively easy to bring your environment around.

While vscode's ssh option is cool, it still requires that you have it installed on your local machine and while the web based version doesn't have that issue, it's missing other features (like ssh).

So for me the biggest motivator for switching to nvim has been the ability to connect to my machine and work on code from any device (ie even android) anywhere, only needing access to a terminal, and if I need to work on someone else's machine, having my environment there is as simple as cloning a git repo with my .vimrc

[lazyier]

I don't know why people would use a text editor in a terminal when they can use that same text editor as a desktop application.

Fonts are better, colors are better, it is faster, less latency, running a terminal inside your editor works better, pop-ups and overlays work better/are more flexible/easier to read, mouse interactions work better, resizing works better, it is easier to run multiple windows, it is easy to run multiple different fonts with different font sizes, etc etc.

I also don't have to figure out solutions to conflicts between the keyboard shortcuts between the shell, the terminal, the terminal multiplexer (screen/tmux/tabbed terminal emulator), and the editor.

> I can use my editor over ssh and edit anywhere

I can just have my editor use ssh to edit files anywhere. Remote editing is a thing.

Anyways for proper system hygiene you shouldn't be shelling into anything except to troubleshoot problems or for checking things you don't have monitors in place for. This is why we have things like ansible or puppet.

In fact the whole insisting on having an editor in a terminal emulator thing is probably holding Nvim back as a whole. Which is why you don't see the obvious benefits.

Since the community wants to use terminal emulators so heavily then all the add-ons and features of the editor must support the lowest common dominator between desktop apps and terminal emulator, which is almost always going to be the terminal emulator.

Just remember that you are not avoiding a GUI by using a terminal emulator. It's still a GUI. Just a GUI designed for running command line applications in a Unix-style shell. And Neovim really isn't even a command line application.

[kldx]

Thank you, I agree with this perspective. The content density from a professional IDE is higher than what I get from a terminal editor. I can't imagine tooltips using the same font size as the rest of my code. I don't like it when the UI elements use monospace fonts.

[Barrin92]

Integration. The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth.

Vscode or Jetbrains or any other integrated software is from the ground built up to have its tools work together 100% of the time. I like vim fine if I edit something without any plugins needed but otherwise I'll stick with an IDE. And if I want vim controls I'll just turn them on the IDE because conceptually for me it makes more sense to port keyboard controls to an IDE than to port the entire IDE to a terminal

Practical example, look at the instructions to set up an ide-like ocaml environment with neovim[1]. It requires basically to install half a dozen tools by hand and to fix the linter config before you've even started. In VsCode it's literally one click.

[1]https://www.rockyourcode.com/setup-ocaml-with-neovim/

[mjlbach]

> The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth.

Any issues with the language server I doubt are client side, and every request/response is "async".

For a minimum setup it is:

1. Install the language server via opam:

  opam pin add ocaml-lsp-server https://github.com/ocaml/ocaml-lsp.git

  opam install ocaml-lsp-server

2. Add lspconfig, the plugin

3. Add the following to your init.lua

  require'lspconfig'.ocamllsp.setup{}

4. That will give you basic linting, you can add keybindings/omnifunc integrations by copying out our configuration examples from `:help lspconfig` or the lspconfig wiki.

We're not trying to target vscode users, so if the above is too many steps that is ok, you just aren't our target audience.

[annowiki]

The debugger.

I made your same argument for years to a buddy of mine that always used WebStorm (I'm a Python dev and he kept pushing me to try PyCharm). A coworker pushed me to try PyCharm since we're on Windows and I haven't really looked back. I even bought CLion.

If you can point me to an easy debugger to set up in neovim I'd probably be right back, but I can't. Couldn't figure out how to set up vimspector. And in PyCharm, at this point, I find it has better tooling than coc (I haven't wanted to spend the time setting up LSP/treesitter).

Furthermore, doing development in wsl isn't that great in my opinion and native windows neovim isn't either, even when using Windows Terminal. Its slow when handling a massive repository. FZF with ripgrep still works massively faster than telescope for my main work repository. I mostly dip into wsl when I want to do complex grep/sed/find operations and to make edits to my hledger timeclock sheet.

But one thing I've found to be a killer app for Pycharm Pro: vim keybindings in jupyter notebooks. Works way better than the plugins for Jupyter Lab.

IdeaVim is sometimes kind of disappointing, I wish JetBrains would just add a neovim plugin (I want to use vim sandwich instead of vim surround but alas). Still, it's good enough.

[davidkunz]

Debugging in Neovim is quite simple, I recommend nvim-dap, I made a few videos:

https://youtu.be/ga3Cas7vNCk

https://youtu.be/SIYt1dopfTc

If you prefer Vimspector:

https://youtu.be/-AZUIL1rY3U

[wussboy]

I watched your first video. As someone who likes the idea of Vim and has learned many of the keyboard shortcuts, my impression of the video was "Debugging in Neovim is quite simple. Just remember these 35 keyboard shortcuts."

[davidkunz]

That's true, it requires a bit of memorization and configuration. I've put the shortcuts similar to character movements: CMD + j,k,l (jump over, jump out, jump in).

[nobleach]

I've mentioned this to several others (and also as a response to David in the past) but I highly, HIGHLY recommend anyone who's just getting started with nvim-dap, watch these videos. They helped me immensely when I was first getting it set up.

Thank you David, they're a fantastic overview of these plugins!

[davidkunz]

Wow, thanks so much, I'm humbled!

[wyclif]

I knew I'd watched the first two videos at some point because when I opened this page, those first two links were the only ones greyed out. Good stuff.

[davidkunz]

Thank you!

[ilovecaching]

Vim added a debugger plugin that is installed by default called termdebug.

I work on kernels and various pieces of the boot process, so my needs when it comes to debugging aren't a typical case.

[baq]

I've been a hardcore vim user since early 2000s. I've switched to VSCode a couple years ago and haven't looked back.

My .vimrc clocks in just below a humble 500 lines. VSCode gets me more with practically zero configuration out of the box; a few clicks to install relevant language extensions and that's it. It's more stable and more performant on large files (e.g. 2+kLOC Python modules). RemoteSSH and RemoteWSL plugins are 100% pure gold.

[paskozdilar]

Vim/Neovim/Emacs/etc. require a certain "commitment" to them - you have to learn keybindings, for example. Moreover, if you want any fancy IDE features you're addicted to, like hints, autocomplete, static analysis, refactoring, etc. you have to configure it yourself, which still isn't quite straightforward as selecting a plugin in VSCode (perhaps this is a good feature idea?).

Most people just don't think it's worth it, when the existing tools are Good Enough for them.

But once you pass the initial obstacle, vim/emacs/derivatives are really nice to use, and there are plugins for literally anything out there.

[mekster]

> you have to learn keybindings,

Are people seriously training their muscle memory to the default vim keybinding that is so cryptic I don't know what to say.

Since the early days of learning vim, I've changed the "go to end of line" bound as "-" which is next to "0" for "go to start of line" which is way more logically placed than some "^" that even needs shift pressed.

If anyone thinks "because default works on any machine", you need to think how you're wasting your brain cycle on unnecessary complexity for no reason.

[polyamid23]

For me, "because default works on any machine" is a valid argument for some things and for others it is not. jk = Esc is so crucial, I can not live without it. Start of the line on the other hand is just `0w`, so not that clunky. I guess it depends on how much time you are spending on what amount of different machines :) These "muscle memory produces some weird result" vs. "this keybinding is not very convenient" also affect my thought process in different ways. The first one disturbs me much more for some reason.

[paskozdilar]

> Are people seriously training their muscle memory to the default vim keybinding that is so cryptic I don't know what to say.

Nobody does that on purpose. It's just a side-effect of learning Vim.

[mekster]

Why do you accept it as a given and not customize it?

[paskozdilar]

Because I don't think the difference is worth my effort.

[d0mine]

There are preconfigured emacs distributions such as Doom Emacs https://github.com/hlissner/doom-emacs#doom-emacs

[xigoi]

On the other hand, in IDE requires commitment to using only a few select programming languages.

[ilovecaching]

There's 0 configuring. It's as simple as installing one of the many LSP clients, like ALE, that will automatically detect and start a language server for you with the right arguments.

[guhidalg]

You and I must have different definitions of "0 configuring". There is no "one" LSP client, so every time I want to spend time training my vim muscle I have to research basically which one [is the best/has the most problems or users], whether the language server works well with it, figure out which plugin manager I should be using, write down and remember the shortcuts to invoke my plugin manager, set up key bindings, set some more configuration flags, then maybe have something working by the end of the day.

After all that, yea I'm more productive but I think the large barrier of entry to CLI editors is what keeps people using IDEs and their Electron cousins.

[mikub]

Installing an LSP is already configuring, so it's not 0.

[paskozdilar]

If that's true, I'd really like to try that. I've never heard of ALE, so thanks for that.

Still, the fact is that you have to know what to install. It's not like the NeoVim manpage mentions any LSP clients. So it requires a lot of tinkering, reading and participating in the community to figure out how to do stuff. That's exactly opposite of 0-configuring.

If NeoVim could bundle an LSP client with it, and have a config key to enable it, that'd be dope.

[mjlbach]

Neovim does bundle an LSP client.You can launch and attach with ~6 LoC. See `:help lsp`

https://paste.sr.ht/~mjlbach/1a1df5cd61627e87ea4c4355a0473bf...

[paskozdilar]

I did not know about this. Thanks!

[mjlbach]

Of course :) Lspconfig adds an autocommand that does this for you when it detects the filetype, and includes the start commands (that's it, all the other functionality is in core.

[heydonovan]

Could not disagree more. For entertainment purposes, I've installed neovim with `brew install neovim`. Opened a small project with `nvim ~/projects/whatever`, and am presented with a screen full of errors (https://imgur.com/D0ydDIG). Pressing enter brings me to a blank screen with even more errors. It then drops me into a vim document with some modal screens and now now I'll probably spend hours researching what all these mean, why this is happening, etc.

All those features you've listed aren't anywhere on the homepage, how does one even do that? I'm interested in learning more, but to think one can do this in a weekend just isn't true.

While I'm sure I could figure out all these kinks, its just software, it's the time sink that makes me pause. I don't see the value here, but I also don't know what all it can do compared to my current workflow with VSCode.

[jethro_tell]

That's a brew packaging problem. Haven't used it for years but it happened enough for me that I just went to Linux where packaging wasn't an issue.

[LVB]

I held this view too for quite a while. But in recent years as I’ve been exposed to some really powerful features in VSCode and GoLand, I’ve adopted a much more flexible workflow. I always have my CLI editor running and might spend the day in there, but I often have an IDE running in parallel (with Vim bindings, naturally). By now I automatically switch between the two based on whatever is the better platform for the immediate task, and have let go trying to load up Vim beyond basic LSP.

[mbernstein]

Neovim is amazing but recall how long it took you to get used to vim keybindings. It isn't something you master overnight. I recall it took me a few weeks to get comfortable. Lots of people are perfectly comfortable not using keyboard navigation.

Edit: Also to note - vscode supports editing files anywhere over ssh as well, so there isn't a huge advantage to neovim there.

[ilovecaching]

Except that I can use vim on my iPad Pro with just a terminal app, which I can't do with VSCode. Vim is portable anywhere you can get a terminal connection, even if it's over serial.

[stnmtn]

While it takes more work (and probably won't work over SSH), looks like there's a neat way to host a vscode server and use and Ipad as a client of it: https://medium.com/swlh/vs-code-for-ipad-and-other-phones-an...

[petepete]

At this point I'd use recommend Codespaces. I taught some of my less techy colleagues how to make content changes with it and it was a breeze.

[mekster]

If vim or neovim can work as featureful as JetBrains, I'll switch any day.

Let me know how to highlight SQL in strings and make tables linked to remote database over SSH and autocomplete table names and column names as I type. And make sure that its grammar is checked against specific RDBMS's available syntax.

And I also want code formatting that's not entirely opinionated, so I can decide what gets wrapped and what gets indented and let it format an entire folder with a shortcut.

And if I'm setting the project to use PHP 8.0, make sure to highlight features I've mistakingly used from 8.1, so that I don't get runtime errors.

And if I'm editing files over SSH, make sure that if the remote file is changed, it warns me before I upload a local version, so I don't accidentally overwrite any remote changes and give me the option to merge.

And for sake of being right, in PHP if I have a function paremeter set as a string, highlight "is_string" check on the parameter as redundant, so my code doesn't look dumb.

I probably have others and even more that I'm not even aware of from its feature lists that can be useful over what vim/nvim can offer after taking some months configuring it to my liking.

I suppose you're comfortable missing out on those?

vim to me is a server config editor.

[wing-_-nuts]

I like using vim as an editor. I don't bother with janky plugins that require some arcane blood ritual to install, configure, and be invoked. I'm not going to go through the trouble of setting up vim as a java ide when intellij does that intuitively out of the box.

If I just need to edit a file, or view it, I'll often use vim. If I need to sit down and actually code? Intellij every time.

If vi had never existed, and you introduced it today, people would think it was some sort of april fools joke of an editor. It is the least intuitive and user friendly piece of software I've ever used. The only reason I continue to do so is because I've learned it's quirks and it's stockholm syndrome now.

[JodieBenitez]

> I really don't understand the comments of "I will literally not spend a single minute configuring my editor".

It's really not difficult at all. I and others have probably a million things we would like to tinker with (yes, including tweaking a text editor), but we all have a limited time so we end up with priorities. It just happen that I didn't make a priority to tweak vim/neovim because I'm happy with my current code editing setup. For other kinds of software, I may not be happy at all, to the point of writing my own.

See: different people, different expectations. Your choice being right for you doesn't mean it's the right choice for everyone. Tolerance 101.

[harha]

Maybe because it’s all easy to find. You don’t need years of experience, just search for the plug-in you need. Sure it’s probably worse, not really portable and possibly insecure, but the barriers of entry are so low that it works great for most people.

[rwnspace]

Precisely this, kitted-out vim in the hands of someone experienced is a force multiplier but it's uh, 'late-game'. VSCode and the like take absolutely minimal brainpower and experience for near-enough similar gains (for most users, I would say).

I say this as someone who uses both the editors I mention depending on context.

[ahallock]

I've used Vim for 20 years. My main issue is that, while I love the text editing part, setting up something aesthetically pleasing with IDE-like features takes a lot of effort -- especially when you're dealing with multiple layers of shell + iTerm2. Some even add tmux on top of that! My setup still doesn't look on par with the amazing setups I see on Youtube. There are too many low-level settings you need to mess around with and it's completely unintuitive.

[ahallock]

Felt inspired to look at this again and there is a project called LunarVim which advertises giving you an "IDE" experience out of the box. Looks promising!

[brightball]

One of these days I really need to sit down and commit to learning to use Vim at this level. I always use Vim when I'm editing from a terminal but generally stick with VSCode or the Jetbrains family of IDEs for any real coding projects.

I've just never gotten around to learning vim in a more advanced way than edit, replace, copy paste, skip to line and search.

Any good suggestions on where to start? I looked at Spacevim but that seems to just throw everything at you.

[auslegung]

I highly recommend following this author’s advice https://medium.com/actualize-network/how-to-learn-vim-a-four...

It’s a pretty gentle introduction to vanilla vim over 4 weeks. After that point I’d recommend using nvim and all the plugins you want to make life easier, but learning The Vim Way is very powerful

[davidkunz]

I think it makes sense to start from scratch and learn new features step by step, otherwise it quickly becomes overwhelming. I made some videos on how to configure Neovim, maybe you'll find it useful: https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...

[brightball]

Thanks! I'll check them out.

IMO that approach makes the most sense too.

[lambdaba]

For "base" Vim (pre-neovim), the Practical Vim book and Vimcasts by Drew Neil were very helpful.

To get the muscle memory, try blocking the arrow keys in your config or even hiding the cursor (I'm serious, I once had this unintentionally and realized that because I was so used to Vim movements I didn't even need to see the cursor in normal mode).

The vim way is: stay in normal mode, learn to move efficiently with searching, jump to char, forward/backward words etc.

Don't use a prepackaged config. Refrain from plugins until you know for sure what you want.

[Aissen]

I prefer using (neo)vim, but I find it a bit disingenuous to ask such a question. LSPs wouldn't exist without the investments made in VSCode. I'm grateful for this technology aimed at bringing IDE features in any editor (instead of being silo-ed), and don't really care if most people prefer the comfort of integrated environments.

[fi_do12]

Question to those who are using both NeoVim and an IDE like VSCode/Jetbrains:

Suppose you're using VSCode/Jetbrains with proper keyboard shortcuts (stuff like expanding selection, search/highlight all matches, ...) - basically never using the mouse. Is navigating / editing with NeoVim really that much faster?

[wyclif]

Just curious: you mentioned SSH. What is currently the optimal way to setup vim/neovim over SSH and carry all your configuration over with you to different servers?

[xigoi]

Just use your favorite version control system?

[JodieBenitez]

Surprise ! Different people have different expectations.