LazyVim got me back into vim. After years of custom configs and/or heavily editing lunarvim and nvChad I was getting a bit burnt out but decided to give lazyVim a try, and I was absolutely blown away. For the first time a vim setup actually felt like a real IDE. It took about 60 seconds to go from having lazyvim installed to having a fully functional IDE that I could use at work in a real environment. That's the same amount of effort it would have taken me to set up a fresh install of vs code with whatever plug-ins I wanted.
If you've ever been put off by the complexity and setup of nvChad or lunarVim, then I highly suggest giving lazyvim (or astrovim, its similar but with more "batteries included") a try
I don't buy it. I have so many custom little quirks that no ammount of integrated out of the box setup is gonna replace it in 60s. Thats unrealistic. I believe its good, but it must be for certain class of working habits (for example, its probably great for those people that use vanilla anything, including vim).
That's the thing, I absolutely don't want to do a bunch of tiny tweaks. I want to write (react) code. For me personally I feel like tweaking an IDE gets in the way of that. Yet I can take a clean install of lazyvim, use mason to install the react language server, and install copilot, and then I can immediately start working.
And so that's what I actually do, and I find that to be much more pleasant (and lightweight) than other IDEs like VS code.
Agreed. Back then, I tried to get into neovim with packer and a ton of plugins, then tried AstroVim and stuff broke all the time. Went back to vscode.
I tried it again about half a year ago with a much leaner, custom lazy (plugin manager, not LazyVim) setup, and now it's my main IDE for everything except C++ (clangd sucks, sorry)
It took me less than a day to get a decent config, and now I rarely touch it (occasionally there may be a nice plugin to throw in). Config is about 2-300 lines, with LSP (rust, typescript), harpoon, oil.nvim telescope, etc. Works great.
That's interesting to me since I've been using close-to-vanilla lunarvim for the past year and it's been great. I'm just not into customizing my editor much, and only touch my config when I'm annoyed by something. This seems to be your goal as well. Can I ask then what makes lazyvim easier or quicker to set up how you want?
I found lunarvim to just not work that well for web development out of the box (if I tried doing anything past vanilla JS), and I have no interest in learning about lunarvim specific things like the lvim global object to be able to tweak it.
Many people complain about the time you need to have a proper vim.
In computer security, I learnt to make my own tools, to develop my own script that match what I want to do/scan.
For vim, this is exactly the same. I started with Python so my vim became the best Python IDE (for me) and that's all. What I said to junior dev is "Here my vim conf, you are allowed to copy/paste only what you understand". Then I did some Typescript and added a configuration that works for me. Thus, some pain point came from my old config in python, I found new good plugins and added them. And so on with rust and ruby.
Everything is commited so now, on a new machine, it takes me the time to copy/paste my config and write :PlugInstall.
Everytime I test vscode, it does not do what I want and when I look into it, I can't configure it correctly. Vim has always my back.
Indeed, yet I switched to vscode after 10 years of vim because it is next in line to vim when powerfull editor is in question, and once you set it up you can have it 0 on-boarding everywhere else working on ANY machine you use, including browser. I use a lot of machines and I want my editor with me. Its mind blowing that you can just login in GitHubs vscode within a web browser on any repository and have your own vscode with config, hotkeys, extensions and whatnot, the same as on the desktop.
I do miss vim editing constantly, and I could never feel vim emulations as a native thing, but vscode is really awesome, particularly its keyboard centric design and sync.
Once vim has this "works everywhere and my setup installs in 1 command" I will get back to it.
Imagine if you had to do that to every program you want to configure. Sure, rsync/git cloning your config may be less straightforward than logging in somewhere, but it's far more convenient when you have to configure dozens of programs anyway.
And then a coworker/boss is at your desk with you and needs to show you how to do something and cannot for the life of them grok wtf your personalized bs is, requiring them to go get their own absurdly personalized mess to show you, and still you both have problems because the workload they showed you tonsave an hour a day would require you to pull out massive chunks of your personalized bs in order to add in a huge chunk of their personalized bs.
And that doesn't even get into what happens on shared machines (servers etc) where your entire workflow either doesn't work or entirely prevents others from being able to get anything done on the machine.
Really.... we all recognize the value of standardization when it comes to our code but yall fight tooth and nail about standardization in other aspects of the profession.... and then wonder why everything is a buggy unintelligible mess at 99% of workplaces and projects...
Why do people keep making value judgements about people that built tools they trust like they should be ashamed or something like that?
Parent simply explained his process and why he uses vim like that and why he doesn't like VSCode. There's nothing there that says "macho" in any shape or form. I don't understand this need to put labels on others like this. Maybe it makes people feel better about their own choices? Helps with insecurity? I don't know.
Whatever it is, this doesn't add to the conversation at all.
This sounds like a refutation, but it's also in the same spirit as the parent. "No need to deal with insane complexities, I'll stick with my simple editor." Whether that's vim or Sublime, that answer works, and that's pretty cool.
I don't believe in 10x programmer and know this term only from HN.
I live in France and after 10years programming, I never heard a collegue said "I am a 10x programmer". However, I always make sure any git project can be worked on with any IDE. I use vim, some use PyCharm and most of them use VScode and it works fine.
However, I can tell you my main pain point in using VS code vs vim: project switching. Many times I have to go quickly to another project and close it. When I code in vim this this :
ctrl+Z (go back to term)
workon project_2
vim
ctrl+P (select the file I need to see or quickly edit or show to a colleage to explain)
:q! (let's say I didn't edit anything)
fg (Go back to my main task)
Did not know how to be that fast to open/close project with a _real_ IDE.
To oppose this, there is one feature I envy of vs code: code in docker through ssh seamlessly. Unfortunately this is not even available in vscodium.
what's the current recommended package manager for vim? I used to use vundle but that seems to be unmaintained/deprecated and has broken on recent installs.
I'm Ruby developer, and tried multiple times to switch to vscode or one of these heavy IDE like plugins. All the time I'm back to my simple setup which is basically vim + fzf(powered by ripgrep). CTRL+P I run fzf to find files, CTRL+F to scan files content.
It's so fast, that every time I'm doing the test switch to another tool, I'm missing this speed and get back to it. Some time ago I wrote an article for company that I used to work for, describing my workflow: https://thecodest.co/blog/rails-development-with-tmux-vim-fz... you can check it for more details.
A much simpler alternative to this is kickstart.nvim. My approach to customizing my neovim config was to use kickstart as a reference, and slowly add things that I needed.
I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing.
The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs, and other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer. The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
A simple question like "How do I set up Black with neovim to format my Python files on save?" will yield a dozen answers, each one with someone's favourite plugin. Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies that doesn't quite work the way you want, but is too fragile and time-consuming to tweak correctly.
In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
> The amount of work needed not only to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
"This airplane is the choice of professional pilots! The first thing we advise you to do is turn the yoke upside down, it's much more ergonomic like that. Also, you probably want to rip out the altimeter and replace it with a custom one that has more features. And bring your own GPS unit and tape it to the windshield, because this plane doesn't have one by default. And of course, remember that unlike in your car, 'left' actually means right in this plane. This is the professional way. Ah yes, when you fly over Canada, you will see a blinking warning sign telling you that you're out of fuel. That's just a small glitch caused by metric/imperial confusion. It has been known for 23 years but we haven't quite gotten around to fixing it yet. Don't worry, this plane is still excellent for professional pilots. If you feel otherwise, you are probably not a real professional."
More that you want to carve a bowl out of wood. Vim is like a knife that with some modifications you can turn into a carving knife. VSCode is like a chainsaw that has attachments that have been made for it and it also has bowl carving attachment.
If you don't know your tools, then you can easily mess the knife modification and not end up with a carving knife. The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
So it is more like trading initial speed with more precision, but also being able to do more after the initial learning curve.
Let's not forget that vim isn't really designed to be an IDE, though. People just like the editor so much they want an IDE with it. Unfortunately using vim itself for that is the wrong choice. The correct choice is emacs with evil mode.
Referencing the Gimli glider. But does vim have any analogous issue? In matters of technical correctness FOSS is usually the more exacting. You won't find a 1 TB hard drive full at 931 GB of used space on Linux, for example.
>The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lu
Can't agree with this at all.
I don't think I've spent more than an hour in total setting up my vim config back in a day and maybe 1-2 hours in total when migrating to neovim (lua, packer etc) and then migrating to Lazy.
Yes, you have to spend some time building your own DE, but at least now you know what it can really do, all the hows and whys.
>Furthermore, the community does not have a good culture of documentation and learning
Most of the plugins have docs that can be accessed via (neo)vim itself. Usually you can find all information there.
>Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies...
Not true at all. Only a few plugins have strong dependecies and even then you rarely come across a plugin that will have more than one dep.
Haha 1-2 hours ... Maybe things have improved since 2018 but I was up to about 25 hours and still not satisfied with the results. That might be just being a perfectionist or coming from another IDE and trying to replicate something. But 1-2 hours is not a reasonable amount of time to set aside to set up a truly usable custom ide with neovim to acquire the knowledge to drive it.
I’ve plugging away at NeoVim in my spare time trying to get it working and it took me a weeks before I just gave up and directly ripped someone else’s LazyVim config to finally get things working in a state I’m happy with.
Never mind that in order to get modern syntax highlighting and code completion you need LSP-Server, Mason, and Null-ls. The first which has per language dependencies and the 3rd is about to be archived.
Also I don’t know what world you live in but a tool a verbose and powerful as NeoVim you can spend hours just reading the documentation and getting a handle on the basics let alone configuring things to your liking
> Most of the plugins have docs that can be accessed via (neo)vim itself. Usually you can find all information there.
This was something which took some time for me to notice.
There are some plugins which have the best documentations I have ever seen, but you need to read it from the Vim.
I vehemently disagree with this. I find managing vs code extensions a nightmare and having to download them based on rating alone when there are 300 extensions for every query is untenable in a production environment.
Furthermore if you want to customize a vsc extension to do something unique for your set up you have a whole new set of issues like finding the settings, documentation etc.
Now if you can get over all of that it’s still a bulky, slow and cluttered IDE that is constantly sending telemetry data and other nonsense around the web
While I haven’t tried LazyVim I would strongly recommend LunarVim to anyone new to the vim ecosystem. It installs fast, needs minimal set up and packages can be installed with a single line in the config or through packer. Most things work out if the box. But if they don’t vim is so mature you can just ask chatGPT.
Seems like ease of use is also the aim of lazyvim so I would not discourage anyone from trying this flavour as well.
After an unfortunate bout of Java development, I was flung into the arms of Intellij, steadily won over by the indexing and the reliability of the refactoring tools. The Vim plugin was good enough and defining some chords for editor shortcuts resulted in a kind of fucked up fat vim emacs mode that was quite productive.
I, too, got fed up of spending inordinate amounts of debugging vimscript and incompatibilities to end up with something that was slower or buggier than an IDE in certain crucial ways or with highly debugging resistant niggles.
But I'm also far from in love with Intellij these days. It's slow. Prone to index corruption with lots annoyances I can't easily fix myself. I may churn to vscode. But I'm definitely in the gravity well of Intellij.
However perhaps this is worth a look. I have historically had a fairly high tolerance to plowing hours I'm never getting back into fiddling with tools. Just less than I used to. More nixos gnome, alacritty than gentoo, xmonad, urxvt...
I somewhat like Intellij too, but it seems insanely slow, esp. with the Vim plugin. I have to slow down my editing sometimes, because all it's fancy features can't handle the speed.
FWIW, I still use regular vim with ale [0] and it does everything I want. It formats files with Black and isort, shows ruff and pyright errors, supports jumping to definitions, and has variable information available on hover. It also does this for every other language I write in. I have collected my config over the past several years, but I pretty rarely encounter errors with it. It requires no additional dependencies except for the language tools themselves (Black, ruff, etc.).
This is the problem though: if you come to Neovim, and ask "what is the best formatter/linter" someone will tell you "use null-ls". Then a dozen others will say "don't use null-ls, it's been deprecated, use efm-langserver".
OK, how do I set up efm-langserver with Neovim? Good luck! You could probably use a plugin, or maybe not. You'll need a way to install LSP servers. nvm-lsp-installer? Nope,that's also deprecated, use Mason. OK, MasonInstall Black. Wait, it's not formatting anything. Oh, you might need nvim-treesitter. Um...ok, but that's installed already. Ah, you just haven't configured it correctly...here is my setup (pastes 300 lines of Lua or vimscript with zero context as to where you are supposed to load it)....Why are you using efm-langserver? Formatter.nvim is all you need! What? That's old hat! You should be using neoformat!
If you mention Ale or coc.nvim...they stare at you as if you have just stepped out of a time machine from the 19th century.
I have also been able to program for years in C with vim + ale + gutentags but if you start doing some web with all its litlle dsl, it gets overwhelming quite rapidly. In this case LunarVim (or others) is a relief.
> The amount of work needed to get a basic IDE up and running for your languages of choice,
I don't think vim is meant to be an IDE. If you want an IDE, go get an IDE. If you want a text editor, vim works well. But vscode is unwieldy as a text editor, and vim is painful to contort into an IDE.
Exactly this. Don't blame the airplane for not being a car, or a submarine for being a beach buggy.
Obviously people have made things for VIM to be IDE like, some are cool to me, but completion-integrations-lang-servers always seemed so anti-vim to me. Make an HTTP request every key stroke to get suggestions? The. Latency.
Then tell the vim fan bois to stop telling people to use vim as their ide....
The issue isn't with the fact people try to use it that way, it's that those who use vim are adamant it's the best option for doing so and berate the Other until they try.
I dont know..
The argument i read all the time is "i don't want to invest time in vim".
But what kind of professional spends hours uppon hours learning his craft (programming), but is unwilling to invest some of those hours into mastering professional tools?
What about sharpening the axe? The amount of time i saved by sticking to vim is definitly more that the time i needed to learn it..
IDEs are easy mode and waste of resources.
Its ok to start with them as a noob, but down the line i want to customize every part of my toolchain. (And thats just horrible to do in VSCode etc..)
If someone likes to use vim, then so be it. If someone likes to use VSCode, then so be it. IDEs can also be called productive mode and use the right amount of resources necessary for large projects. They will get the job done, and for many it is the preferred option.
Vim doesn’t have to be the tool you use when there are others. If it was the only tool, I’d agree that people should know it better. Thankfully it’s not the only one.
Some hours is not what one should put into Vim, IMO. I've used it for many years and felt I got better at it very gradually (maybe I'm like that with most things). It's much more than hours! It's using it every day for a few years :)
I think your experience report of the NeoVim subreddit is severely misrepresentative of reality. I have never seen a RTFM response. Many answers point to exactly which part of the documentation would be helpful. Your Jenga tower of dependencies is much more imagination than fact.
If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
Or if you don't want to take the trouble to learn how to use (neo)vim, then don't use it; that decision is fine too.
> If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
The real question would be:
Why does the 50 year old editor with supposedly a huge community and tons of editors not have support for a popular formatter for probably the most popular programming language on the planet, and instead everyone has to write their own (probably buggy) variation of that integration?
> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the problem of being clunky on older laptops, but it is an amazing experience to use. I get the best of both worlds, I get really good vim emulation so I don't have to relearn editor shortcuts, I get the benefits of a modern full fledged IDE with many useful features that work out of the box with basically 0 configuration (debugger, git, tasks, etc.)
Same. I like it better than the vscode vim emulation, which is more “strict” and turns to the visual mode when selecting anything with the cursor. Which I personally think is the worse part of vim.
I do have a personal all-products license as well, but I hesitate to go “all in” and be dependent on them.
But it is ok to just use a lot of editors for different things. VS Code is ‘good enough’ a lot times. I like writing notes in emacs org-mode. NeoVim on the command line. Sometimes I use Helix, I think it hits a sweet spot between snappiness and minimal configuration.
If you want IDE like features, then of course an IDE is a better choice. I've never understood why people and to extend vim to try to make it half of an IDE.
For many people, it's because the choices for an IDE are all dog slow, and configuring a few plugins for their editor of choice provides a close-enough experience to strike the balance they are looking for.
So, no, an IDE is not a better choice for everyone who want's "IDE like features". It is for some, but not everyone.
> I've never understood why people and to extend vim to try to make it half of an IDE.
Because vim ships with any *nix machine and provides a consistent experience no matter where you use it.
Vim is the DE part and people add plugins or whatever to enrich the text editing experience with LSPs or other language aware plugins, and the I in IDE is in the form of the integration with the tooling already available on the host.
I feel you, but I’d like to point the Finger in the other direction as well: (modern) programming is not sane. The tools and the environment are not made to be sharp and minimal, we are not using hammers and screwdrivers, we are all using custom made chainsaws with hundreds of proprietary extensions and that’s about as minimal as it gets. Sometimes it’s actually more like wielding multiple nunchucks each covered with chainsaws.
It’s quite disappointing we need multiple layers of assistance to even begin our work. Syntax, autocomplete, go-to def. These sound like simple things, but are fiendishly difficult. Catering to all the various languages’ their idiosyncrasies is, as you have noticed, a task beyond the community.
If something like editing some basic pieces of code takes multiple man-years to facilitate and requires “language servers” I tend to look towards the environment that produces such monstrosities.
Maybe we could stop complicating things so damn much? Impractical I know, but I won’t give up an ideal just because it can’t be reached (now).
Instead of syntax highlighting do you want… minimal syntax in languages?
Instead of autocomplete do you just want to type the thing out manually?
Instead of go-to def do you just want the code in 1 file?
These things didn't require language servers historically, but LSP was an attempt to reduce "many editors re-implementing the same functionality many times" to "implementing the same functionality once and connecting many editors to it". This has a cost, and YMMV on the docs for getting LSPs set up, but I don't think I'd prefer going back. I don't use it, but it seems like VSCode has 1-click plugin installs for most of these LSP integrations, more or less?
I went from VSCode back to vim via Neovim and it works great. I am setup for go and lua. I took a base config called kickstart and removed things I didn't need. Then I added things I do need. As for the community, the channel on Matrix is one of my favorite communities. Whenever I needed help, it came instantly and with precisely what I need. (They must be getting the same things a lot). They never suggested I use a big plugin to solve a little problem as far as I can remember.
All in all it looks like we had a wildly different experience. I suspect the real issue is that I like to work with vim a million times than I did with vscode. You might me biased the other way. I feel better on the command line and it's amazing how much people have figured out already to make things run well and look nice.
This. As someone now in their 30s who didn't learn to code until their 20s, I've tried several times with vim/emacs but it just isn't worth the hassle because I just don't have the free time anymore to endlessly fuck about with config files and learning the ins and outs of each program. So many of the absolute best seem to use one of vim/emacs but then so many of the absolute best started coding when they were children or teenagers with time on their side. It would be a lot easier if they could develop some kind of easy way to switch between these pre made configs but last time I tried chemacs and cheovim I couldn't get them to work as expected. I think emacs has built this feature or something similar into the release coming out soon so I might give it another go in a year or two but I dunno.
hmm.. but you also spent a lot of time to learn programming. Why not invest some time in the use of professional tools?
If you master an editor like vim, you'll never need to spend time to learn additional IDEs. In the past i needed to learn VSCode, Eclipse, IntelliJ, XCode, Visual Studio and some other niche IDEs. All have very different menu structures and keybinds. Just to unify that was worth the time learning vim.
This is why I switched to Helix. The configuration is practically non-existent, and it has default configs for all the language servers I could ever want to interact with. I just put the language server binary in my path and I'm ready to go with autocomplete and all the other features.
Helix is cool, but it doesn't have Vim keybinds, which is unfortunate. I find its own system to be a little worse than Vim's (see my other comment about it in this thread).
I've also switched to Helix recently and I get the feeling that is not emphasized enough how much it is about having default integrations for modern standards like LSP, Tree-sitter, and DAP. It's amazing how much functionality you get with just that and not having any plugins or complex configuration.
Some time ago I switched from my bespoke Vim setup to Doom Emacs. I was pleasantly surprised to find out how “VS-esque” it is. As in, it’s very easy to set up it for a new language. Usually I just need to uncomment the correct line in config. And even if it’s not there, finding the correct major-mode and installing it is usually pretty straightforward.
So yeah, highly recommended! Of course, I use the evil mode for Vim keybindings.
Setting up vim with IDE features takes an hour maximum + 2 minutes per additional language.
If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys.
If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.
Sure, it's one hour if you did that already 20 times and you know the ecosystem.
An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing).
If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, finding the needed plugins for your languages, getting familiar with each plugins commands, resolve any conflicts between them, then you need file pickers, debuggers, task launchers, snippets, split screens, multi tabs, etc... Even then, you only made things work once... Good luck figuring that out in one hour...
Then you'll need to keep the config working, practice and memorize the commands, movements, and maybe customize your workflow.
Configuring vim to replace your IDE may be worth it, but "set it up in one hour" is, in my experience, extremely unrealistic.
That's simply not the case because you will, very quickly, run into problems. One example I had with vim recently was that two different plugins both tried to format the same code and actually send each other into some sort of hell loop and crashed vim entirely because they called something in a circular fashion.
That's absolutely representative of the kind of errors vim and neovim configurations have, because it's all independent plugins with very little ability to fix weird interactions. As soon as you have to customize anything in a slightly non-expected way you have no chance to predict if this is gonna break one of the dozen things that are basically held together with duct tape. VsCode or anyting designed to be an actual IDE with its tools better integrated doesn't suffer from this.
I’ve felt similarly, and really wanted to switch to VSCode. But it gives each pane its own set of tabs, while Vim has a single set of “tabs” (buffers) and multiple panes within it.
I’ve been using N/Vim for 25 years, and even after trying for a week or two, I just can’t get comfortable with VSCode’s way of doing it.
I'm in a similar boat. I've used vscode, pycharm/idea, visual studio and vim etc.
I'm currently giving neovim + i3wm a try, and there are certain things I love. Specifically instant switching between my browser and my ide, the ide and terminal.
However, the speed of the LSP(tips, method definitions when coding) is greatly exaggerated. For example for python there is the exact same 10gb ram using behemoth running in the background. Is it faster than using the same language server in vscode or idea? Yes, a bit, but definitely not 10x faster.
Also, I have 2 complaints. One is about keys. There is a huge emphasis in vim world to set your own keys for everything... The problem with that is that for some rarely used action one forgets... Or one moves to a different machine. I think plugin like lsp-zero should more prominently document their _default_ keystrokes. I prefer to learn these before I start setting my own for everything.
Second thing is what makes an ide most useful. A tree view file manager. I'm currently using nvim-tree. It's a nice plugin, and it works, but it lacks certain features like displaying large trees of empty folders in a "collapsed" way like vscode does.
So, for now I'm sticking with nvim, but I can't say for how long..
You might be interested in installing the fzf-vim plugin [0]. It has a user-defined command :Maps which can be used to search through all keybindings (you can also do this with just :nmap in vim, but the fzf interface is much nicer). It also provides :Commands. This behaves remarkably like VSCode's command palette.
I don't disagree, it's always a balance of "how much time do I actually want to spend on my workflow vs getting the work done", but I think the only reasonable way to use Vim is to build your environment over time (many years) and have it in source control so that you never have to do it again. You'll still have to keep making updates of course, but that's typically a bit smaller time commitment.
this is basically why I moved to https://github.com/helix-editor/helix/ for most things. neovim setup is a nightmare these days. 0.5 introducing Lua was both great (yay! vimscript sucks!) and horrible (oh no, everyone took this power and made a full operating system worth of complex stuff out of it that rarely fits together cohesively, and it all updates so frequently now that I can't keep up)
I don't actually think it's Lua's fault. And I don't necessarily want to jump and say "the improved accessibility of this thing turned it into an unusable circus", because that's both unnecessarily sassy and also likely prescribing blame in some places it doesn't fully belong. But there's something that tidally changed in that time, and especially in the past 2-3 years, my vim setup became a thing I dreaded updating (because it would 100% guaranteed, every time, break something about my workflow)
> I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing.
I’ve done that a couple years ago after ~15 years of happy vimming. Still yearning for the text manipulation language combined with macros, but all the other gains significantly outweigh the worse editing capabilities.
I wonder why people are asking Google search like they would ask a person?
Just googling "black nvim" yields a correct result (project repository) where you can follow the lines to get it installed/configured in a minute.
Why would someone ask "How do I set up Black with neovim to format my Python files on save?", hit the reddit/quora/another obscure forum where he finds some hostile people who doesn't well explain to him how to set up black with neovim to format for his python files on save. DAMN. Just type in "black nvim", hit return and head to repository boy. There are genuine docs and installation instructions from the author, you don't need other people to explain it to you.
Google is a search engine not an answer engine, so if you're looking for struggles instead of information you'll find it by inputting questions instead of indexes.
I'd recommend trying a neovim distro like lunarvim out. It has black and all other typical ide features configured out of the box and doesn't mess with your normal neovim config.
I tried out spacevim, but then some feature was getting in my way and I couldn't figure out how to turn it off (I've forgotten what now).
I think thats a disadvantage to some of these heavily customized vim flavors. Plugins don't necessarily work out of the box, and when they do they promote their own way of interaction that sometimes needs to be learned.
Did you try LazyVim or any other neovim distro? Seems like you're complaining about configuring neovim from scratch, which is that pain that neovim distros aim to remove
Yes I did. And they work fine, until you need to do that one thing (e.g. "Set up Black to format on save"). Now you are back in that world of pain of figuring out which plugin needs to be installed/configured, only now you are figuring out someone else's way of doing it.
An alternative to Neovim or VScode that might be worth checking out is Helix (https://helix-editor.com/). It is a Vim/Kakoune inspired editor that is really starting to hit its stride. I haven't used it extensively yet, but I'm testing using it for development now and am thinking of switching to it full time. It maintains the minimalism of (Neo)Vim while coming with a great builtin setup like VScode.
Helix is interesting but I don't really gel with its editing language (subject + verb instead of verb + subject like (n)vim's). Happy to discuss what I think is lacking in more detail, but basically: the premise of 'you can see what you're about to operate on before you do the action' is satisfied for me by visual mode, and I like macros better than multiple cursors. So I don't want a (subjectively) less efficient editing language for these features. I think I generally agree with the complaints in [1], with the addition that I don't want to have to chord (press shift in the case of Kakoune, I forget what helix does here) to extend a selection.
Helix is quite nice, with some sensible defaults and an easier setup. The keybindings take a bit of getting used to if you are coming from it with years of vim muscle memory, but kind of make more sense when you think about it (select+action vs action+select). It's still rough around the edges but one to keep an eye on.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
Vim's built-in package management means all my plugins are stored as git submodules that are installed alongside my configs. I don't have to remember what extensions I have and Ctrl + P and install them one at a time.
VSCode's settings.json and extension-level configuration is also extremely cumbersome. You're paying a time tax no matter what tools you're using if you want to customize them to fit your workflow. Personally I'd rather pay that tax 1 time with Vim and then carry the same setup with me to any PC than have to eat that cost every time I need to configure VSCode on a new machine.
I also went through this phase about a year ago, then just gave up and went with VSCode for its superior out of the box experience. That said, I still fire up vim to read files in a server or make one line config changes, but everything else....VSCode.
Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
I've just come around to accept that we've been blessed with great hardware over the years, and it's a waste if those extra CPU / GPU cycles aren't translated to significant dev productivity improvements. I'd take slower (~ ms) editor paint times over saving hours messing with vim configurations.
> Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
What's hard about this?
rsync -a dir/ server:dir/
I'd much rather have commands in my terminal where I can search for them later than do things visually and have no record of what I did once and how to repeat it.
Strange, the only thing I need to do to get everything I need these days for a new language is install the right LSP provider and point vim to it. It used to be much harder, now it's closer to trivial.
I just want a decent open source native editor with a native GUI.
10+ years ago, when I and almost everyone I knew were on Windows or Linux, this was simple and ubiquitous. UltraEdit, Notepad++, Vim and Emacs of course, etc, there were dozens of options to choose from.
Then I and most developers that I know switched to Macs, and now this is an alien concept. There's a dearth of open source Mac development, and much of what exists uses Electron or some other crutch to avoid committing to the Mac platform.
I've tried Neovim, but the "GUI" version is basically just the console version in a window. Might as well just skip it and do everything from the terminal.
There is MacVim, but you have to open it from the command-line in order for it to scan your home directory properly. If you pin it to your dock and launch from there, then it doesn't know who you are and launches in stock vanilla mode without reading your .vimrc. Same problem with Geany. I could PROBABLY figure out how to modify the dock icon to launch with the right flags, but the point is that this is unreasonably complex and arcane for most users.
So... I just stumble along with VS Code by default, like most people these days. It's an odd shame that cross-platform desktop app development is as dead as it is, especially considering that most devs today are not using the dominant platform anymore.
> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
I've personally been test driving JetBrains Fleet and have to say that it's pretty okay for most of my lightweight dev needs: https://www.jetbrains.com/fleet/
It's still a bit early for it and it doesn't have the same ecosystem that VSC has, but it'll probably be even better in 1-5 years and is decent already.
For most of the more heavy work I just use JetBrains IDEs, but that's very clearly a no go for the less capable devices like my netbook.
For even lighter options, on Windows there is Notepad++, which has been okay although not an IDE.
I don't need an IDE for Python. Of course I can use a plain text editor if I want. Hell, nano even.
But right now, today, at work, I have a large legacy Django project to maintain, and it's kind of nice having little things like auto code formatting and linting to help me as I go and prevent me from making dumb mistakes and saving me a ton of time so I can focus on the problem at hand, not making the code look nice for review and I can hop between buffers to fix up the tests as I change the code.
I can certainly just run black/isort/ruff what have you manually, or with pre-commit, sure. But it's more productive to be able to see changes as I work.
Sure maybe I shouldn't be using Python, and maybe the original developers should have written it in Rust or whatever. Fine. But that's not what I'm being paid for.
Sadly I completely agree with you. Whats even sadder is I recently made a post proselytizing the virtues of neovim over vscode.
The final straw for me was discovering that vscode automatically updates packages and imports when moving files around a java project - something that doesn't seem possible in neovim despite hours of research and lua tinkering.
Edit: I did use Helix for awhile (long enough to still have muscle memory for their editing model) but it’s just not there yet and eventually moved on to Zed.
I love the concept and engineering behind Zed, but considering how software startups tend to fare, there's just no way I'm going to mentally invest in a closed source dev environment.
Even if they succeed commercially, chances are some day Microsoft just buys the whole thing and shuts development down a week later. No thanks.
I am using mostly default settings on my neovim setup for most plugins.
I can't do much with vscode before also install tons of plugins and eventually setting them up. The only major difference to me is a central marketplace for vscode plugins instead of relying on github search engine+recommendations and being subject to telemetry I don't want.
I think it's important to know a terminal text editor if your work involves remote servers. Then once you know one of the good text editor, you may be tempted to use it for other tasks. That's where people get into trouble.
The base emacs and vim documentations are actually excellent, the problem is the plugins. Just use an IDE for IDE tasks and a text editor for text editing tasks! I'm not going to start a new project in Intellij just to edit a config file or take notes about something. Why would I want to pollute my minimal emacs config so that I get a flaky IDE?
(Of course it's fun to program in a text editor because it's fast and distraction-free, which is why I use them for hobby projects. But for professional work I use professional tools.)
Agree. It's crazy and I've given up. I have windows and linux computers, and what works for one, doesn't for the other. Setting up a shared vimrc is a nightmare. In the end, I only use vim for text. Colab and jupyter for all the programming.
My experience with vim differs drastically and I believe the root of most problems you had stems from trying to turn vim into an IDE.
I won't argue at all. If you prefer IDEs, you go for it. But maybe vim and neovim aren't the best choices.
I use vim as a text editing tool, solely. My .vimrc contains ~ 20 lines. Use 2 popular plugins to help me finding and opening files, and one plugin to support editorconfigs (useful for sharing formatting rules with folks using vscode in the team). And I use makefiles or other scripts to call external tools (formatters, linters etc).
There's probably a billion of plugins which could increment my productivity, but honestly I don't care much.
Just tried today to switch from Vim to Neovim as my EDITOR when I work over SSH (I use VS Code otherwise, I know about its SSH capabilities but don’t use them to edit just one file).
Result: had to add a PPA on my Ubuntu server (not ideal but OK), most plugins require nvim 0.8+. Switched to the unstable PPA (because the stable PPA ships 0.7), turns out it doesn’t ship the latest release but instead a nightly dev build.
While editing Lua configs of Neovim, I tried to use ‘micro’ just for fun.
Result: my new EDITOR and GIT_EDITOR (that I previously set for +startinsert) are now set to ‘micro’. Alt+/ for commenting code, sane shortcuts, and code highlighting cover 90% of my needs.
(As much as I'm team *Vim) Vimscript is a mess. Oh, so you mean 'noremap' means remap this? No way! /s
The story about plugins is so true, regardless of the above. People will want you to install a plugin with 5 stars that will not play nice with anything else to do something basic like pre-save processing. Or one of the 'everything but the kitchen sink' plugins that has an end goal of giving you a Borgified Vim
And in the end I sincerely don't care, I could use the time I'm playing with this to install VSCode, or something else and have something more complete OotB
I use vim for years, too but also I keep my .vimrc and, more recently, .vim in a git repo (using bare repos for dot files discussed here: https://www.atlassian.com/git/tutorials/dotfiles). So, getting a functional environment on a new system is close to running `git pull` once.
I don’t update plugins too often, because they work, but I also don’t use too many. Based on my git history, I last updated a vim plug-in 11 months ago.
I've stopped using vim and started using visualstudio + vim plugin and called it a day. for me, it's just not worth it to tinker with truckload of plugins just to get ide features work.
I think learning vim was very worthwhile for me cause I now use vim bindings if it's supported, but yeah vscode was getting slower for me the past few months and I decided to try neovim again and man so many things have changed since the last time I tried it with the new Lua config. I feel like it'll take me a day to recreate a config im satisfied with and it'll probably have a few bugs too after using it for a while.
Vim definitely was designed and remains an editor first and foremost. The IDE=like functionalities were clearly cobbled together later and it shows, on that we agree.
What always surprises me however is why having realised the limit of this model, decide to go back to VSCode, another editor with cobbled together IDE=like functionalities? IDEs are nice. Last time I checked VSCode debugging was still subpar and required fiddling with configurations.
I use VSCode with one of the neovim extensions for 'IDE tasks' (none of those extensions is perfect though, but they're "good enough"), and a vanilla vim without customization for quick text editing tasks on the terminal (sometimes even within the VSCode terminal panel).
E.g. for me, "vim" is more like an input scheme that works across editors, less a particular product.
I was going to ask a similar question. This seems really cool, but since I already suffer with the complexity of vscode at work (but it's supported so is a net win), and I have my Vim setup that is small enough to (mostly) understand myself, why add a third thing which combines bad features of both? I'm responsible when it breaks, and it's complex.
For me vim is a good text editor. You could somehow turn it into an IDE — even into a good one, but that is not what is the core value proposition of vim.
I am mostly using sublime text for programming projects and vim for editing configs on headless servers. If I like to use vim for programming I'd try to add vim keybindings to my IDE instead of adding an IDE to vim.
Same sentiment here. After 2 decades of development and having been through phases such as Gentoo, Vim+plugins, and other deep dive hobbies, I enjoyed the time spent, but now I just want something that works out of the box. I've found IntelliJ/GoLand with Vim bindings to work well for me. That Vim muscle memory is something I'll never get over.
Code should be self-documented.
And editor should have a good mechanism to help you understand the source code.
Emacs does better in this angle than Vim by far.
You can find the documentation for every variable (describe-variable) and functions (describe-function) easily and jump to their source codes.
> The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Now how you integrate this into your config is again a little programming problem in and of itself. But it's not really a complex programming problem. You are after all not trying to write some large complex and scalable system. You probably have all the tools necessary to organize your code well. I went with a highly functional approach which passes functions around everywhere but you may be more familiar or happy with another approach. The beauty of a neovim configuration is that you are the only person who needs to maintain it.
I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.
> I agree that neovim is not for people who are not interested in learning their tools.
That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this job otherwise.
However, my time is limited. I have to be selective in what I spend time learning. Much of that choice is determined by my employer, project and other requirements. Free time left over for learning other things is even more limited.
Learning another language and API and plugin ecosystem just so I can configure my editor? Maybe for some people, that's time well spent, but personally - having spent a fair bit of time with neovim to give it a fair shake - I realized that what I don't need is a perfect artisinal text editor, but a good-enough IDE that lets me do the things I'm either actually interested in, or paid to do.
Vim as a simple text editor? Perfect, use it every day when dropping into a headless server to edit a config file or two. For an IDE? I don't love vscode, but for what I need, it's fine.
JetBrains have excellent offerings for both JavaScript and Python, in my opinion. I happen to like Neovim and I don't use the languages you have issues with the Neovim side of, but if I were to use an alternative it would definitely be JetBrains IDEs.
They are certainly still trying. I used vscode a while ago. Some of the best and most essential extensions like LiveShare and Remote are proprietary and worked only on the proprietary build of vscode (the last time I checked) and wouldn't work on OSS builds like vscodium (why though?). Both these extensions and the proprietary build of vscode come with telemetry that's either opt-out or always enabled. They nudge you ever so slightly and gradually towards the proprietary build. I left vscode since I don't like such manipulations.
but there is.
VSCode core may be open source, but the plugin marketplace certainly isn't.
So if you for example use VSCodium, you don't have access to the plugin marketplace and eather have to use an alternative or manage your plugins completely manually on the filesystem.
neovim extension + vscode is a great pairing. full neovim in normal and visual mode but you can call out to vscode anytime you want in those modes and you also get neovim extensions too. it's great and fast... worth a try.
I've never tried neovim, but have been a vim user for over a decade and never really dealt with problems where I need to touch vimscript at all. Is neovim that clunky? Is it plugins?
My feeling is that neovim per se, as a piece of software, is fine, but that it belongs to one of those developer communities that prizes freedom and infinite configurability over the day-to-day practicality of getting things done. So something like LSP integration has too many ways to do it across too many plugins.
If you are deeply involved in the community and are willing to put in the time, sure, you could probably build something superior to vscode. But the time invested to get there might not be worth the marginal productivity gains.
No, it's not clunky. The plugin community is just a lot more active, imo. I personally avoid plugins wherever I can, since I prefer to write my own little Lua scripts that do stuff the way I like. (And I quite like the Lua API-- the lua plugins I use seem be a lot faster/less janky than the vimscript ones, as well? not sure)
Vim, the program, I find useful in limited cases. Vim, the keybindings, I find I try to use everywhere -- from the browser to every IDE I ever work in.
Yes I did, and no it didn't really help. Sure it was a much slicker starting point, but when I needed to do a bit more (ie. configure a formatter) it just added more obfuscation than anything. The "pre-cooked" part does help with setting up linting, but formatting...you're kind of on your own (if you search the source you can find an example with prettier but you will still need to add your own integration for anything else).
Am I the only one using vanilla vim with a minimal configuration file (<50 lines)? I set tabs to 4 spaces, put syntax highlighting on, set background to dark, add fuzzy finding, and configure netrw (default file browsing).
Very easy to setup. Moreover, when I'm on a different computer and open (vanilla) vim without any configurations. I know that everything is more or less the same as my default vim environment. I think it's not that hard to learn developing in the default vim environment, with some minor tweaks.
No. I've been dragging my small (106 line) .vimrc around pretty much unchanged for at least a couple of decades. It's mostly just setting different colour schemes for different filetypes. I've been a vi user for about 4 decades.
I need a small, fast text editor that works over remote connections, works on Linux and Windows, needs no configuration or plugins to be useful, and just works and gets out of my way. VSCode does not fulfill most of those needs. Plain old vim (and not neovim) does.
I really think this is the best way to use it for many people. You need something more complex? It's ok to bundle vim with any of great IDE's out there.
I learned how to change colorscheme more than 20 years ago because my CRT monitor made it impossible to read comments on default themes. I use same command today on my local terminals, bastions accessible via web or remote sessions ... for basically the same reason.
If you code from one machine spending time to set up IDE and then leaving it be makes sense.
But if you are more of an admin, or learn a lot and jump from host to host, from learning platform temporary environments to cloud environments, from mobile to some remote mainframe that is being decommissioned for past 7 years? You could just figure out how to change 2-3 basic options and have a predictable environment for next few decades.
I’m at home on vanilla vim, but there are some quality-of-life stuff I’ve been collecting over the millennia that are just too good to give up on my day to day use. One has to find its own balance of custom vs default.
I worked this way for ages, but over time I came to appreciate some modern IDE-like conveniences like linters (I use ALE for this stuff). Especially thanks to LSP (which neovim supports natively, though I stick to upstream Vim myself) you can get a lot of value from these.
I think it's easy to go overboard though. A lot of plugins (and these meta-plugins) provide little value over what vim can do on its own with a little configuration.
There is always people coming over from established purpose made IDEs who want to test to waters and bare vim is pretty feature parse out of the box, so these huge plugin & configuration monoliths offer easy stepping stone into vim.
Of course with these packages you are trading flexibility for features and you are inheriting ways of working from someone stranger, but it is not that much different than using any IDE. While this offers a nice(r) gate into vim-ming it does kind a miss the biggest perk of using vim - which is molding it to your exact needs and preferences, but that is not something you will do over night. I have been in both camps. I have installed way too many plugins and then gone to very sparse configuration. I think with NeoVim I have found somewhat of a balance, but I think reworking your vim config is a natural thing every five years or so. We grow as people and developers and our needs change and the tools evolve.
I have a one-line vimrc, mainly to undo the damage the change in defaults vim 8.0 brought (so I've got things like set t_BE=). I used to have to also have set noincsearch and set scrolloff=0, but something in my environment seems to been upgrade so I no longer need that in my vimrc
You're not the only one, but my configuration is the opposite of yours.
These are the three lines I always use on any vim install.
let loaded_matchparen = 1
syntax off
map ; :
The first two lines are crucial, because I find rainbow colored text and flashing punctuation extremely distracting. If you find monochrome code unreadable, then that's a problem with your formatting style that you can easily fix.
The last line is really handy for not having to hold down shift so much.
Not at all. This boring answer is very useful for general use. I have some fun plugins that have been useful (YouCompleteMe was helpful for C development) but they break and I don't notice. But at work someome else maintains an IDE for me, so I use that.
It helps though with remembering where you are in your codebase. Rather than cluttering my brain with the info that Nerdtree provides, I can instead use the extra brainpower for other things.
Yeah I've been using vim with just a custom theme and a fairly vanilla .vimrc for 20 years. I just copy it around with me. These posts always make me feel like I'm missing out.
I use neovim for my development. It has a bunch of plugins to facilitate using it as my primary code editor. I don't particularly enjoy typing things out over and over again (I have RSI) so to me a config that doesn't have things like autocomplete aren't going to be acceptable to me long term. LSP also makes it easier for autocomplete to function with the context of your development environment, which allows me to type even less.
I'm not going to sacrifice my 95% use case for the 5% of time (probably even less) that I am in a situation where I don't have access to my own config. If I am just editing a few lines in a config file on a server, it doesn't really matter that I don't have my config.
With that being said, not everyone wants or needs plugins and their needs are different from mine. Do what serves your needs. I would simply advise anyone to consider if their workflow is serving themselves or not. A lot of people get stuck in the mindset that they need to simplify in order to facilitate easy transitions to situations that just don't come up all that often.
With less plugins and less custom configuration it becomes much easier to work in environments outside your home. Also it is more robust and less things break!
I feel like I should be the kind of person who prefers eMacs over vi(m), because I've always been a hotkey maniac. I'm actually not though at all, and I much prefer the simplicity of vim. I already have way too many hotkeys lingering in my brain, especially since I played the game Age of Empires II.
I don't play many games these days, and I certainly don't use their hotkeys (I play exclusively on consoles these days, lazily).
None of this likely has anything to do with the article. I'm sorry to report that I did not read it. I come here for the commentary, not the article. I am guilty of that.
I've had several people recommend me their IDEs or some new text editor from time to time by telling me that the editor supports Emacs style keybindings assuming that is the main difference between editors. I've never used emac's native keybindings, nor do I use vim's since I don't use qwerty.
While my custom keybindings are something I would not want to give up they can be replicated in any other editor that provides this basic functionality. What cannot be replicated is the whole reason why I prefer emacs, I like being able to use it like a file explorer, like a terminal, I like being able to open or edit pretty much any type of file I ever use. When you combine the ability to work/view most of the files with consistent keybindings, that is the killer feature that emacs provides, its never been about the keybindings.
I'm curious though, I never really got into vim as soon I realized that it only makes sense if your layout is qwerty. Is vim just its keybindings? or is it like emacs in that the keybindings are not the main reason people use it?.
> people recommend me their IDEs or some new text editor from time to time by telling me that the editor supports Emacs style keybindings assuming that is the main difference between editors
I get that too but with Vim. People think Vim is just about the controls because all they know about Vim is the :q joke. No, that IDE's Vim plugin doesn't cut it, because unfortunately it comes with an IDE and its distracting overloaded UI, weird tab switching behaviour, absolutely infuriating popups and other annoyances.
Vim being just a really flexible and fast editor with a mostly empty status line as the entire user interface is a feature.
I used vim for a long time and now use Emacs doom/evil over top for most of my daily work. I’d say the part of the key bindings that I find hard to live without is the modal editing side of it which helps me really think about the macros I use when moving around or editing.
The other thing I really love is the integration with the old ed editor so you can quickly do several really flexible edits with regex and get what you want. I’m sure emac’s built in functionality can do some/most of the stuff but it’s no where near as concise and other editors have no such built in functionality to speak of.
Oh goodness, I would never use vim as an IDE, or any purely text based editor. I pay out-of-pocket to use proprietary IDE's, and I consider it a cost of doing business. Vim to me, is simply a way to make minor changes to configuration files mostly. I would never dream of coding in vim.
Edit: TLDR - vim is sometimes better than sed for making changes to files, but in my mind that's about it.
Stick with what you like, if it works for you then that's what's most important. Personally I switched from neovim to emacs, but I don't care for the 'emacs style' of keybindings. Instead I use evil-mode and set my own bindings with hydra for everything else. Tbh main reason I switched was elisp envy; there's not really a whole lot that you can do with one but not the other.
Most people miss "Vim Is More than Just an Editor." The Vim Language, its motions, and its modes will make you a better programmer and writer. If you invested in the vim language early on, you can use it on each editor, browser, and other apps. This has nothing to do with the editor yet – these are universal and available. For example, there's VSVim for VSCode, IdeaVim for the JetBrains products, Vintage Mode for Sublime, and so on. But there are also Browser extensions like Vimium or Firenvim, and Gmail even adopted some of Vim's shortcuts for navigation (j, k for moving, g for jumping).
Everyone who types on a computer eight hours a day should learn the Vim language. Yes it's hard initially, but that's the case with everything new and different. But getting better every day and having more fun coding or writing should be motivation enough. Also, imagine, if you work over a decade, how many times you had to learn a new editor (notepad++, atom, eclipse, ...) some of which do not exist anymore. If you once learned the vim language, you are getting stronger. There is a reason the editor has existed since the eclipse of programming.
The Vim grammar is exceptional, as spoken language has verbs, subjects, and objects, as does the Vim language. The grammar has different verbs, to begin with. Copying (or yanking) in Vim with y, deleting with d, pasting with p, changing with c, and so on.
You can also see in the comments here people fight over Vim and VSCode, where the natural beauty is the language behind Vim. If you do not want to configure and customize your own, use VSCode and add the Vim extension. But if you're going to get better at your job, you should try the Vim language.
Once mastered, you edit text at the speed of thought. Sounds cheeky, but it's true for me. Instead of thinking, "I want to edit that word," my fingers jump to it and change it with a few keystrokes.
I would substantially nuance most of what you say. I really like vim and use it almost exclusively, but it is not necessarily the "only" way, or even necessarily the "best" way to do things. If the vim grammar clicks for you, great, by all means use it. There are people for whom it doesn't click, and that's fine too. I do encourage everyone to try it for a bit.
I also would not say learning vim makes you a better programmer or a better writer. It makes inputting and changing text easier and faster, but that's not what programming or writing is about.
I agree that the vim grammar is nice, but the bigger thing that differentiates editing text in vim versus other editors is its modality. And it is the modality that allows it to have a grammar in the first place. And that grammar does break down in places, just look at every keybind starting with g.
So yes, try vim, because it is pretty great. But if it doesn't work for you, move on to something that does.
Readit News
If you've ever been put off by the complexity and setup of nvChad or lunarVim, then I highly suggest giving lazyvim (or astrovim, its similar but with more "batteries included") a try
And so that's what I actually do, and I find that to be much more pleasant (and lightweight) than other IDEs like VS code.
I tried it again about half a year ago with a much leaner, custom lazy (plugin manager, not LazyVim) setup, and now it's my main IDE for everything except C++ (clangd sucks, sorry)
It took me less than a day to get a decent config, and now I rarely touch it (occasionally there may be a nice plugin to throw in). Config is about 2-300 lines, with LSP (rust, typescript), harpoon, oil.nvim telescope, etc. Works great.
[0] https://github.com/NvChad/NvChad/releases/tag/v2.0
For vim, this is exactly the same. I started with Python so my vim became the best Python IDE (for me) and that's all. What I said to junior dev is "Here my vim conf, you are allowed to copy/paste only what you understand". Then I did some Typescript and added a configuration that works for me. Thus, some pain point came from my old config in python, I found new good plugins and added them. And so on with rust and ruby. Everything is commited so now, on a new machine, it takes me the time to copy/paste my config and write :PlugInstall.
Everytime I test vscode, it does not do what I want and when I look into it, I can't configure it correctly. Vim has always my back.
I do miss vim editing constantly, and I could never feel vim emulations as a native thing, but vscode is really awesome, particularly its keyboard centric design and sync.
Once vim has this "works everywhere and my setup installs in 1 command" I will get back to it.
Just copy/clone the dotfiles, launch neovim and run a command to update the plugins and everything is good to go.
Not as customizable. But I pretty much would configure vim to do what helix does out of the box anyway.
Imagine if you had to do that to every program you want to configure. Sure, rsync/git cloning your config may be less straightforward than logging in somewhere, but it's far more convenient when you have to configure dozens of programs anyway.
And that doesn't even get into what happens on shared machines (servers etc) where your entire workflow either doesn't work or entirely prevents others from being able to get anything done on the machine.
Really.... we all recognize the value of standardization when it comes to our code but yall fight tooth and nail about standardization in other aspects of the profession.... and then wonder why everything is a buggy unintelligible mess at 99% of workplaces and projects...
I will keep using Sublime Text. No need to suffer needlessly.
Why do people keep making value judgements about people that built tools they trust like they should be ashamed or something like that?
Parent simply explained his process and why he uses vim like that and why he doesn't like VSCode. There's nothing there that says "macho" in any shape or form. I don't understand this need to put labels on others like this. Maybe it makes people feel better about their own choices? Helps with insecurity? I don't know.
Whatever it is, this doesn't add to the conversation at all.
Can you expand on this? What specifically does not work for you on vscode?
However, I can tell you my main pain point in using VS code vs vim: project switching. Many times I have to go quickly to another project and close it. When I code in vim this this :
ctrl+Z (go back to term) workon project_2 vim ctrl+P (select the file I need to see or quickly edit or show to a colleage to explain) :q! (let's say I didn't edit anything) fg (Go back to my main task)
Did not know how to be that fast to open/close project with a _real_ IDE.
To oppose this, there is one feature I envy of vs code: code in docker through ssh seamlessly. Unfortunately this is not even available in vscodium.
https://github.com/nvim-lua/kickstart.nvim
The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs, and other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer. The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
A simple question like "How do I set up Black with neovim to format my Python files on save?" will yield a dozen answers, each one with someone's favourite plugin. Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies that doesn't quite work the way you want, but is too fragile and time-consuming to tweak correctly.
In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.
"This airplane is the choice of professional pilots! The first thing we advise you to do is turn the yoke upside down, it's much more ergonomic like that. Also, you probably want to rip out the altimeter and replace it with a custom one that has more features. And bring your own GPS unit and tape it to the windshield, because this plane doesn't have one by default. And of course, remember that unlike in your car, 'left' actually means right in this plane. This is the professional way. Ah yes, when you fly over Canada, you will see a blinking warning sign telling you that you're out of fuel. That's just a small glitch caused by metric/imperial confusion. It has been known for 23 years but we haven't quite gotten around to fixing it yet. Don't worry, this plane is still excellent for professional pilots. If you feel otherwise, you are probably not a real professional."
If you don't know your tools, then you can easily mess the knife modification and not end up with a carving knife. The chainsaw with ready made attachments is way easier to get going, but in return you have to carry the chainsaw with you and if there are any problems with the tool itself you probably aren't going to be able to fix or modify it yourself.
So it is more like trading initial speed with more precision, but also being able to do more after the initial learning curve.
> 'left' actually means right
Referencing the Gimli glider. But does vim have any analogous issue? In matters of technical correctness FOSS is usually the more exacting. You won't find a 1 TB hard drive full at 931 GB of used space on Linux, for example.
Can't agree with this at all.
I don't think I've spent more than an hour in total setting up my vim config back in a day and maybe 1-2 hours in total when migrating to neovim (lua, packer etc) and then migrating to Lazy.
Yes, you have to spend some time building your own DE, but at least now you know what it can really do, all the hows and whys.
>Furthermore, the community does not have a good culture of documentation and learning
Most of the plugins have docs that can be accessed via (neo)vim itself. Usually you can find all information there.
>Setting up that plugin will require another plugin, and so on until you end up with a Jenga tower of dependencies...
Not true at all. Only a few plugins have strong dependecies and even then you rarely come across a plugin that will have more than one dep.
Never mind that in order to get modern syntax highlighting and code completion you need LSP-Server, Mason, and Null-ls. The first which has per language dependencies and the 3rd is about to be archived.
Also I don’t know what world you live in but a tool a verbose and powerful as NeoVim you can spend hours just reading the documentation and getting a handle on the basics let alone configuring things to your liking
This was something which took some time for me to notice. There are some plugins which have the best documentations I have ever seen, but you need to read it from the Vim.
Example of coc.nvim: https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt and https://github.com/neoclide/coc.nvim/blob/master/doc/coc-con... and https://github.com/neoclide/coc.nvim/blob/master/doc/coc-api...
Dead Comment
Furthermore if you want to customize a vsc extension to do something unique for your set up you have a whole new set of issues like finding the settings, documentation etc.
Now if you can get over all of that it’s still a bulky, slow and cluttered IDE that is constantly sending telemetry data and other nonsense around the web
While I haven’t tried LazyVim I would strongly recommend LunarVim to anyone new to the vim ecosystem. It installs fast, needs minimal set up and packages can be installed with a single line in the config or through packer. Most things work out if the box. But if they don’t vim is so mature you can just ask chatGPT.
Seems like ease of use is also the aim of lazyvim so I would not discourage anyone from trying this flavour as well.
In the end it is whatever works for you.
After an unfortunate bout of Java development, I was flung into the arms of Intellij, steadily won over by the indexing and the reliability of the refactoring tools. The Vim plugin was good enough and defining some chords for editor shortcuts resulted in a kind of fucked up fat vim emacs mode that was quite productive.
I, too, got fed up of spending inordinate amounts of debugging vimscript and incompatibilities to end up with something that was slower or buggier than an IDE in certain crucial ways or with highly debugging resistant niggles.
But I'm also far from in love with Intellij these days. It's slow. Prone to index corruption with lots annoyances I can't easily fix myself. I may churn to vscode. But I'm definitely in the gravity well of Intellij.
However perhaps this is worth a look. I have historically had a fairly high tolerance to plowing hours I'm never getting back into fiddling with tools. Just less than I used to. More nixos gnome, alacritty than gentoo, xmonad, urxvt...
[0]: https://github.com/dense-analysis/ale [1] https://github.com/CGamesPlay/dotfiles/blob/master/files/.co...
OK, how do I set up efm-langserver with Neovim? Good luck! You could probably use a plugin, or maybe not. You'll need a way to install LSP servers. nvm-lsp-installer? Nope,that's also deprecated, use Mason. OK, MasonInstall Black. Wait, it's not formatting anything. Oh, you might need nvim-treesitter. Um...ok, but that's installed already. Ah, you just haven't configured it correctly...here is my setup (pastes 300 lines of Lua or vimscript with zero context as to where you are supposed to load it)....Why are you using efm-langserver? Formatter.nvim is all you need! What? That's old hat! You should be using neoformat!
If you mention Ale or coc.nvim...they stare at you as if you have just stepped out of a time machine from the 19th century.
I don't think vim is meant to be an IDE. If you want an IDE, go get an IDE. If you want a text editor, vim works well. But vscode is unwieldy as a text editor, and vim is painful to contort into an IDE.
Obviously people have made things for VIM to be IDE like, some are cool to me, but completion-integrations-lang-servers always seemed so anti-vim to me. Make an HTTP request every key stroke to get suggestions? The. Latency.
The issue isn't with the fact people try to use it that way, it's that those who use vim are adamant it's the best option for doing so and berate the Other until they try.
Vim doesn’t have to be the tool you use when there are others. If it was the only tool, I’d agree that people should know it better. Thankfully it’s not the only one.
To honor the many-years of vim, I relearned a new vim feature now: using :g to run a macro like this: https://stackoverflow.com/a/5292858
If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
Or if you don't want to take the trouble to learn how to use (neo)vim, then don't use it; that decision is fine too.
The real question would be:
Why does the 50 year old editor with supposedly a huge community and tons of editors not have support for a popular formatter for probably the most popular programming language on the planet, and instead everyone has to write their own (probably buggy) variation of that integration?
Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the problem of being clunky on older laptops, but it is an amazing experience to use. I get the best of both worlds, I get really good vim emulation so I don't have to relearn editor shortcuts, I get the benefits of a modern full fledged IDE with many useful features that work out of the box with basically 0 configuration (debugger, git, tasks, etc.)
I do have a personal all-products license as well, but I hesitate to go “all in” and be dependent on them.
But it is ok to just use a lot of editors for different things. VS Code is ‘good enough’ a lot times. I like writing notes in emacs org-mode. NeoVim on the command line. Sometimes I use Helix, I think it hits a sweet spot between snappiness and minimal configuration.
which i translated to "cluttered ui" and "not responsive".
So, no, an IDE is not a better choice for everyone who want's "IDE like features". It is for some, but not everyone.
Because vim ships with any *nix machine and provides a consistent experience no matter where you use it.
Vim is the DE part and people add plugins or whatever to enrich the text editing experience with LSPs or other language aware plugins, and the I in IDE is in the form of the integration with the tooling already available on the host.
This[0] might shed some better light on the "why"
[0] https://blog.sanctum.geek.nz/series/unix-as-ide/
It’s quite disappointing we need multiple layers of assistance to even begin our work. Syntax, autocomplete, go-to def. These sound like simple things, but are fiendishly difficult. Catering to all the various languages’ their idiosyncrasies is, as you have noticed, a task beyond the community.
If something like editing some basic pieces of code takes multiple man-years to facilitate and requires “language servers” I tend to look towards the environment that produces such monstrosities.
Maybe we could stop complicating things so damn much? Impractical I know, but I won’t give up an ideal just because it can’t be reached (now).
Instead of syntax highlighting do you want… minimal syntax in languages? Instead of autocomplete do you just want to type the thing out manually? Instead of go-to def do you just want the code in 1 file?
These things didn't require language servers historically, but LSP was an attempt to reduce "many editors re-implementing the same functionality many times" to "implementing the same functionality once and connecting many editors to it". This has a cost, and YMMV on the docs for getting LSPs set up, but I don't think I'd prefer going back. I don't use it, but it seems like VSCode has 1-click plugin installs for most of these LSP integrations, more or less?
All in all it looks like we had a wildly different experience. I suspect the real issue is that I like to work with vim a million times than I did with vscode. You might me biased the other way. I feel better on the command line and it's amazing how much people have figured out already to make things run well and look nice.
Kickstart nvim: https://github.com/nvim-lua/kickstart.nvim
So yeah, highly recommended! Of course, I use the evil mode for Vim keybindings.
If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys.
If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.
An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing).
If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, finding the needed plugins for your languages, getting familiar with each plugins commands, resolve any conflicts between them, then you need file pickers, debuggers, task launchers, snippets, split screens, multi tabs, etc... Even then, you only made things work once... Good luck figuring that out in one hour...
Then you'll need to keep the config working, practice and memorize the commands, movements, and maybe customize your workflow.
Configuring vim to replace your IDE may be worth it, but "set it up in one hour" is, in my experience, extremely unrealistic.
That's absolutely representative of the kind of errors vim and neovim configurations have, because it's all independent plugins with very little ability to fix weird interactions. As soon as you have to customize anything in a slightly non-expected way you have no chance to predict if this is gonna break one of the dozen things that are basically held together with duct tape. VsCode or anyting designed to be an actual IDE with its tools better integrated doesn't suffer from this.
I’ve been using N/Vim for 25 years, and even after trying for a week or two, I just can’t get comfortable with VSCode’s way of doing it.
https://github.com/microsoft/vscode/issues/143024
Vim has some core concepts that are unique and (for those of us who adopt them) very sticky.
My entire career has been spent trying out IDEs every few years in hope of switching, dating back to Eclipse. I always try their vim modes too.
But the reality is that the core editing experience in vim is so central to how I work that I can never manage it.
I like features, and I have no love for arcane configuration of plugins. Yet to this day I've found nothing better for me than vim.
I'm currently giving neovim + i3wm a try, and there are certain things I love. Specifically instant switching between my browser and my ide, the ide and terminal.
However, the speed of the LSP(tips, method definitions when coding) is greatly exaggerated. For example for python there is the exact same 10gb ram using behemoth running in the background. Is it faster than using the same language server in vscode or idea? Yes, a bit, but definitely not 10x faster.
Also, I have 2 complaints. One is about keys. There is a huge emphasis in vim world to set your own keys for everything... The problem with that is that for some rarely used action one forgets... Or one moves to a different machine. I think plugin like lsp-zero should more prominently document their _default_ keystrokes. I prefer to learn these before I start setting my own for everything.
Second thing is what makes an ide most useful. A tree view file manager. I'm currently using nvim-tree. It's a nice plugin, and it works, but it lacks certain features like displaying large trees of empty folders in a "collapsed" way like vscode does.
So, for now I'm sticking with nvim, but I can't say for how long..
[0] https://github.com/junegunn/fzf.vim
Install https://github.com/folke/which-key.nvim and you will always have a popup that will tell you what keys to use next.
I don't actually think it's Lua's fault. And I don't necessarily want to jump and say "the improved accessibility of this thing turned it into an unusable circus", because that's both unnecessarily sassy and also likely prescribing blame in some places it doesn't fully belong. But there's something that tidally changed in that time, and especially in the past 2-3 years, my vim setup became a thing I dreaded updating (because it would 100% guaranteed, every time, break something about my workflow)
I’ve done that a couple years ago after ~15 years of happy vimming. Still yearning for the text manipulation language combined with macros, but all the other gains significantly outweigh the worse editing capabilities.
Why would someone ask "How do I set up Black with neovim to format my Python files on save?", hit the reddit/quora/another obscure forum where he finds some hostile people who doesn't well explain to him how to set up black with neovim to format for his python files on save. DAMN. Just type in "black nvim", hit return and head to repository boy. There are genuine docs and installation instructions from the author, you don't need other people to explain it to you.
Google is a search engine not an answer engine, so if you're looking for struggles instead of information you'll find it by inputting questions instead of indexes.
I think thats a disadvantage to some of these heavily customized vim flavors. Plugins don't necessarily work out of the box, and when they do they promote their own way of interaction that sometimes needs to be learned.
To get a feel for its development status I recommend reading their news post for their 23.03 release.. https://helix-editor.com/news/release-23-03-highlights/
I wish they'd add a Vi mode. ;)
[1] https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
Vim's built-in package management means all my plugins are stored as git submodules that are installed alongside my configs. I don't have to remember what extensions I have and Ctrl + P and install them one at a time.
VSCode's settings.json and extension-level configuration is also extremely cumbersome. You're paying a time tax no matter what tools you're using if you want to customize them to fit your workflow. Personally I'd rather pay that tax 1 time with Vim and then carry the same setup with me to any PC than have to eat that cost every time I need to configure VSCode on a new machine.
Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
I've just come around to accept that we've been blessed with great hardware over the years, and it's a waste if those extra CPU / GPU cycles aren't translated to significant dev productivity improvements. I'd take slower (~ ms) editor paint times over saving hours messing with vim configurations.
What's hard about this?
I'd much rather have commands in my terminal where I can search for them later than do things visually and have no record of what I did once and how to repeat it.10+ years ago, when I and almost everyone I knew were on Windows or Linux, this was simple and ubiquitous. UltraEdit, Notepad++, Vim and Emacs of course, etc, there were dozens of options to choose from.
Then I and most developers that I know switched to Macs, and now this is an alien concept. There's a dearth of open source Mac development, and much of what exists uses Electron or some other crutch to avoid committing to the Mac platform.
I've tried Neovim, but the "GUI" version is basically just the console version in a window. Might as well just skip it and do everything from the terminal.
There is MacVim, but you have to open it from the command-line in order for it to scan your home directory properly. If you pin it to your dock and launch from there, then it doesn't know who you are and launches in stock vanilla mode without reading your .vimrc. Same problem with Geany. I could PROBABLY figure out how to modify the dock icon to launch with the right flags, but the point is that this is unreasonably complex and arcane for most users.
So... I just stumble along with VS Code by default, like most people these days. It's an odd shame that cross-platform desktop app development is as dead as it is, especially considering that most devs today are not using the dominant platform anymore.
I've personally been test driving JetBrains Fleet and have to say that it's pretty okay for most of my lightweight dev needs: https://www.jetbrains.com/fleet/
It's still a bit early for it and it doesn't have the same ecosystem that VSC has, but it'll probably be even better in 1-5 years and is decent already.
For most of the more heavy work I just use JetBrains IDEs, but that's very clearly a no go for the less capable devices like my netbook.
For even lighter options, on Windows there is Notepad++, which has been okay although not an IDE.
There's also CudaText, which feels quirky but has decent language support: https://cudatext.github.io/
Maybe even something like Geany is worth a look, depending on your needs: https://www.geany.org/
By the way, if you need an IDE for Python then you're missing the point of Python.
But right now, today, at work, I have a large legacy Django project to maintain, and it's kind of nice having little things like auto code formatting and linting to help me as I go and prevent me from making dumb mistakes and saving me a ton of time so I can focus on the problem at hand, not making the code look nice for review and I can hop between buffers to fix up the tests as I change the code.
I can certainly just run black/isort/ruff what have you manually, or with pre-commit, sure. But it's more productive to be able to see changes as I work.
Sure maybe I shouldn't be using Python, and maybe the original developers should have written it in Rust or whatever. Fine. But that's not what I'm being paid for.
The final straw for me was discovering that vscode automatically updates packages and imports when moving files around a java project - something that doesn't seem possible in neovim despite hours of research and lua tinkering.
1: https://zed.dev
Edit: I did use Helix for awhile (long enough to still have muscle memory for their editing model) but it’s just not there yet and eventually moved on to Zed.
Even if they succeed commercially, chances are some day Microsoft just buys the whole thing and shuts development down a week later. No thanks.
I can't do much with vscode before also install tons of plugins and eventually setting them up. The only major difference to me is a central marketplace for vscode plugins instead of relying on github search engine+recommendations and being subject to telemetry I don't want.
The base emacs and vim documentations are actually excellent, the problem is the plugins. Just use an IDE for IDE tasks and a text editor for text editing tasks! I'm not going to start a new project in Intellij just to edit a config file or take notes about something. Why would I want to pollute my minimal emacs config so that I get a flaky IDE?
(Of course it's fun to program in a text editor because it's fast and distraction-free, which is why I use them for hobby projects. But for professional work I use professional tools.)
- https://github.com/vscode-neovim/vscode-neovim
I'm looking forward to some kind of open source VS Code killer with vim editing and native platform builds.
I won't argue at all. If you prefer IDEs, you go for it. But maybe vim and neovim aren't the best choices.
I use vim as a text editing tool, solely. My .vimrc contains ~ 20 lines. Use 2 popular plugins to help me finding and opening files, and one plugin to support editorconfigs (useful for sharing formatting rules with folks using vscode in the team). And I use makefiles or other scripts to call external tools (formatters, linters etc).
There's probably a billion of plugins which could increment my productivity, but honestly I don't care much.
Result: had to add a PPA on my Ubuntu server (not ideal but OK), most plugins require nvim 0.8+. Switched to the unstable PPA (because the stable PPA ships 0.7), turns out it doesn’t ship the latest release but instead a nightly dev build.
While editing Lua configs of Neovim, I tried to use ‘micro’ just for fun.
Result: my new EDITOR and GIT_EDITOR (that I previously set for +startinsert) are now set to ‘micro’. Alt+/ for commenting code, sane shortcuts, and code highlighting cover 90% of my needs.
(As much as I'm team *Vim) Vimscript is a mess. Oh, so you mean 'noremap' means remap this? No way! /s
The story about plugins is so true, regardless of the above. People will want you to install a plugin with 5 stars that will not play nice with anything else to do something basic like pre-save processing. Or one of the 'everything but the kitchen sink' plugins that has an end goal of giving you a Borgified Vim
And in the end I sincerely don't care, I could use the time I'm playing with this to install VSCode, or something else and have something more complete OotB
I don’t update plugins too often, because they work, but I also don’t use too many. Based on my git history, I last updated a vim plug-in 11 months ago.
What always surprises me however is why having realised the limit of this model, decide to go back to VSCode, another editor with cobbled together IDE=like functionalities? IDEs are nice. Last time I checked VSCode debugging was still subpar and required fiddling with configurations.
E.g. for me, "vim" is more like an input scheme that works across editors, less a particular product.
I am mostly using sublime text for programming projects and vim for editing configs on headless servers. If I like to use vim for programming I'd try to add vim keybindings to my IDE instead of adding an IDE to vim.
Deleted Comment
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Something like:
Now how you integrate this into your config is again a little programming problem in and of itself. But it's not really a complex programming problem. You are after all not trying to write some large complex and scalable system. You probably have all the tools necessary to organize your code well. I went with a highly functional approach which passes functions around everywhere but you may be more familiar or happy with another approach. The beauty of a neovim configuration is that you are the only person who needs to maintain it.I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.
That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this job otherwise.
However, my time is limited. I have to be selective in what I spend time learning. Much of that choice is determined by my employer, project and other requirements. Free time left over for learning other things is even more limited.
Learning another language and API and plugin ecosystem just so I can configure my editor? Maybe for some people, that's time well spent, but personally - having spent a fair bit of time with neovim to give it a fair shake - I realized that what I don't need is a perfect artisinal text editor, but a good-enough IDE that lets me do the things I'm either actually interested in, or paid to do.
Vim as a simple text editor? Perfect, use it every day when dropping into a headless server to edit a config file or two. For an IDE? I don't love vscode, but for what I need, it's fine.
You’re not though, there’s no lock-in.
If you are deeply involved in the community and are willing to put in the time, sure, you could probably build something superior to vscode. But the time invested to get there might not be worth the marginal productivity gains.
I started with this config. This made it a lot easier to start.
It will never be a ctrl+p install away from feature X system though. You do have to put some effort in.
Very easy to setup. Moreover, when I'm on a different computer and open (vanilla) vim without any configurations. I know that everything is more or less the same as my default vim environment. I think it's not that hard to learn developing in the default vim environment, with some minor tweaks.
Also related, How to Do 90% of What Plugins Do (With Just Vim): https://www.youtube.com/watch?v=XA2WjJbmmoM
I was absolutely thrilled to find that VSCode’s vim emulation included vim-surround! I guess someone out there has the same problem I do.
So much programming is editing various text surrounds: parents, braces, brackets, quotes of various flavors.
I also really like having semantic completions. I get by with YouCompleteMe, but it’s a little jank in my build system.
I need a small, fast text editor that works over remote connections, works on Linux and Windows, needs no configuration or plugins to be useful, and just works and gets out of my way. VSCode does not fulfill most of those needs. Plain old vim (and not neovim) does.
I learned how to change colorscheme more than 20 years ago because my CRT monitor made it impossible to read comments on default themes. I use same command today on my local terminals, bastions accessible via web or remote sessions ... for basically the same reason.
If you code from one machine spending time to set up IDE and then leaving it be makes sense. But if you are more of an admin, or learn a lot and jump from host to host, from learning platform temporary environments to cloud environments, from mobile to some remote mainframe that is being decommissioned for past 7 years? You could just figure out how to change 2-3 basic options and have a predictable environment for next few decades.
I think it's easy to go overboard though. A lot of plugins (and these meta-plugins) provide little value over what vim can do on its own with a little configuration.
Of course with these packages you are trading flexibility for features and you are inheriting ways of working from someone stranger, but it is not that much different than using any IDE. While this offers a nice(r) gate into vim-ming it does kind a miss the biggest perk of using vim - which is molding it to your exact needs and preferences, but that is not something you will do over night. I have been in both camps. I have installed way too many plugins and then gone to very sparse configuration. I think with NeoVim I have found somewhat of a balance, but I think reworking your vim config is a natural thing every five years or so. We grow as people and developers and our needs change and the tools evolve.
These are the three lines I always use on any vim install.
The first two lines are crucial, because I find rainbow colored text and flashing punctuation extremely distracting. If you find monochrome code unreadable, then that's a problem with your formatting style that you can easily fix.The last line is really handy for not having to hold down shift so much.
I'm not going to sacrifice my 95% use case for the 5% of time (probably even less) that I am in a situation where I don't have access to my own config. If I am just editing a few lines in a config file on a server, it doesn't really matter that I don't have my config.
With that being said, not everyone wants or needs plugins and their needs are different from mine. Do what serves your needs. I would simply advise anyone to consider if their workflow is serving themselves or not. A lot of people get stuck in the mindset that they need to simplify in order to facilitate easy transitions to situations that just don't come up all that often.
I don't play many games these days, and I certainly don't use their hotkeys (I play exclusively on consoles these days, lazily).
None of this likely has anything to do with the article. I'm sorry to report that I did not read it. I come here for the commentary, not the article. I am guilty of that.
While my custom keybindings are something I would not want to give up they can be replicated in any other editor that provides this basic functionality. What cannot be replicated is the whole reason why I prefer emacs, I like being able to use it like a file explorer, like a terminal, I like being able to open or edit pretty much any type of file I ever use. When you combine the ability to work/view most of the files with consistent keybindings, that is the killer feature that emacs provides, its never been about the keybindings.
I'm curious though, I never really got into vim as soon I realized that it only makes sense if your layout is qwerty. Is vim just its keybindings? or is it like emacs in that the keybindings are not the main reason people use it?.
I get that too but with Vim. People think Vim is just about the controls because all they know about Vim is the :q joke. No, that IDE's Vim plugin doesn't cut it, because unfortunately it comes with an IDE and its distracting overloaded UI, weird tab switching behaviour, absolutely infuriating popups and other annoyances.
Vim being just a really flexible and fast editor with a mostly empty status line as the entire user interface is a feature.
The other thing I really love is the integration with the old ed editor so you can quickly do several really flexible edits with regex and get what you want. I’m sure emac’s built in functionality can do some/most of the stuff but it’s no where near as concise and other editors have no such built in functionality to speak of.
Edit: TLDR - vim is sometimes better than sed for making changes to files, but in my mind that's about it.
Everyone who types on a computer eight hours a day should learn the Vim language. Yes it's hard initially, but that's the case with everything new and different. But getting better every day and having more fun coding or writing should be motivation enough. Also, imagine, if you work over a decade, how many times you had to learn a new editor (notepad++, atom, eclipse, ...) some of which do not exist anymore. If you once learned the vim language, you are getting stronger. There is a reason the editor has existed since the eclipse of programming.
The Vim grammar is exceptional, as spoken language has verbs, subjects, and objects, as does the Vim language. The grammar has different verbs, to begin with. Copying (or yanking) in Vim with y, deleting with d, pasting with p, changing with c, and so on.
You can also see in the comments here people fight over Vim and VSCode, where the natural beauty is the language behind Vim. If you do not want to configure and customize your own, use VSCode and add the Vim extension. But if you're going to get better at your job, you should try the Vim language.
Once mastered, you edit text at the speed of thought. Sounds cheeky, but it's true for me. Instead of thinking, "I want to edit that word," my fingers jump to it and change it with a few keystrokes.
I wrote more on https://www.ssp.sh/blog/why-using-neovim-data-engineer-and-w... in case you are interested.
I also would not say learning vim makes you a better programmer or a better writer. It makes inputting and changing text easier and faster, but that's not what programming or writing is about.
I agree that the vim grammar is nice, but the bigger thing that differentiates editing text in vim versus other editors is its modality. And it is the modality that allows it to have a grammar in the first place. And that grammar does break down in places, just look at every keybind starting with g.
So yes, try vim, because it is pretty great. But if it doesn't work for you, move on to something that does.