[anpep]

Should I take this opportunity to switch to Neovim for once? I've attempted using vim/neovim/emacs, etc. many times but it's just so confusing to me.

Why would I go over the trouble of debugging my editor for simple stuff like having LSP completions and semantic highlighting? It's insanely difficult for me to wrap my mind around vim packages, configs, etc., when VSCode/GoLand/et al. do a pretty darn job being decent editors that you don't need to hack on and just work out of the box.

Don't get me wrong, I'm not throwing shade on vim/emacs, I'm just wondering what am I missing since everyone's been super happy and productive with vim for ages, and if I'm approaching these tools the wrong way...

[bartq]

Friend... don't try to "switch". Just use multiple tools at the same time. I personally use all: Neovim (great writing/editing experimence, LSP+Treesitter+fzf allow you to get really far), Emacs (for Magit), VS Code (if Neovim or Emacs breaks I can still edit the code ;)) and WebStorm to run tests using nice and rich UI. Don't try to limit yourself artficially.

[zeroDivisible]

I have almost exactly the same habits when using editors mentioned above. I'm not sure if I've been using Vim (neovim now) or Emacs (+evil) for longer, but both have great reasons to be installed at the same time.

[newlisp]

Do you use the vim plugins in vscode/emacs/webstorm?

[bartq]

No, I use Emacs keybindings in the rest of the tools. Tried to use vim bindings but they don't seem to do everything correctly or smoothly and it annoys me.

[bartq]

Actually... I use my own keybindings which are more ergonomic twist of Emacs bindings. For example for moving char left I use C-d and to move word left I use C-S-d (control+shift+d). Convenient to press using both hands (using right shift with pinky). Of course Control is swapped with Caps lock.

[wint3rmute]

I suggest you try something like LunarVim[1] or NvChad[2] for a ready-to use IDE-like neovim configuration.

I had the same problem with configuring (neo)vim, it's simply too much work to get a reasonable IDE experience. Using an already well tested and documented configuration helped me to make the switch.

[1] https://www.lunarvim.org/

[2] https://nvchad.com/

[zamalek]

I would recommend against heavy-handed plugins, it's the reason I burned out on nvim and fled to helix. The thing about a breaking change in a plugin (like, oh, I don't know nvim-treesitter - likely the most installed plugin) is that you find out when you are about to do work/be productive.

Keep nvim as minimal as possible IMO.

[gorjusborg]

This guy gets it.

I am also firmly in the vanilla config camp.

Neovim is very usable out of the box. Once you are invested in the interface (modal editing) then look to get 'fancy'.

I think the big config approach just tries to make the editor an IDE. You don't most of that to try it out.

Start simple.

[lenkite]

[3] https://www.lazyvim.org/

[EasyMark]

lazyvim is definitely the one I found easiest of a bunch of these. I've been using it for a while now, I haven't tried in neovide though, I just did and it ran but when I did an update there was a compilation error (on mac). So maybe avoid an update there? :) It was easy to fix in standard iterm2 though (just resync).

[cassepipe]

If only doing C and C++ dev work you can get pretty far with a very minimal vim config though

But yeah, webdev had me switch to Lunarvim (my favorite among all those nvim distros)

[ivanjermakov]

I also suggest against using distributions. Instead of learning how to configure nvim itself you're learning to configure that specific distro.

I suggest to take someone's lua config and start from there. Kickstart.nvim is a good one: https://github.com/nvim-lua/kickstart.nvim

[retrochameleon]

I tried both and ended up using AstroNvim

[unshavedyak]

Any idea if these would be problematic with Neovide?

[zeroDivisible]

LunarVim may require some symlinks but I've ran both with Neovide at some time. nvchad should work out of the box.

[Ringz]

Lazyvim runs fine

[Rudism]

I think if you're happy with the experience that the IDEs you mentioned provide you, then there is very little reason to switch.

