The Vim/Neovim ecosystem has gotten unbelievably better over the last 5-10 years. "Living in the terminal" for core development work is IMO better than pretty much anything else out there; my Neovim setup has a modern plugin manager; an IDE-like experience with fast autocompletion as I type, goto definition, and automated refactor support; and a side-drawer file browser navigable with Vim motions. It feels like an IDE, except that it launches in ~100ms and has ultra-low typing latency. Using it with tmux panes means I can have various drawers and panes with a series of full, incredibly fast terminals wherever I want, with long-running tasks like automated test watching/running while I edit code placed wherever I want around the editor panel. Not to mention the Cambrian explosion of "modern" terminal tooling getting built, like xplr [1], hyperfine [2], httpie [3], etc.
That being said, I think "living in the terminal" for general purpose computing, like browsing the web or talking to your coworkers, has been in a kind of frozen standstill while the rest of the world has moved on. I think it isn't worth trying to push non-dev work into the terminal currently.
You sound like a sales pitch but my NeoVIM based off of AstroNvim breaks in very random ways across a dozen of servers even under same configuration, I'm about to try Helix instead of the ecosystem with pile of random quality plugins.
It looks promising at first with LSP and all that but I don't know when I had any stable moments.
It's not neovim, but the surrounding plugin architecture I need. I'm using coc.nvim to get autocompletions and documentation and I find that to be increasingly brittle. Also the python3 provider stuff randomly breaks in a venv sometime.
Huh, sorry to hear that. Personally the only annoyance I've had with coc.nvim was when they changed how autocomplete worked and I had to update my keybindings, but that wasn't particularly bad.
In packer, at least, you can pin plug-in versions. I’ve never had the issue you describe - I suspect precisely because I keep my plugin count lean and pin each dependency so it’s always deterministic.
Once you have the proper tooling in place you can do pretty much everything in vim that you are doing in vs code or intelliJ. I've just started using it for most of my dev work recently and I have found ThePrimeagen's youtube videos on vim to be a great resource.
Is there an LSP that allows refactoring Python code like PyCharm?
I haven't found any other tools that does simple things like extracting a function, renaming or inlining variables. For example, vscode's Python support is terrible.
Jetbrains IDEs have refactorings that are light-years ahead of any LSP functionality. I can use nvim for simple or small code bases, but for any real work project I've had to use IntelliJ.
For example, I had a VSCode coworker who was asking to switch all typescript string union types to enums so they could be refactored, but IntelliJ is able to refactor (in this case rename) the string union types
It can be yes, especially depending on what you're doing. I'm so much more productive with some of the impressive refactoring actions. An example cool one for me in React is "Extract Component" where you can pull out a component and it automatically picks out your props (including types for TSX).
A recent example is that I removed all import cycles from our app last week (there where over 200) and I was able to do this purely with the IntelliJ "move symbols" refactor in a codebase of xxx,xxx lines of typescript. I can't figure out how to move a symbol to another file with LSP. I spent the first year of development at my current job when working on the front end and I'm simply more productive in IntelliJ compared to vim - I'm in vim for everything else tho (as long as it's not kotlin/java as I can't get LSP working for JVM projects).
I do love JetBrains products. But they were too memory-hungry for me. I stepped away from GoLand and into Neovim and it’s been by far the best experience the past year and a half. So far, there is not a single feature I miss or haven’t been able to duplicate.
Regarding stability - pinning plug-in versions could be helpful. That’s what I’ve done and I’ve never had an issue with stability.
I have both PHPStorm and Pycharm running, each takes up 4+GB memory on a 8G M1. Slowly growing memory usage for WindowServer process makes matter worse.
In addition to all the language servers folks have already pointed to, Github Copilot works -- surprisingly --- great in Neovim. Tim Pope (author of fugitive and many other popular Vim plugins) wrote the integration.
Lunarvim is a pretty solid choice and comes fully stocked with cool plugins that match most of the popular editors out there. Sometimes I even forget i'm in a terminal.
Depending on what you deem to be a suitable replacement i'd recommend:
nvim-telescope/telescope.nvim // integrates well with code actions and searching (very extensible in general, similar to ctrl-p)
hrsh7th/nvim-cmp
hrsh7th/cmp-nvim-lsp // for language server completion
neovim/nvim-lspconfig // a bunch of language server specific stuff
note, that you'll probably need a bit of time to configure it to your liking and that nvim doesn't install the language server by itself, so that is something that you need to take care of by yourself as well.
If you want to see what a preconfigured IDE-replacement might look like you can take a look at lunarvim(but beware, it misbehaves on windows quite a bit, you're better of with a linux system here)
If you’re just jumping in, you can’t beat starting with lunarvim or astrovim and then customizing further from there if you need to. Neovim is fantastic, and the best way to edit code IMO, but getting it set up to a point where it has the features of vscode/IDEs can be a project in itself.
There's really only one "class" of plugin that's a "must have" to turn Vim (Vim or Neovim) into an IDE replacement and that's some kind of Language Server integration; there are several you could pick, they all allow your Vim to automatically start and talk to a local Language Server, giving you all the fancy autocomplete/go-to-definition/inline documentation/etc that you expect from an IDE. Otherwise, I dunno, maybe a nice color theme? Probably the only one I really depend on that's not part of "general" vim is the FZF plugin, which lets me rapidly and quickly fuzzy search for files by their name anywhere in the folder I'm in.
I use Neovim all the time but although I do have some linters installed I find all the fancy stuff so much worse than in a more visually appealing editor. I love vim and I do have a lot of affection for the terminal but things get extremely visually noisy with language servers in a way they just don’t with a more graphical interface.
It sucks because I want to use vim for TypeScript dev but I just can’t stand it compared to VS Code. For non-typed languages I still use vim, and I love how I can fluently edit anything on servers I shell into, but I kind of wish there was a middle ground of some kind.
Can you explain what you mean by “visually noisy”? If you’re referring to the diagnostics messages (virtual text and signs and such), that is easily configurable to disable (I would know, I wrote it)
I mean like all the stuff that displays in and around the code, that isn’t the code itself. For example warnings, hints, etc. An obvious example of something you can’t do in Neovim is display information in a smaller font. Generally speaking you just don’t have nearly as many options for creating information hierarchies in a UI consisting of ASCII characters.
In terms of turning things off, if you turn them off, then what’s the point of having the language server? (Not a rhetorical question - I would describe myself as a workaday programmer, not a master by any means.)
>In terms of turning things off, if you turn them off, then what’s the point of having the language server?
Code navigation and completion, for one.
But there are plenty of knobs to turn that provide a spectrum between “show nothing” and “show everything”. I also find the inline diagnostic text noisy, so I configure it to only show on the line where my cursor is. You can also use the “open_float” function to open the diagnostics on your current line in a floating window. That way you can leave them off my and simply view them on-demand.
You can use the vim extension for vs code, which let's you have your cake and eat it to. All the convenience of vs code with all the speed from using vim commands.
If you really want speed, you’ll want the neovim extension. This replaces VSCode in many ways, making it neovim under the hood…which means no waiting for VSCode to figure out what’s going on in your giant codebase, no wondering why it takes literally a full half-second sometimes before the characters you just typed pop onto the screen. But it’s still VSCode “on top,” so you can tap into the other features you might want when you want them.
Full disclosure: it’s been years since I used it, but I was super impressed
I still haven’t made the transition to Neovim in favor of stability, but here’s part of my dotfiles repo that installs all the plugins that I use with Vim:
Look up astronvim for a pre-configured setup that'll work for you. You cam try that and add your own stuff in the user configuration. It's pretty easy.
Everything up to and including spell checking, yes. In fact none of those first items are remotely unreasonable to do in a terminal, rather surprising to see them being used as arguments against the terminal.
Emacs also exists which runs in the terminal mostly (I only miss image rendering personally).
Collaborative editing is something I don't do much of but would guess there's a neovim plugin which could be used for backend sync.
Interacting with your issue tracker depends on the issue tracker software you use (flat file would work for example, Jira has unofficial clients, etc).
I've used IntelliJ plenty, and it's pretty bad at most of those tasks. Using the git CLI is much better for version control than the Jetbrains GUI wrapper; using Docker itself rather than a wrapper is much better for containers; etc etc. I'm sort of amazed the question of "can you do version control in a terminal" is even being asked... That's where git originated! That's the git team's primary development focus even today!
"Can you run multiple static analyzers simultaneously"... That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!
Most of the editor questions were also answered by my original post (and the answer was yes).
> Using the git CLI is much better for version control than the Jetbrains GUI wrapper
For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)
> That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!
I meant getting a consolidated list of from them, and also having the ability to run corrective actions.
> Most of the editor questions were also answered by my original post (and the answer was yes).
Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
> For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame
The shit I've seen IntelliJ users do in git repos is insane. Somehow they create merge commits between their local branch and the origin version of their branch. They've lost changes, rewritten history, all sorts of shit, with 0 understanding of what or why. I'm guessing the warnings come as a pop-up and people instinctively just click ok without reading.
> Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
From your replies it's pretty obvious you have made up your mind. But what you are describing is my exact experience with JetBrains. The good thing about JetBrains tools is that their language analysis stuff is truly state of the art and significantly better than the equivalent LSP stuff out there. Apart from that everything is a Frankenstein setup that works differently.
In vim, all those plugins are just splits. So I can navigate between them with just ctrl+w->h/j/k/l (most people rebind to ctrl + h/j/kl). Each split supports the vim hotkeys by default, because that is the design of vim.
In intellj it's an incoherent mess. Every pane has some weird fucking hotkey that makes 0 sense. You cannot just go "select the pane on the left). The hotkey is ctrl+shift+alt+7 or something insane, to the point where it's not worth it and you just need to click everything.
Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
IDK, my experience with JetBrains is it's leaky abstractions all the way down, outside the core edit/refactor features. Using JetBrains Git without knowing git... I mean, I've seen people do it, but they seem pretty frustrated and confused when things go wrong.
I'd rather just learn the underlying tool once, rather than the underlying tool and also the leaky wrapper around it too.
>> Using the git CLI is much better for version control than the Jetbrains GUI wrapper
> For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)
Magit[1] in Emacs is quite okay. It doesn’t feel duct-taped. I haven’t used fugitive[2] in Vim but that’s a thing that exists too.
It's not only some rando on the internet. There's always that one co-worker with a wannabe-vim-hacker setup, that you have to help occasionally with some real work task and nothing in their setup ever works effectively (bonus points for only using DVORAK). After showing them how much easier things are with autocompletion in intellij, next week they proudly show their latest installed emacs-plugin, that only does half-assed keyword completion, without being aware of variables, imports and the program structure. Such a waste of time. Lately I've started to just refuse cooperating under such circumstances, unless they truly show they know their tools.
Mastering the commandline is of course still important, just please not for editing code.
If you want half-assed keyword based completion, you don't need any plugins at all (e.g. ctrl-n in vim).
And if you install a proper plugin that uses language servers, you're at the same level of VSCode, which I'm pretty sure is the most used editor by a wide margin.
Your rant sounds more like you're more annoyed by "wannabe-vim-hackers" than any actual limitations of the tools.
Not OP, but to me, software that requires installing multiple plugins and extensions on top of it and requires much configuration in order to be useable is basically "unfinished software". It's 2022. Software not just has to work out of the box (or out of the download), it has to be packaged with everything needed to actually use it. It has to come fully configured for the most common use cases, or be able to fully configure/adapt itself at runtime. The days of sitting there installing plugins and tweaking settings and looking up how to configure it to do Common Use Case Xyz should be long behind us.
For example browsers. Whenever there is a Must Have extension that basically everyone downloads and installs, we should not be saying "See! It's great that software has plugins and extensions!" We should be saying "The development team totally missed this."
To be honest, VIM doesn't require plugin installation to be fully functionnal.
The main problem with VIM is that nobody reads the documentation, and jumps directly trying to configure vim to imitate what they experienced with other softwares.
Most VIM users never understand VIM philosophy and inner mechanism supporting it. They just try to bend VIM into another graphical code editor.
It's like the meme about "exiting vim". It is pointless. Once you understand VIM you never need to exit it. Just Ctrl-z or use neovim terminal if needed.
The best challenge i was given by VIM guru, when i was asking help installing dozen of plugin, was to read the vim doc (:help) and just use for 6 months a VIM pure vanilla, without any plugin and minimal vimrc.
After more than 20 years using VIM daily, i just understood i never learn how to use VIM and were just an adept of CARGO-CULT, victim of mass spread anti-pattern.
I guess you could shell out to check for errors (for example), but isn't it in general nicer to get error messages as you go? Or how about actually intelligent autocomplete? Stock vim simply cannot do those.
What are some examples of plugins people commonly use that you think are useless?
I'm a sysadmin, and most of what I do (editing config files) is very efficiently done in nano.
Edit a vhost in apache/nginx.
Change a port number on a service.
edit rc.conf,
etc...
But I've discovered that by using vim macros, the tedious parts of using nano became easy and FASTER then nano.
Let's say you have to declare a bunch of IP's and you can't just type a range, you have to type out each one.
In nano: copy/paste each line then backspace to change the last octet.
TEDIOUS
In vim: write it once
record a macro of doing it a second time auto-incrementing the last octet.
now type: 199@w (or whatever letter you stored that macro in)
BOOM, 199 new lines have been input.
That 1 use case, made me use vim more.
Then I got better.
Then I got faster.
Now I can edit those same old config files faster then I once did in nano.
Please believe me, it's worth the learning curve. There is SO MUCH MORE available then just editing some config files.
Nano is fine. There is nothing wrong with nano.
If you only edit (config) files a couple of times a year, then maybe you won't want to switch. But I'm so much better at vim then I was before, I use it to do ALL my writing and editing.
Literally nobody is asking you to use vim. In fact, I don't recommend it to newbies, and warn that a lot of setup is involved. But I am 100x more productive in it than any other IDE, or seen anyone else with an IDE. It works for me. It may not work for you, that's fine.
You might be well served by not seeking out the company of vim users then. There’s better things to spend this life on than arguing about editors, plugins, and keybindings.
Yes there's a learning curve but once you've learned that it can be more efficient. For some people key bindings are easy to remember. For others a menu is better even though it's slower to navigate.
But clearly it isn't for you. It isn't for me either, though I did try. I just don't really have a reproducible workflow (I'm not a dev). In that case the setup overhead does indeed not pay off. If you spend every day in an IDE I could definitely see it working out.
Even on my work mac I often prefer using the cli for things that others would do in the GUI. They find that archaic and overly complex. I find it simple and faster. Opinions vary :)
I've been using Vim since college and nothing else and I could retire at 33 from my FAANG RSUs so it worked for me. Have fun "getting shit done" in VSCode or whatever. Honestly if someone told me they hated memorizing commands or configuring their environment in an interview I would see that as a big red flag, but you do you.
Most of it unvested stock and not enough to retire at 33.
Thanks to the great people running the economy, if you get to survive all layoffs taking place and vest that money, you'll be able to buy an avocado toast made of soylent green in the metaverse of the future. You will own nothing and be happy.
Yeap, what the other guy said. I prefer byobu to vanilla tmux, but the idea is the same. Create a byobu session, detach, give it group permissions, group collaborators attach, enjoy the nano editing party. :)
The commandline is more powerfull than an IDE due the very logic the things work, and has much higher skillcap. You apparently have some skill in an IDE, little skill in the commandline, and draw the incorrect conclusion that the IDE is better.
That being said, I think "living in the terminal" for general purpose computing, like browsing the web or talking to your coworkers, has been in a kind of frozen standstill while the rest of the world has moved on. I think it isn't worth trying to push non-dev work into the terminal currently.
1: https://github.com/sayanarijit/xplr
2: https://github.com/sharkdp/hyperfine
3: https://github.com/httpie/httpie