Being familiar with vi keybindings can be useful if you ever find yourself on a minimal system with no other editors available, but the subset of knowledge you need in that situation would be much smaller than if you wanted to use Neovim as your primary development environment. I think Emacs/Vim/Neovim and the like are better suited to users who actually enjoy the process of configuring stuff like LSPs and code completions in a way that's fine-tuned to their personal preferences and works the same across all programming languages.

[nsm]

If you are happy and productive with your current editor(s), no, you don’t need to spend valuable time picking up and configuring another one. Save the effort for when you actually need it.

Despite what others may say to convince you otherwise, this is the only correct answer ;)

[cassepipe]

I feel you, I feel the same. I just like modal editing too much. Even though I have to remap CapsLock to Escape to make that usable.

I feel naked without those commands at my fingertips. It's not even about speed, without it it's like... it's like woodworking with a table knife

If I were to take up modal editing now, I'd go for Helix. It's a better editing paradigm (Kakoune inspired) and it aims at just working out of the box.

I finally opted for Lunarvim but I believe all those Neovim distributions are great

[extr]

I'm the same way. I've tried like a half dozen times over the years to "get into" vim. It seems like the perfect thing for me. I used to love wasting time ricing my Arch install. But you know what happens? I get 3 hours into setting it up and realize I am only marginally closer to what I already have with VS Code. And in VS Code if I want more language support or some fancy new feature, it's like 3 clicks and it's just working immediately.

[worksonmine]

Adding language support in neovim isn't very difficult once you're setup. I use nvim-lspconfig[1] and just about any language you could need is documented[2]. But like others have mentioned there are batteries included distributions of neovim if that's your cup of tea.

[1]: https://github.com/neovim/nvim-lspconfig/

[2]: https://github.com/neovim/nvim-lspconfig/blob/master/doc/ser...

[jannes]

kickstart.nvim [1] is the best way to get started if you want to understand how things are configured rather than using someone else's config.

It's a single file and you can pretty easily use it as a starting point for your own config.

And it comes with the which-key.nvim [2] plugin that helps you learn vim motions.

[1]: https://github.com/nvim-lua/kickstart.nvim

[2]: https://github.com/folke/which-key.nvim

[e12e]

I would recommend the helix editor[1].

You won't get the deep magic of emacs, or the benefit of learning vi key bindings (sadly there's not yet a helix mode for gnu readline) - but you get a great modal editing experience, good defaults and great discoverability.

I moved from vim/neovim a while back - and now I find vi/vim verb-object (d[delete]w[ord]) yanky compared hx visual select/object-verb (wd).

I've been using vim for some 15-20 years prior.

[1] https://helix-editor.com/

[n8henrie]

I'm intentionally trying to move from nvim to helix, but I still sorely miss macros, `gv`, `g;`, piping rg to the quickfix list, and a few others. Slowly getting used to it though, the ultra-fast startup time and no-hassle LSP integration is nice.

[e12e]

Hm, i wasn't much of a user of visual mode in vim. Seems something like gv is coming to helix:

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

What does g; do?

Helix has (experimental?) macro record/playback q/Q?

https://docs.helix-editor.com/keymap.html#changes

[n8henrie]

I use visual mode a fair amount for block-wise changes (something that helix does very well).

Unfortunately I reliably labor to get might visual selection correct in helix and then mistype a key and it's gone. Glad to hear it's coming!

`g;` takes the cursor to the location of the most recent change you made (and then the one before that, etc.). <C-o> in helix doesn't ever seem to get it right (unless I remember to <C-s>, which I never do).

Also glad to hear about macro support.

I should take another look at if they are interested in contributors. One of my main interests in helix is that I enjoy rust and don't know C/C++, so I feel like I could maybe "give back." That said, my first issue I raised was not taken very seriously (and is a show-stopper for helix on windows in my case).

[e12e]

Helix claims that "g." should: "Go to last modification in current file"?

[n8henrie]

Wow, that's been there a while: https://github.com/helix-editor/helix/commit/35c974c9c49f912...

Wonder how I missed that. I'm getting a re-education in helix today -- thank you! I'll go through `hx --tutor` again before I insert any more feet in my mouth.

[nequo]

> now I find vi/vim verb-object (d[delete]w[ord]) yanky compared hx visual select/object-verb (wd).

I often use `viwd` instead of `dw` to create a selection before deleting.

[ionrock]

While I can't say this is true for vim, in Emacs, I found that the customizability helps for a lot of different programing tasks. I run my terminals in Emacs and they are associated with my projects. Magit (the Emacs git package) helps me do complex rebases with diffs alongside creating branches and everything else you might do in git (even the reflog when things get rough). There is event a handy rest-mode that lets me write and save HTTP sessions. I connect to my database in buffer as well. What makes all this so handy is that I can move the buffers around to compare things side-by-side, use a single large buffer, etc. While VS Code has splits and terminals, I found that in Emacs I can access everything from my keyboard and now that I've gotten used it, I don't even think about it.

I've heard that a lot of vim folks get similar behavior via tmux and leverage other shell tools.

I'm not going to argue you should switch, because it is an investment. It is like owning a house, you have autonomy but you're also on the hook to fix the air conditioner. You also can't just drop it and move to the next editor. Your hands and workflows become tied to your editor. Keybindings may be similar, but it is not the full story. Either way, it is a journey getting good with your tools, so enjoy it!

[widdershins]

For some people (myself included) the infinite configurability is the selling point, and configuration is the 'cost of doing business'. I'm an Emacs person but I'm sure it's the same for (Neo)Vim people too. You're gradually crafting your editor using your editor, and that feels good.

Along the way there are innumberable little choices that you make that shape it into something completely your own. Plus you know it's never going away or getting enshittified because it's open source and has been for decades.

Now, does it actually make you more productive? Or is any productivity you gain swallowed up by tinkering with configuration? That's an open question, and a valid one. People who enjoy an out-of-the-box IDE experience are fine by me - different strokes and all. I just enjoy working in an environment that is always gradually evolving according to my needs, even if it means putting in the work.

[cbm-vic-20]

I think there's a faction of vim/emacs users who use it because that's all that was available when they started out. vi and emacs are ancient- nearly 50 years old. PCs introuced IDEs (think Turbo Pascal) in the 80s, but there really wasn't anything like this in the Unix or VMS world. So if you started programming for non-PC, non-8-bit machines, you would certainly have encounteded vim or emacs early in your career. I'm one of these people.

There's another faction, of users who have come to vim/emacs in the era of decent IDEs. I think a lot of these people have come in due to the keyboard focus of these vs. IDEs, or because they are very quick and responsive (though recent IDEs themselves are finally really fast, too), or due to aesthetics or because it's percieved as being "hardcore" or "cool".

IMO if you're productive with what you're using now, stick with it. But try other things and see if they click. This goes both for the Unix graybeards and the IDE kids.

[cmrdporcupine]

I'm sort of halfway in your description there. When I began my Unix journey 33 years ago, yeah, that's all that was available. I picked up emacs because I hated (and still hate) the modal aspect of vi, and because I also used emacs to connect to MUDs and MOOs and IRC, and read my email, all in one. On my 486 with 8MB of RAM, emacs did almost everything for me in one place. I grew to really like C/C++ mode in it, especially the way it handled indentation and reformatting at a time when this was actually not a commonly well-done thing even in some of the IDEs at the time.

I then left it backgrounded in my brain for a couple decades, only using it here and there when I didn't have a GUI available, while I used JetBrains IDEs. I couldn't be bothered to do all the customization.

But the past few weeks, I got pissed at JetBrains for the way they're handling the CLion->RustRover transition, and my CLion license ran out and I said f'it, and spent a weekend really tuning emacs for my workflow. And, honestly, it's kind of awesome.

The key point being I can make it do whatever I want really. So the learning curve really comes down to what I put on it. LSP + Company Mode + Rustic Mode + Treemacs + Projectile is a pretty good approximation of an IDE. And then I just went through and tuned it up with the bindings I wanted, adjusting things as I went.

I had never in 30 years invested this much time into emacs before, and it was entirely worth it.

Anyways, the TLDR is: it's not just the "I want to be hardcore" and "I am ancient", there's real practical value to the depth of these tools that's actually hard to get out of other "editors", even VS Code. I can't speak for Vim, I have never liked that way of editing, but with Emacs it's really about building your own lightsabre.

[hiAndrewQuinn]

You need to eat the upfront cost of learning to use vim's keybindings effectively. Once you've done that, you can edit text files quickly and efficiently on any Linux box from the last 30 years or so. Having an editor you can run right in the terminal, Ctrl+Z out of to run some commands, and then `fg` to keep hacking away is an incredibly powerful way to make using the terminal much lower friction.

Beyond that?, I just run LazyVim unmodified. It supports Copilot out of the box, which was my killer feature for it. Last year I even wrote a set of shell scripts I can curl into any new Ubuntu machine to fully automate all the setup for me, which might be of use to you as well, if you want to skip all the configuration. It also installs fzf, fd, rg, and a whole bunch of other useful tools all at once.

https://github.com/hiAndrewQuinn/shell-bling-ubuntu

[cmrdporcupine]

Can't speak for vim, but with emacs it's a lot like building your own lightsabre. If you want to invest the time, it can be very rewarding, as you're basically building your own tool chest full of your own customized tools.

But it does take time, and doesn't come "out of the box" with the creature comforts you're probably used to, and has "weird" ways of doing things that are very old but there's usually good reasons for them.

[zjp]

What I like about Emacs is that there are a lot of opportunities to automate away little things. For example, you can make it update copyright years automatically or define a template that will be automatically inserted into all files of a certain type under a certain directory (and that text is itself programmable).

What I like about neovim is that it's as fast as greased lightning. If I could say the same thing about Emacs there would be no competition.

[animal_spirits]

If you’re not loving it then don’t waste your time on it. Use the tools that suite you. Getting into vim is a commitment to configuration, I’ve probably spent close to 50 hours of my life configuring this little text editor. It’s been relatively fun, but mostly because as soon as I started getting into it I had the bug to make it perfect for myself. I ended up switching to VSCode with a neovim extension and my life improved significantly lol

[Scarbutt]

FWIW, I settled on using both. Vim with a simple config and Jetbrains(with vim plugin) when I want all the bells and whistles. Using both equally for coding.

My simple config does include vim-commentary, vim-surround (both supported by jetbrains too) and fzf.vim.

[epicide]

I will preface everything with: if you don't see yourself getting value out of vim... don't use it. It's that simple. Vim has been one of the greatest things in my life for most of my life, but that doesn't mean it will be for you. Everybody is different.

Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.

I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.

First the technical implementation

Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.

To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.

Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.

A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:

au BufNewFile,BufRead Jenkinsfile setf groovy

None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]

Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.

Getting a bit more philosophical

If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.

In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.

The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].

The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.

Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.

[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.

[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.

[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".

[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.

[je42]

Lazyvim can help. https://lazyvim.github.io/

> Transform your Neovim into a full-fledged IDE

[roland35]

Just install lazyvim and you basically have everything you need! A few languages are already configured as lazyextras so it's easy to add what you need

[SadWebDeveloper]

Only if you have carpal tunnel problems or painful arthritis, it will make you happy and as productive as a normal developer with vs/vscode/jetbrains/etc

The amount of time you need setup *vim in order to make it a useful editor is not justified, i have seen people waste weeks on it and the only reason is if you have a condition that vim helps to masquerade.

Personally m waiting to get enough money to justify a kinesis keyboard, that will the only reason to improve my neovim knowledge... as for the moment the vim keybindings for vscode are as good as neovim.

[e12e]

Don't discount preventing carpal tunnel!

[CyberDildonics]

Something like gvim is relatively easy to get into if you can give it a few days and look some things up.

Neovim is bizarrely confusing and difficult to configure. The UIs are all weird terminal windows with no buttons, it isn't clear which of the dozens of folders are actually being used for configuration files, it isn't clear how the actual attributes are being declared, it's a disaster.