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.
Can you actually explain how it's suboptimal UX, and what I could be doing better. I want a simple IDE, not suboptimal bloat. I don't need 200 keybinds to make a vue component.
Just because you have a bunch of custom quirks doesn't mean that I do.
The thing about vim and emacs is that both of them, out of the box, suck. BUT, what they both offer better than anything else, is the ability to gradually modify them to match what your brain needs.
I 100% agree with your hyperbolic "200 keybinds to make a view component" But that's ...that's not how it works unless that's what your brain wants.
With ALL editors you eventually encounter "ugh, this is frustrating" or "i wish i didn't have to do that" and then you have 30+ years of plugins and configs you can draw on to modify it to match your liking without any coding. VERY rarely, you'll want to tweak it in a way that there isn't a plugin / config for and you'll find communities of very helpful people who'll respond with "what about this solution..."
The fact is that _your_ brain is different from everyone else's. The less configurable an editor is the less it will be able to support the way your brain likes to work.
You _can_ accept pre-made defaults like those provided by VSCode OR you can gradually refine your editor to be a perfectly crafted tool for your particular and very individual way of thinking.
I choose the latter because i spend SO much time staring at my editor and trying to convince it to do things that are almost always better with automated assistance from it.
In my case, I'd prefer to do so. I'm a different use-case though, I'm a server admin so I want to be as comfortable with bare-bones defaults as possible so that I can jump on any server and just use Vim (or sometime just vi!). I can't afford the time it would take to set up a custom config on every server in every environment, so the most I need is a basic .vimrc that has `set number` and a couple netrw tweaks that I can copy with scp and get going. Most of the time I don't even copy that over and run `:set number` when I open a file.
Note that I'm still an intermediate Vim user at best, splits and markers are the most complex features I use (no macros yet). I know I can edit remote files, so maybe once I'm comfortable with that then I can set up some real customization in each environment.
Sysadm here as well, been using vi since the '80s. A year or so ago I threw away all my custom vimrc and went with (nearly) bone stock LunarVim, and have really enjoyed getting off the treadmill of maintaining a custom vim setup. Partly because of the 100s of machines issue, partly because of managing plugins and interactions between them. I program maybe 5% of the time, so the stuff I do to make it IDE-like often isn't worth maintaining for that 5% time, so I often end up with partially working plugins or whatnot.
LunarVIM has been a bit tricky, mostly related to upgrades around LunarVIM, usually neovim updates. But, the capabilities of having Language Server in vim have been so refreshing! Particularly when working with Python 2 code to bring it up to Python 3, pretty much just follow what Language Server says.
When it gets right down to it, there are only a couple little tweaks from my old setup I want to carry over, everything else I want to go back to using defaults (places where I've diverged my own functionality) and stop pushing around a poorly maintained manual config that gives me 10% of what Lunar or similar gives.
One of the things I noticed about LunarVim is that they were not very receptive about it in the official NeoVim rooms whereas people there (including NeoVim developers) were quite positive about LazyVim. The other alternative they suggested was https://github.com/echasnovski/mini.nvim
TLDR is that with the global lvim object, custom path, breakages because of unstable plugins it causes a lot of support issues where people go to the official NeoVim channel and not the LunarVim one.
I switched to LazyVim, which is developed by folke (one of the main developers of most of the plugins (trouble.nvim, tokyonight, which-key, lazy.nvim etc) https://github.com/folke?tab=repositories) the other "vim distributions" use anyway.
I'm also very happy I only maintain now "one configuration", I really disliked having "nvim" and "lvim" simultaneously on the same machine.
The method of checking out the "starter" repo https://www.lazyvim.org/installation and simply deleting the .git folder is a LOT nicer than an annoying installation script that does a gazillion things (LunarVim).
I've got a painstakingly crafted neovim config that approximately works how I want it to, most of the time, and I'm happy with it. But it's taken a while, a lot of nights inevitably spent mucking with plugins and LSP and gluing it all together instead of working on more rewarding things.
I'd be lying if I said I'd never thrown something at a wall in frustration due to vim acting in some bizarre, inexplicable way and not knowing why, although that definitely happens less nowadays with nvim.
I hadn't heard of lazyvim until the other day and I doubted I'd really need it, but now that I know it's something new from folke, I'm gonna have to give it a shot. Always quality stuff from him -- dude is a machine, when does he sleep?
Exactly. You absolutely need maximum configurability for the most important tools in your arsenal. You can pass with defaults on less used tools but everyday stuff should be as efficient as possible. In my case those tools are editor, shell, browser, OS, media player - they are customized extensivelly.
Any time somebody else creates something instead of you, it must be accepted as suboptimal. We are all unique human beeings and have different kinds of habits and disfunctions, levels of knowledge etc. so 1 setup for all is pretty much impossible and nobody else can do it but you. Any time you accept that, you are accepting suboptimal UX. If you are doing so you are admiting that you are either lazy, or you are good with your potential being maxed out at that point (if you are accepting anything less then most efficent workflow, given that time is the most precious resource).
Actually, when I look at how most of my colegues are slow using their tools of choice, even senior ones, I imagine I would rather kill myself then using such setup.
On the flip side, I've been using VIM/emacs for over a dozen years, and have gone from extensive user made configs to these starter packs (DOOM Emacs with some custom stuff on top). I mean I'm happy with a well thought out "total conversion" of emacs. I learn the UX on top (that is really nice) and I add my own. If I started from scratch it would probably be sub-optimal ( I mean I could recreate DOOM, but why?)
Or rather it's a matter of trade-offs and some things are just "good enough". It's not up to you what's good enough for him or me, especially weighed against the amount of effort I might have to invest to get something that's "optimal" for me.
Cant wait until you create your programming language to use in the company you created racking up the optimal millions while laughing at us lazy slobs!
Maybe YOU should stop calling other people lazy for something actually very productive, aka not wasting million hours tinkering with lua for marginal returns over investment, often on company time…
Just because it’s predefined doesn’t mean it’s suboptimal. On the contrary - anything I do myself likely has less about of thought and consideration from an officially published configuration.
That is just not true. Anything not customized to your specific need and context is certainly more complex and bloated. "Officially published" is a common falacy (resorting to authority)
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.
I had the same issues with AstroVim when it was first coming together. Looks like the creator was rapidly iterating to try and make it easier to configure.
It’s now in a stable enough state that I haven’t had any issues.
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.
With LazyVim I basically got rid of the both, and now my vim config is literally a few overrides https://www.lazyvim.org/configuration/general that are not distribution specific at all.
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.
> Just copy/clone the dotfiles, launch neovim and run a command to update the plugins and everything is good to go.
The last time I did anything like this was back in 2016, where I'd cribbed a relatively customized vim config that my boss had rigged up for python and C++ development. I spent so much time troubleshooting plugins and integrations across the various systems I was trying to do development on, I've been burned out on "just install a plugin and update stuff."
Even now, working with Ruby and VS Code, I feel like I have to troubleshoot my plugin stack once every other month because some behavior isn't working quite right. I loathe the idea of ever having to set this up on another machine, and I miss when I was a Mac developer who just (had to) use XCode. It was flawed, certainly, but the base function set Just Worked.
I used to have the stomach for having to chase down config issues and customizing my esoteric editor, but now I get extremely suspicious whenever someone says something like "just copy the files and re-run the install command". It's never been that simple in my experience.
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.
I think it’s because of the statement “you can only copy what you understand”. I get the sentiment, but comes off as paternal rather than collaborative.
If anything, it's sound advice. Most of my early day colleagues copy/pasted everything from StackOverflow without understanding any of it, causing huge issues down the line.
They were the classic duct-tape programmers and that didn't help them at all to grow as programmers and even impacted their careers.
Labeling this as "macho" implies that properly understanding your tools is actively bad. Couldn't be further from the truth.
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.
That makes sense, and I definitely wasn't trying to denigrate ST. Having not touched Windows since 2003, and having come from the vim world I had to learn a few aspects of Sublime to help my coworkers out, and just like you say, having to learn a new set of keybindings was a pain.
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.
This exists in VSCode, it's called workspaces. You save a .workspace file, then with either an extension like this one[1] bound a key (very easy to do), or just using the command pallette to open it, you can switch to any workspace you want; in the same window or a new window, and you can have the exact files/layout/tabs you had open the last time you were using that workspace open automatically.
It's very simple. It's certainly more simple from first principles than your method, but if you are adept at using the shell as you clearly are, then your 'fg && vim ctrl-p` certainly must feel pretty natural; but I hope you understand that this is only because you have probably lived on the shell for many years. I used to do that too, with tmux and vim configs, but now I find it much simpler, faster, and better to use VSCode. I'm not saying you should switch, I'm only saying that just because it's not on the shell doesn't mean it's worse.
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.
> 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.
This is where your analogy breaks down for me. The "chainsaw" (VSCode) is absolutely perfect for the tasks I'm using it for. When I write Python code, the Python extension gives me exactly what I want. That's because the environment it creates has been fine-tuned based on feedback from thousands of users with similar requirements to my own. There's no need for me to modify anything, any more than I modify my car or my trousers. It's simply ready for me to do professional work, and whenever I have special requirements, I know that I will find an extension that caters to them also. I don't need or want to reinvent a wheel that has been invented hundreds of times already, and polished to perfection through more man-hours than I could ever hope to invest myself.
You get exactly the same functionality with (neo)vim plugins.
Only difference is that because vim has been open-source for decade, there are many many more plugins, and hence the choice is harder to make. VSCode also helped improve the (neo)vim experience (e.g. language servers)
Comparing VSCode and Vim is like comparing a standard calculator with an RPN one.
> Only difference is that because vim has been open-source for decade, there are many many more plugins
No, the main difference is in the quality of plugins, not in how many there are.
For example, Rust-Analyzer provides an official VSCode extension, which is professionally maintained by members of the Rust core team. The extension is part of the Rust-Analyzer project itself, and can be installed with a single click, at which point it just works.
For Vim, you have to manually download (and update) the Rust-Analyzer binary, install a third-party plugin, configure them to work together, and hope (1) that the whole thing doesn't break when the plugin or the language server is updated, and (2) that this concoction provides a tiny fraction of the functionality that the official VSCode extension does.
FWIW, I just needed to install the default nvim-lspconfig plugin (it's provided by the Neovim maintainers, and it doesn't do anything besides provide default LSP server configs for a lot of languages to the builtin Neovim LSP client), paste in the keybinds recommended by the README, and call lspconfig.rust_analyzer.setup in init.lua. Configures itself to start whenever rust_analyzer is in PATH. Seems to work well enough! I don't think it's missing any functionality.
I agree with your main point, you have to do quite a few things to configure these plugins and some of it is not straightforward.
However, I program rust using the lunarvim default configuration for vim and it has been very straightforward. I have all features I need to program comfortably and I didn't need to configure anything, the defaults were good enough for me.
So that doesn't mean that vim cannot have the same easy of use if there exists some sane default configuration you can just install.
I am happy with it and not going to change to vscode or something else.
I'm a vim user, but only because of the keybinds. I use VS code an equal amount because I often get too frustrated trying to wire the disparate vim tools. The never ending fiddling and 30-step process to get the equivalent of one click in vs code is exhausting.
The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
One of the tips in The Pragmatic Programmer is "Achieve Editor Fluency", wherever it's Vim, VS Code, or Sublime Text. I use IDEA for java code because in my job, I browse code more often than I edit it, and IDEA is nice for that. I also use WebStorm for the JS part because it's also good for that. But I invested my time into VIM because I can do everything above with it and even more. I don't want my editor to become an IDE, I want it to be powerful in editing and allow for integration, as there are slews of tools that work with code and text.
You should invest in your tools, be it Vim or VS Code. I chose Vim and Sublime Text because of their speed, and JetBrains' IDEs because of their code analysis engine. You may have different criteria, but try to follow the tip.
I do exactly what you described and indicated that clearly in my post.
What I'm perturbed by are the people who take it to extremes, and are happy to spend hours a week tweaking things, and can't fathom someone else might not enjoy doing the same.
> The people who _enjoy_ the toil seem to truly struggle to comprehend that someone might not want to spend hours upon hours learning how to get things working, only to immediately forget.
It's worse than that, it's a religion. Many of them truly seem to believe they're achieving a higher "hacker rank" or something, while most of it is just tedium and very low level learning.
It's rarely learning huge, game changing concepts. Frequently it's just chasing obscure docs to obscure forums to obscure repos for stuff some PhD student half baked a decade ago on their way to their biochemistry thesis.
Guess what, I work in DevOps, that's just my dayjob, anyway, I don't want to do it as a hobby in Vim, too :-))
And I say this as an "also Vim user". I.e. I use Vim and I've used it for more than a decade, just not exclusively, best tool for the job and all that.
For what it's worth, the 'VSCode-level' functionality in my init.lua has probably required roughly a few hours of maintenance over the ~7 years I've been using Neovim. The LSP setup is just a matter of finding a plugin manager (or not), installing the lspconfig plugin, pasting in the config from the README, and inserting a single line that contains the name of the language server you want to configure.
It can definitely lead you down all sorts of twisty paths if you look at other people's elaborate configs and decide to do that sort of stuff yourself but it's very pleasant/low-maintenance if you stick to the basics (meaning roughly what people do with VSCode). It takes me roughly a few minutes to configure Neovim for a new language :)
(Of course, there's some other stuff in my init.lua that I've put there for fun, like clipboard and window management scripts, but that's not strictly necessary. I've spent a bit more time figuring out the Lua API to write these, but I personally think it's worth it for the extra ability to mold the editor to my needs).
> No, the main difference is in the quality of plugins, not in how many there are.
I don't think that is true. If you browse the vscode marketplace and search e.g. for python [1] you literally get hundreds of plugins. If you scroll down only a bit, you quickly end up at plugins that only have a few hundred to a few ten downloads. I highly doubt that the quality of those plugins is better than the plugins for (neo)vim.
For your Rust-Analyzer Plugin example: I can install Rust-Analyzer with Mason in a few seconds as well and then (if you have lsp-zero [3] installed) it also just works™.
But I agree, keeping a vim configuration up to date is akin to a hobby (which I by the way enjoy quite bit).
That's just plain untrue. Vim always kept its own rust-analyzer binary and prompted me to update it. I use emacs now and actually have to update it myself
If what you need to do is cut down bunch of trees then chainsaw is exactly what you need. No one in their right minds would start with a knife and start building it into a saw and then attach a motor to motorize it. Mind you we were carving a bowl, but as per Internet argument you completely dismissed the use case and inserted your own.
If VSCode does exactly what you need out of the box exactly how you want it to do it, then you are set and you should use VSCode.
The problem is that Vim can be used to create config files and source code files among other things. VS Code can be used for very much the same things.
The output of both tools is practically the same thing.
The niche of things Vim can do and VS Code can't is tiny and constantly decreasing.
It's always been like this. Vim is an editor, and so is Sublime Text, Emacs, VS Code, Geany, Kate, Notepad++, and more. What sets vim apart is its ubiquity (it's been on every Linux box I touched) and its philosophy of editing text (modal editing). Apart from that, it's a matter of preferences and practicality.
I can think of a few YouTubers who would and probably have done just what you described. Now that I say that though, I realized you used the phrase "right mind" and I don't think I'd count many if any in that cohort.
Nah vs code is a multitool with both a hook blade (the knife younuse for carving out a bowl) And a chainsaw....
Slightly more unwieldy in that specific narrow use case than a plain hook knife but you don't need a second tool to cut the log you take the wood for the bowl from...
In other words, it's a tool that let's you do near anything with minimal modifications whereas vim is a tool that requires significant modification just to do Any task other than looking at it.
Yes. The advice to turn the yoke upside down is supposed to reference remapping Caps Lock to Escape, without which Vim destroys your pinky on a standard keyboard. But it's the choice of professionals, so what can we do?
I've been using Ctrl-[ instead of Esc for so long that I forget that a lot of people don't know about it. This may not be convenient on non-English keyboard layouts.
small fun fact:
I switched to this when the escape key was taken from me (thanks again NOT apple)
After switching to a newer MacBook that has the escape key I did not start using that again, but stuck to the Ctrl-[ as it just works.
I'm playing into the joke here, but on most terminals, alt + <key> will actually be sent to the program as <esc> + key. You can use this to avoid pressing escape in Neovim.
+1. I mainly use this approach. If your next intended move is to go to the next line, Alt-J will exit insert mode and go to the next line immediately.
Also the same for Alt+w/W/b/B, Alt+o, Alt+0, etc etc and it's just a matter of using your left thumb at the same time as navigating.
Nice, I didn’t pick up on that one. And I do have Caps Lock mapped to remapped to Escape haha.
If any vim enthusiasts haven’t read this history before, this article [1] provides a good overview of how ex/vi came to be. The photo of the Lear Siegler ADM-3A keyboard used by Bill Joy largely explains the odd choice of keys.
Trick for those wanting caps lock to be compose instead: ctrl-c also works as escape, and has historically been slightly faster due to sidestepping the escape timeout.
There is a timeout on multi-key mappings, so if you need to type fd0 you type f, wait 'timeoutlen' (1 second by default apparently), then type d0.
That's a pain, but it doesn't come up often. In return you get quite a lot of functionality (due to vim being modal) without having to move your fingers beyond the letter keys, which is quite relaxing.
Like many things in our field, we try to justify our choices, and because generally folks in our field holds high standards about themselves, we should justify as the only right way. What in reality, it is all about user preference.
In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.
I take it you've never played a fast game with keyboard controls? :-)
They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.
Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.
In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.
Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).
As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.
That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).
Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.
The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.
Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.
For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.
Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.
The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.
Did you read my original comment? I literally mentioned QWERTY as another example of backwards compatibility screwing everyone over.
I use QWERTY because I have to, I don't like it and I can't do much about it in practice. People frequently defend Vi's HJKL vehemently - just like - if I'm not mistaken - you, presenting it as a superior option for some reason.
I actually switch back and forth and I've thought many times about remapping u and l and j and k... you know what, maybe I should just bite the bullet.
HUJK instead of HJKL, basically WASD moved to the right :-)
Yeah. I actually find that no highlighting in some ways helps you understand the language better. Because you have to parse it, not rely on the highlighting to do it for you. When I was learning Rust, I spent a year writing Rust in vanilla vim which is by some accounts insane. But I did it for the uh immersion. And I’m happy with the result.
I do use Zed for working on projects when on my home turf. It’s just that I’ve sworn off wasting time configuring Vim everywhere. That too is advantageous because you have to have a much more thorough knowledge of the vim tool instead of relying on plugins to make it work for you. And vim is everywhere.
The thing is, using a plugin like ‘surround’ Is just so nice. When you’ve chosen to use a pleasant and powerful editor, I don’t see the benefit in depriving oneself of further pleasure and power.
I use vanilla vim when I have to ssh into a server and work on some config files. As such, I much prefer it to nano, and it's installed, or easily installable, on any Linux server.
For that use case, it's absolutely great. No complaints.
I spent years and years enjoying using vim for the same purpose when I was a sysadmin. I was absolutely disgusted beyond belief to find out people actually used it as their daily IDE when I became a developer.
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.
The correct choice is to instead use something that doesn't require a really long time to both learn properly and modify until it's decently functional, even including premade distributions for it, and just using something to get the job done so that, you know, you get the job done instead of preparing to get it done and not getting it done.
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.
This was supposed to parody how some of Vim's default shortcuts just flat out do not work on non-US keyboards, because e.g. typing [ requires pressing AltGr+8 on German layouts, but Ctrl+AltGr+8 is not the same thing as Ctrl+[.
And yes, it was also a reference to the Gimli glider.
I'm Czech and I use the English layout with UCW accented letters accessible via AltGr. It's much more convenient than tke standard Czech keyboard, even outside of Vim.
>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
null-ls is now archived so you don't need it (dark humor). Anyway - you needed it for linting\formatting etc.
Modern syntax highlighting comes with treesitter, you don't need anything but theme that supports it.
You also don't really need Mason unless you want an automated way of managing your providers. And LSP-config+Co is needed anyway - neovim\VSCode and other editors use it all the same.
>Also I don’t know what world you live in ...
We were talking about building a config, not about learning every dark corner of it. You don't have to go much further than Packer's or LazyVim readme.md to get a grasp of what's going on. Things were much harder when it was vim and vimscript + some plugins.
> 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 spent quite a long time trying to get nvim-jdtls configured correctly and playing well with all the other LSPs I have configured. Had it mostly working and I did like writing a large amount of Java for a greenfield project in Neovim, but then a bunch of it broke again when I upgraded either nvim or one of its plugins. So I spent some time trying to make the IdeaVim plugin work as closely as I can get it to my Neovim setup and am finding that to be a happy medium. But I might still come back to Neovim for raw editing at some point if the LSP issues do get sorted out.
Same. IntelliJ is just too damn good for JVM work, and specially for Kotlin. jdtls ans other Java langservers are decent, but unfortunately, kotlin_language_server is miles behind IntelliJ.
Not only that, but in my experience everyone else will be using IntelliJ, so the project is usually dependent on IntelliJ in some form. Sometimes subtlely, sometimes not so subtlely. It will usually build with gradle since it has to for CI/CD, but beyond that everytime I worked on a new project I had to fix all kinds of subtle problems that were the result of some config/state that IntelliJ keeps outside the repo and nobody notices because they all use IntelliJ.
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.
When it's having a particular bad day I can sometimes rename a file-local unexported symbol faster than it can (pointlessly) search the entire repository for the name. Or when it's on an indexing holiday I can navigate by memory to a file I want with mouse-and-tree faster than it can. This make me sad and feels more common than it used to.
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 see where you're coming from. FWIW, I've been using Neovim for an odd 7 years or so and only use plugins where absolutely necessary. I'll usually just add an appropriate BufWritePost (trigger after saving the buffer) autocommand for the language's file extension that does what I want. Or I'll add a keybind in .config/nvim/ftplugin/<lang>.vim (or <lang>.lua). You can do fancier stuff with plugins but I find that I just don't need it (and you probably don't either, by the looks of it).
The default LSP client config at https://github.com/neovim/nvim-lspconfig#suggested-configura... sets everything up for you, if you're using an LSP server. I'm not sure why it hasn't been merged into the Neovim repo; possibly because they want to keep the editor core fast and minimal.
All this means you have to do a little more configuring than with something like VSCode, but to be honest, I haven't legitimately needed to make big changes to my config in a few years. There's stuff I add for fun (like little lua scripts to manage my clipboard and to layout tabs the way I want), but to maintain a 'VSCode' level of functionality none of it's needed. The advantage of spending a little extra time, for me, has been that my editor 'fits like a glove', so to speak :)
So basically your problem is feeling insecure because other people do different choices.
I didn't care following all the trends, my setup use coc.nvim[1] and I don't have any problem with that. I don't care about black, I am fine writing python stuff without it.
Your setup doesn't have to be complicated because others is.
The problem is when you are a newbie to a space, you don't know the difference between "cool" and "what is the best practice as defined by the experts".
I'm a huge Neovim user, but the amount of "hey guys I just rewrote this perfectly fine plugin in Lua [for the Nth time] check it out" posts every day are tiring.
I’ve definitely been down the Vim config rabbit hole and struggled to find the right balance between “cool” (actively developed with newer features) vs. “best practice” (more mature and stable). My current approach is to search Hacker News comments for “vim plugin-feature-I-want” and the most popular comments usually point me in the right direction.
For what it’s worth, I use Neovim with ALE at the moment and it works just fine.
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.
not really..
vim is easy to extend and adapt.
You loose that with only vim mode in vscode.
You also loose the ecosystem and relevant core functionality like most vim core functionality like :grep :vim :make, quickfix list, arglist etc..
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?
It does, you'd just have to install a python plugin that registers the autocommand-- or leave out the plugin and register the autocommand yourself. The (n)vim/emacs communities aren't fond of integrating the hot new thing for each language directly into the editor-- I think this is a lesson that comes from being 50 years old!
As for whether it would be buggy, I'd doubt it? Unless Black's principle of operation is different from most formatters, it should just write the formatted contents to the file, right? The autocommand you'd use would just run Black on your current file on each save. So where % is Vim's symbol for the name of the currently open file, :silent! suppresses stdout/stderr from the formatter, and :! runs a command:
autocmd BufWritePost *.py silent! !<format_cmd> %
(Don't quote me on that, but it should be essentially correct. I'm not at a computer right now.)
Actually, it looks like you can install an (n)vim plugin from the official Black repo here:
Anyway, I think it's actually a really cool effect of doing this that you realize a lot of the scaffolding underneath most editors _isn't_ that complicated! It's totally understandable :)
Because it's been here before the formatter and will be here after it. I don't think there is any support for any formatting tool, except the general act of formatting for every formatting tool. And if you find your config has multiple lines just to format languages you've touched, then it's time to build a plugin or search for one. And if you find it, and it's quite not like you want, extend it as most plugins are open source and free.
If the tool doesn't suit you, build your own or find another.
> 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.
JetBrains product has always been fast for me, as I wouldn't run them on a 10-year-old computer with an HDD drive. They've been very configurable, more than other IDEs I've used. An IDE is a host of tools, so the UI can be dense because they can do so much stuff. You invest in your tools, and that can also mean buying a powerful enough computer to do the stuff you want.
> the UI can be dense because they can do so much stuff.
Vim can do a lot of stuff, but its UI is very minimal. That's because it recognized that there are already many buttons right under your fingers, so there's no point in putting more of them on the screen.
Vim has the potential to do a lot of stuff. It is extensible to a point that you can build any JetBrains' IDE with it (their main selling point is the code analysis part). But right out of the box, editing is its only strong point.
GUI is more discoverable than terminal software. You open a project with WebStorm, it can already understand it, and you can configure a build process in a few clicks.
i share your feelings and i'm a happy jetbrains customer (and i dont do java!); but i see the point of people not feeling comfortable using them specially when coming from more pared-down experiences. emacs and neovim are also snappier, vscode is marginally snappier, doesn't bother me but it's noticeable.
JB also has some glaring holes, like the inability of easily specifying an env file to load when running projects from the IDE runner (and the plugin to do this was half broken with the 2023 versions)
The 'New UI' in PyCharm 2023 is pretty nice. Less of an airplane cockpit vibe. Its still a total hog of compute resources but I have an M1 machine and never notice any problems.
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?
Notice I said these features sound (and should be) easy, but they are not. The “intellisense” features themselves are fine as QoL improvements.
It’s the environment and the languages themselves that produces these “problems”. I mean, let’s say, Python. I just don’t know what to say to you if you think sanity lies in that direction.
I’m in the somewhat marginal Alan Kay camp and think computing can and should be reconsidered from scratch. I cannot prove we are on a dead end, but I have the strong sense that we are and I want to encourage other paradigms and ways of approaching development and computing in general.
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.
Because I don't need to? I honestly think it would be easier to follow along with a tutorial for whatever language I'm using in any of those editors you've mentioned than one for Vim or Emacs.
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.
I actually dread the day Helix eventually gets the WebAssembly plugins system that's been floated around. The current Helix culture of "you get a Kakoune-like editor that can do three categories of "bonus" things, and NOTHING ELSE" encourages a more manageable pace of development (and maybe more importantly: slower updates for those of us exhausted of software churn breaking our stacks constantly), and discourages feature creep/bloat. I love where Helix is at currently. After some tinkering and adjusting a few keybinds, and after a few releases for them to fix various bugs I'd been dealing with, it's quickly become my new favorite editor, and has nearly fully replaced NeoVim. Hats off to Helix.
I couldn't agree more with this! I actively don't want plugins for Helix either - as tempting as it sounds. Nvim is already a create plugin based modal editor with a rich ecosystem, so Helix's no-config philosophy is kinda it's whole selling point.
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.
I think it takes at least one month to get into vim, let alone mastering any of the plugins, and afterwards you keep learning every day.
IMO this is not due to the difficulty of installing plugins (which is becoming easier and easier), but rather to embrace the vim "philosophy".
Many think that VSCode is better because easier to use and has more features. However I think this is because they don't use any advanced features of VSCode either, only the glaring obvious ones.
I am not talking about learning vim. Of course, that is a huge time investment and you have to make your own judgement if that is worth it (for me it absolutely was, but I was in University with few obligations and lots of time).
I am talking purely about going from a vim without IDE-like tooling to one including it. That can be done in an hour.
Still, IMO it can only be done in an hour if you've done it already... You need more time than that for finding the plugin candidates, evaluating them, installing the right plugins, then you need a test run where you lookup the key bindings, on vim it's not as easy to discover features as in a "GUI" IDE.
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.
You’re absolutely right that this can happen, but wrong that it is representative. Let’s take all the serious vim users in the world. How many have this kind of plugin hell experience? A tiny percentage.
Serious vim users don’t try to create a kitchen sink IDE. They start with a vanilla base and with their way up, including just the features that are important to them.
Starting with something like LazyVim is fine too. Then you get a rich set of plugins that have been configured for you. Lovely! And now just be thoughtful about what you later on top.
Yet half the (neo)vim people in this thread are yelling it's the One True IDE that can, in fact, do everything, and if you are using VSCode or IntelliJ or whatever then you must be a noob or too lazy to invest time in your tools.
"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..)"
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.
There's an extension for almost everything, right there in the UI.
The fact that it's electron means there is native support for graphical preview in e.g. markdown, mermaid, plantuml, jupyter, etc.
Relatively sane defaults. I haven't tweaked much of the editor except the color scheme and shell startup timeout.
Zero messing around with language server setup. It's 'install extension' and go. Sometimes a window reload is required, but it restores the session intact, even with terminal history.
Remote ssh (and WSL on windows) is super seamless. The way I've used vim was always ssh+tmux. Most of this is unnecessary with remote ssh in vscode.
There's probably more but these are what comes to mind immediately.
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.
As a recent LunarVim user, I can really recommend it.
Coming from vanilla vim, it has been a pleasure to use. More power at the cost of less configuration. And beginner friendly (for someone that's familiar with vim)
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.
LazyVim gives you Mason to install Black. You could use :MasonInstall black and restart Nvim to ensure black is loaded.
Or if you want to have it automatically available on other setups, black is a builtin formatter in Null-LS, so you would just have to add "black" to your builtin list for your Null-LS configuration.
Format on save is already set up.
I've not used LazyVim. It took me 30seconds to look at the docs to see what was available. Yes, getting to the point where you have Mason, NullLS and LspConfig and the glue-plugins to make them work well together takes more than 30-seconds to set up, but once it is adding a new LSP or formatter takes no time at all.
I think you're going about the wrong way if you're reaching to plugin for every simple thing in vim. Granted, I will say that vim has steep learning curve, it kinda gives you the power to do your _own_ way which is probably why you're seeing people do their own way.
Also, you sort-of have to shift your mindset to embrace unix/shell as your IDE. But definitely reach out to other tools if it's not your cup of tea. Like many others have said, if you're trying to force it into something it's not then you're going to have a miserable time.
As for your e.g. it would be a simple autocommand to run black that's installed in your machine on buffer write event in your neo/vimscript.
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.
I've seen that breakdown before and have skimmed it but didn't really find an analytical breakdown of why style X is better/worse than style Y for person Z very useful. Tools preferences are to personal and varying. It really depends on how it meshes with your style and the only way to really test that is to try it out.
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.
The way I see it if Zed fails I just go back to VSCode and I’m no worse off than before. The nice thing about Zed is that it’s batteries included so it really isn’t hard at all to pick up. I did in maybe 15 minutes tops, seriously.
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.
Because files and directories make up the core organization and architecture of any project.
Obviously when I'm working with 1-5 files then Neovim is great, but it's awful when I'm working on a real project with dozens of directories and hundreds of files. I can't hold that much contextual information in my head to simply remember the correct file name (or function name) and hit some keyboard shortcuts to jump to it. I need to actually see it all together.
VS Code's project tree and tabs system works great for me to always understand where I am working, and I don't have to remember any keyboard shortcuts to navigate.
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.
I'm sorry that you read it this way, I think I could have written it differently. That being said, I don't agree that any of the things you listed are tools.
Moreover, reading what you wrote in your original comment from a more negative stance, I also think it's easy to read it as disdainful but I chose not to read it that way. I would appreciate it if you were more positive in your reading of what I write.
Tools in my mind are things like: a keyboard, your IDE/editor, your build system, your VCS, your userspace utilities (sed, awk, cat, ls, grep, etc), code formatters, code linters. I guess "tool" is probably not the best name for these categories given that I can understand why you would also call a library a tool but to bring in an analogy from woodworking, tools are things you use to make things from the materials (what would be libraries, frameworks, programming languages, etc).
So having this distinction in mind, I don't think it's necessarily incorrect to state that you are of the opinion that what I would categorise as "tools" are not worth learning and (I should add) modifying.
Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
In this sense, I don't think vim, neovim, or emacs are really appropriate for people who don't feel like time spent learning and writing or modifying (let's call them) peripheral tools is worthwhile. Whereas you feel constrained by the need to understand what to you might feel are "irrelevant details" (the need to know the API) about neovim, I feel constrained by what you might feel are "irrelevant details" (the need to adjust to a specific workflow which I might not be used to, the need to constrain myself to a specific set of plugins) about VScode.
That being said, I will say again, to claim that vim takes a lot of time to use and configure is simply wrong. But if you feel like having to learn an API to use an editor is a waste of time then it would explain why your experience might be like this. It's not possible to use vim quickly without having learned the API. Likewise, I feel like having to adjust to a specific way of editing as envisioned by a specific company and a specific plugin writer is a waste of my time and it would explain why my experience of VScode is that it takes a lot of time to configure and use whereas your experience is different. This doesn't mean that VScode takes a lot of time to use and configure, just that it's fundamentally not for me.
I hope the above clarifies things. I would be happy to agree on a different term than "tool" or a clearer way to distinguish between e.g. an IDE and a library or framework.
> Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
I use zsh, with customizations. I know git, and mercurial, and a few other VCS I've forgotten. I know my way around the Linux toolkit. I can configure a Python or frontend or Go environment with whatever linters and formatters and pre-commit and so on and so on. I have a fat repo of dotfiles. Hell, I use vim whenever I need to work on headless servers or the odd config file and the like. Works fine, in that use case.
Every time I learn or modify a tool, I look at whether there is a net benefit in learning it, whether it makes me more productive. Zsh shortcuts for example are tiny, but I get a nice little productivity boost that adds up to many hours over time.
I have spent the hours learning and configuring neovim, but run up against that point where that time spent is no longer yielding that benefit, compared to just using vscode and putting up with its issues.
So, I chose one tool over another. But it's a generalization to say I somehow don't think learning "tooling" is worthwhile.
Okay, so it seems you certainly fall into the category of people who generally find it worthwhile to learn and configure/modify tools. So I really don't understand how you came to the conclusion that neovim and vim are not worth the time.
Neovim takes a lot less time (weeks to months) to learn than something like git (months to years), while I know both very well, I find that I am more often interacting with my text editor than I am with git.
It seems to me that the tradeoff of using something like VSCode, unless it perfectly matches your particular workflow, is much more friction than dealing with git vs something else.
To that end, if you have given neovim a chance and learned it, then I struggle to see how you had problems with something like e.g. making :Black run automatically before the file is written.
Autocommands are a fundamental vim feature, one of the most important for vim related automation aside from rebinding. Something you will have encountered as soon as you search for "vim how to do X when Y." Figuring out that the PSF black vim plugin is a good option for a way to run black from inside vim is a matter of a 10 second google search. I can understand this being a potentially difficult problem if you really had no neovim configuration experience, but if you have learned neovim then this really is a single line addition to your on_attach which you would have already had to configure for the python language server of your choice.
And even then, the black documentation page explicitly shows how to use vimscript (which can be embedded in nvim lua syntax using vim.cmd, again, a basic neovim feature you would have encountered in any guide to configuring neovim) to achieve this in 4 lines.
I use neovim because it eliminates friction. Whenever I do something and find myself repeating an editing or reading adjacent task and making mistakes I think to myself: "how can I solve this once and for all?" I sit down, fix it in neovim and lua in 20-40 minutes. How do I justify the time investment? The 40 minutes (or hell, even if it took 2 hours it would still be worth it) investment once every couple of months to improve some aspect of my workflow keeps the friction down and the reduced friction more than makes up for the 40 minutes or 2 hours of lost time because I would lose much more time on frustration and lack of motivation.
This friction doesn't affect everyone as much as it does me, which is why I notice other people, less affected than me, don't find dealing with learning and configuring/modifying/writing tooling to be worthwhile. But again, what you wrote indicates to me that this kind of friction _does_ matter to you.
So my question is, how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
> how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
Because VSCode also is designed to reduce friction for a modest but (less) steep initial learning curve.
I have used vim a lot. I've also used VSCode a lot. It sounds like you haven't dived into VSCode in the same way you've dived into Vim. I'm trusting you that your Vim setup, after tweaking it to your liking and diving into it, is perfect for you. So I'm asking you to trust me (and the other commenter), and my VSCode setup, after tweaking it and diving into it, is perfect for me.
Using Vim emulation in VSCode, plus the richness of VSCode configurability, I have an environment I'm over the moon about, and it was less steep of a learning curve than Vim.
You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
>You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
I don't think you have read the discussion between me and the other commenter very thoroughly if you came to this conclusion.
I have repeatedly re-iterated my stance so I would rather not do it again but tools such as VS code are inherently inflexible (I have put a couple of weeks into trialling and configuring vscode) for good reasons and to tailor to a specific audience.
My argument is that for the other audience, tools such as Vim or Emacs (or in some extremes, writing your own editor or using something even more obscure) offer superior flexibility and offer the possibility of much reduced friction in exchange for more time needed to learn, configure and maitain and that this setup is worth it for that different target audience which the person I was talking to has indicated membership in.
For a more in depth overview of my stance, please don't skim read what I wrote and as a result jump to incorrect conclusions.
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.
It's not lock-in, it's feature differentiation. Other platforms are free to develop their alternatives of these plugins. There's nothing preventing the community to develop a fully OSS Liveshare or Remote extension (and they are!)
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.
So what? You use the plugins available on the platform you use, that's standard practice. Would you complain Sublime Text plugins are not available on VSCode? Or emacs plugins are not available on vim?
This is not lock-in, just a different feature set.
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.
> But the time invested to get there might not be worth the marginal productivity gains.
Most of the time invested has been invested by other people. My own nvim setup is just a curated list of other people suggestions. I haven't put a lot of research into it and I still find it easier/superior to use than some other editor/ide like vscode.
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.
Oh no, I need at the very least timeoutlen, visualbell and line number. I type that manually when I SSH if I must. Don't want to wait for ESC, no beeps at all and I wanna know where I am on the document.
And lots more is needed for decent Vim IMO. smartcase, set hidden, etc.
I actually think lack of line numbering is essential, because I quite frequently want to select blocks of code with the mouse and yank into the clipboard.
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.
The best part is that the developer(Folke) is very active with development and basically helping with all sorts of problems- the other day, I opened a pull request and it was resolved within hours..
Thank you Folke for the amazing work around neovim not limited to lazyvim.
Best protip I heard about (n)vim customization: use git branches when you want to switch between different configurations. Eg something like:
- vanilla/default
- minimal
- fancy
depending on what you want to deal with. If I go months between using all these plugins I forget what they do and what changed and it’s just noisy distractions that invariably lead me to open my init.lua file rather than what I actually had intended to work on
you can also use $NVIM_APPNAME if you want a more "full" switch between configurations. especially helpful for trying/switching between distributions (i use it for switching between my own config and lazyvim). basically, it modifies the paths where neovim looks for config and data files on startup:
Since the configuration is done in (dot)files you can version and track them with git. If you want several setups you could have them in branches and just ´git checkout X´ in your .vim or .config/nvim directory to change it and it would affect settings and plugins (as they're also just files).
I don't need it but I can see the use. I do have a dotfiles repository however it's very common in Linux and Mac, don't know about Windows. If I setup a new machine or spin up a VM I just have to clone that repository to have all my configurations for everything (even addons for Firefox and Chrome).
This article[1] is a good starting point if you want to try it out.
My attention span for text editor configuration decreased drastically after I finished school. For better or worse, being a professional means making the correct trade off when time, money, and productivity are at stake.
In the modern era, there are sufficiently many practical editors and IDE's with major economic investment behind making them highly functional out of the box. I simply cannot justify spending copious amounts of time configuring a text editor when there's sufficiently good and productive options out there.
As long as you know your tools and can achieve everything it doesn't matter which tool you choose.
I tend to mentor a lot of newbies and they often use VSCode, but since they are newbies they don't know how to do basic things like search (and replace) and I can't help them since I've only used vim. I have tried to give VSCode a go couple times to get more familiar with it, but I run into same issue as you - I simply can't justify in my head the time and effort to familiarize myself with the editor, figure out what settings to use and which addons to add.
Yeah, I don't get the "use Vim for everything" approach unless you're just doing it because you find the customization and configuration fun. I usually use VS Code for quick editing and full IDEs for real work with big projects.
Modal editing is awesome though. I use modified Vim keybinds for everything, even web browsing.
i love lazyvim, as someone who is productive with vim movements and keyboard macros, but has zero interest in learning every inch of the vim plugin ecosystem and writing the corresponding lua to configure it.
In fact, I've found it easier to learn the ecosystem of what is going on and feel more comfortable customising it, now that I have a solid base of customisation to build upon.
I just wish the documentation included more commentary on what each plugin does and why it is available - having to click through on each one is a bit annoying.
After using vim for more than a decade and slowly acquiring my personal config I switched to lazyvim. No regrets.
Also for simple chores like mass converting your config from vimscript to lua I'd really recommend bing chat, an LLM with the docs loaded works wonders on it, getting all my stuff ported and lazyvim set up took less than an hour IIRC
I recently switched to lunarvim, it took a few weeks to port my neovim config over to lunarvim, but now it's perfect. My neovim config was a port from my .vimrc and was outdated, switching to lunarvim has been great.
I've used the jetbrains sweet of IDEs, vscode, atom and many other text editors and IDEs over my career but always come back to vim or neovim. After the initial hurdle of learning vim, everything is easier. My hands and shoulders hurt less and I can navigate code much more quickly. It also helps me stay more focused and actually remember what tools I have available and enables easy tweaking if the tools are broken or not 100% what I need.
I do project planning and time tracking in neovim now and have my notes synced across all devices using obsidian
I use AstroVim in the same vein. Been using vim for a while but the hardest part of me actually making me want to keep using it is the formatting. Somehow, someway, the linting and formatting (whether its eslint vs prettier vs whatever else) always makes it a battle. VS Code does this to perfection. With vim, I have to battle and make small concessions on how formatting behaves.
I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.
I don’t mind slowdowns as long as they are synchronous and deterministic. But most IDEs and IDE-like plugins work asynchronously, so you have to wait and sync all the time. I think that this async-all approach gains technically but loses methodically, so I stick to basic editing. Ymmw.
What I would like to try is an asynchronous non-inplace helper. Like a side panel or a bg overlay to the right-ish that understands what you’re doing and suggests identifiers, reference snippets, full type info, etc. Like the whole page in a smaller font dedicated to what’s under the cursor. Then you could choose what to type into the code, or ignore it because I already know that. I don’t mind typing if it doesn’t require too much attention.
Another thing I’d like to try is mobile-style typing suggestions. First - semi-transparent popups above words in case there’s a typo or an obvious continuation, applied via M-CR. Second - 3-5 most obvious next tokens to insert without even starting to type. Like in
let start = new Date
let date|
Suggests [“=“]. When you choose it, it suggests [“new”, “start”, “Date”, “undefined”]. I bet one could type pages with this alone.
This might work nicely with any editing model, imo.
there is a somewhat hacky way to accept just a word, to my understanding, since copilot.vim allows you to access the raw text that's being suggested. try out the snippet in the linked comment:
It’s a similar job, but a different value. Copilot writes code you don’t know yet (supposedly), while this speeds up typing what you know you’d like to type. Both modes could be useful, I think.
I really haven't experienced this. There was one time i noticed vim slow down, and that was related to a relative line number bug specific to Mac, but that was fixed a while ago. I've used many of the ide type neovim premade configs, and i use my own which has a lot going on. None seem slow to me. Guess it has been a while since I've used a vanilla config. Full ide setups in neovim don't seem slow to me, especially compared to other full ides or vs code.
I also haven't experienced this much. I use the lazy loading functionality for vim-plug, along with async where I can. My neovim starts up in only a few milliseconds and avoids loading most plugins until I open specific file types or use a specific command.
One more thing. You can start neovim with different configs, so if you wanted to launch neovim with a super light config, it is possible to have both. Need to do some trickery with env vars, but it's not hard.
> I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.
Um… the word any is doing a lot of work in this sentence. I never had this problem on a 7 year-old iMac. I tried using VS Code on the same machine with just a few plugins on small projects and because it's an Electron app, I'd get frustrated and switch back to Neovim. VS Code has come a long way but it's no Neovim.
The beauty of new plugin managers like Lazy.nvim [1] is you could have 30 plugins configured but Lazy doesn't load all of them at once. In fact, it doesn't load any of ones you don't need and when they do load, it's asynchronous.
Plugins on Neovim run on separate threads from the editor itself, another reason we don't get those slowdowns you spoke of.
I can't comment on any implementation details, but at least with LunarVim (which I use for daily coding), a slowdown when interacting with LSP is very noticeable. Some others have attested to this on a GitHub issue.
I'm not doubting your experiences with the lack of a slowdown, but there is truth that others do experience it. That might be more of a problem with LunarVim itself rather than Vim, but how likely am I (as someone who would like to avoid what he calls "config hell") or other newcomers to avoid whatever pitfalls there are, if a distribution designed for ease of use by people who know better fall into them?
After re-reading my comment, I think it was somewhat unfair. LunarVim is still the best and most comfortable code editing solution for me and the performance hit isn't that bad.
The point I made about config hell might also be a bit out of place in this subthread since ease of use wasn't brought up explicitly in the comment chain I'm replying to (although distributions aiming for ease of use were mentioned).
What is this speed you speak of? I developed in vim for a decade, then eMacs for another decade, before finally moving to VS Code. I’ve never been as productive with vim/eMacs as I am with Code, or Visual Studio proper / XCode when I have cause to sue them.
Having used all three myself I bounced off VS Code hard because getting a usable Ruby setup with all the fixings like irb integration and sorbet ls was multiple days of frustration and still not working right compared to it just working out or the box with Doom Emacs. What’s the happy path that made VS Code work so well for you? I’m curious in case I did it wrong.
I think sorbet hasn't got the critical mass of devs using it so tooling is hit or miss. And I personally don't like it even though I'm well onboard with typescript.
What is irb integration? I tend to avoid that kind of thing and just do it in the terminal regardless of which editor I'm using.
May I ask what makes you more productive with vscode? Coming from decades of emacs I'm always wondering if I should try it. If anything because emacs is a huge time sink. You can get lost customizing it to your needs and forget that what you needed in the first place was get the work done.
It's basically all the benefits of an expertly configured and finely tuned emacs setup, except maintained by other open source developers so competently that your only time spent configuring your editor is clicking "Install Plugin" the first time you open a file written in the language/framework you use. Sensible defaults, batteries included.
The only downside is that as a web tech app it can have some noticeable latency. But on a beefy dev laptop or workstation the difference shouldn't be noticeable.
Maybe for your needs. When I worked as a game developer was amazing for visual debugging gigabytes of runtime data generated by a game engine with millions of lines of code. I could endlessly click through class hierarchies to see what interconnections arise at runtime, and setup all kinds of complicated breakpoint conditions. Obviously you can do all this with gdb or lldb as well, but in my experience it never approached the productivity boost of a graphical debugger.
Visual Studio is a bit shit outside of games, .net, or windows desktop software though.
This is not a direct response to your experience but a little off topic but lazyvim uses lazy.vim which is a modern plugin manager that lazy loads plugins/extensions, it also loads plugins on demand instead of loading them all together at startup from your config. It also can lazy-load plugins based on events, keymaps, filetypes etc
I have been using LazyVim as my daily text editor/IDE on my 2014 Macbook Air for about 6 months. It is the only IDE that runs smoothly and provides good Language Server Protocol (LSP) and plugin support.
After delving into the configuration rabbit hole, I started prioritizing 'getting things done,' and LazyVim proved to be a good choice.
1. It is easier to disable a plugin than to configure it.
2. It's Vim, so it is fully customizable. For instance, I use it to write LaTeX and compile it upon saving using my preferred LaTeX compiler, thanks to LSP.
3. It's Vim, so my mental muscle are grateful.
The only aspect I feel could be improved is the AI-assisted experience. The available plugins cannot compare to Copilot X Chat on VSCode, so most of the time, I find myself switching between the editor and a browser window with a ChatGPT-like chat to ask for boilerplate code. However, I'm confident that the Neovim community will rise to the challenge (zbirenbaum/copilot.lua and jackMort/ChatGPT.nvim are good starting points).
I have tried most of these out of the box neovim stuff and they do work for the most part but as soon as you want to tweak things it's not as easy. Besides that sometimes plug-ins can just break due to a bad merge and that can just break some core feature and now you are stuck either finding a fix or just go back and use VSCode
After curating my own vim customizations for years I switched to this and have been happily using it for about 6 months now. It was very easy to change any settings I didn’t like and/or port over stuff I couldn’t live without. It opens lighting fast too despite how fully featured it is. Highly recommend.
I switched to LazyVim earlier this year after giving up on Sublime Text, mostly because I want to be able to some motion-based editing and... LazyVim is nice. The builtins are rich enough to cover a lot of stuff you want to do without having to reopen another editor every 5 minutes and for my Scala daily work, it's good enough. The versatility of the configuration allows me to use all my languages with the same editor and a reasonable level of usability.
Also, I started using it with Wezterm and its multiplexing feature, ie though SSH and it's very nice to be at ease with your editor when it's also running in the Cloud.
I think it's hard to beat Pycharm when one is writing something new in python - even the community edition - but I always gravitate back to vim/nvim without thinking about it because my IDE is really the commandline.
It's about how big the project is and how much I know it. The smaller and more known it is, the more I cannot be bothered with the extreme inconvenience of having to steer a huge oil-tanker-like IDE to do what I want and accept that it doesn't exist on this machine or that were I want to do work remotely. It has all the searching and finding and probably SFTP stuff that could do things but that means I cannot use all my CLI muscle memory and ways which are far more generally useful.
In a project I'm not familiar with, Pycharm helps me autodiscover what's going on better and not waste as much time. It's also good for refactoring things with more certainty about whether I've broken it or not. A good set of unit tests are much better than an IDE but since that's not often available I'll take any advantage I can get.
I find that having flake8 setup so that it runs in vim is an enormous help on its own even though it doesn't begin to match what an IDE can do. For 2-4 screen scripts it gives a good balance of preventing annoyingly silly mistakes versus convenience.
That's just the plugin manager, lazyvim.
github.com/LazyVim/LazyVim or github.com/folke/dot/nvim might be more useful to see how to get the most out of this neovim 'distro'.
The mnemonic bindings I get from my config are an integral part of my workflow and super easy to add/update/change. But the primary reason for using Neovim is I don't have to leave the terminal. I switched entirely to the CLI a few years ago and I am more productive here.
If I wanted an IDE, I'd switch to the terminal version of Emacs.
I really wish I could just put a native neovim or vim text editor inside VSCode and call it a day. I absolutely love the lightning fast experience of editing with vim. When I know exactly what I want to do, I feel like I just ripped a line of spice and piloted a trade vehicle across Frank Herbert's universe.
But a lot of my job is exploring a code base and trying to figure out what the hell is going on, and I have to concede that setting up vim to do this kind of broad exploration isn't that great. Being able to click around at random and juggle tabs in the UI instead of storing buffers in my head is nice. I know vim can solve all of this, but I just found myself gravitating towards VSCode when I'm crunched for time and can't be bothered with vim.
Have you looked at the "VSCode Neovim" extension? It uses a native neovim editor in the background (instead of just emulating VIM like VSCodeVim), so the editing experience is the same as native vim.
I have been using Lua to customize Neovim for some time now and generally, the experience has been good. From time to time, I do encounter issues such as dependency incompatibilities butI always manage to find a solution. Recently, though, I experimented with LazyVim, and I must admit, it might replace my current setup. LazyVim fulfills all of my requirements, it works and looks great.
Using setups like this is a great way to get into neovim. Over time you'll start tweaking it and then realize you can just read the source code and implement your own version. That's what my journey over the past ~8 months has been, at least.
Here's to hoping we get a nice way to play with containers in neovim. I'm sorely missing devcontainers from vscode.
I've recently been exploring various neovim distributions and I feel like at this point neovims package ecosystem has gotten good enough that these distributions don't really seem to make my life much easier. Many times quite the opposite actually, as I often find myself fighting with them when I want fo change something.
The experience is still not as painless as effortless as VS Code, distribution or not, but it's definitely gotten a lot better than it used to be.
I dallied in this briefly, but couldn't get a good rust setup exactly how I liked, so went back to vscode pretty quick. Perhaps there's a good lazy+rust guide somewhere? I ran into the usual sorts of problems of some random plugin with instructions for how to install it in some other plugin manager for nvim, which means you have to learn two plugin managers and both their underlying concepts in order to port the config.
I was using neovim but nowdays I just fire up Sublime. neovim remains as a choice when I jump to other servers with SSH.
The thing is that when I'm (for example) trying to RE some protocol and have bytes-only view, I move things around quite a lot. And Sublime has a powerfull tool for this: multiple cursors. I can create as many cursors as I need and edit multuple instances/bytes at once.
m<key> creates a mark. If <key> is a capital letter, you can jump to it across files.
'<key> jumps to the line of the mark.
`<key> jumps to the line + column of the mark.
Although this doesn't let you _edit_ at the mark. There's multiple cursor plugins for that, I suppose... (I'll note that macros are useful in a lot of the same ways as multiple cursors)
Edit: You can also use :vimgrep or another command that populates the quickfix list, and use :cdo to execute a command on every entry in the quickfix list.
I dont understand the multiple cursors, is this better than search and replace? I am guessing you are replacing it to the same thing at every cursor, but I guess the value is then that the from could be different at the cursors?
It works perfectly together - one is not necessarily replacement for the other.
For more complicated things or bigger changes you would go with regex search & replace or sed/awk/grep but for small one-shot things it is way quicker to just click 5 times and do whatever you need to.
I use this all the time and you can copy a range of values with multiple cursors and then paste them into the same size range. It's nice for hashes or modifying static lists that all need the same changes, but are annoying to regex for
NvChad[1]is the first vim/neovim config that worked for me for coding. What I also like in NvChad is that all my custom configs can be placed under a `custom` directory, leaving the provided config as is and easing upgrades of NvChad itself. This doesn't seem to be the case with LazyVim.
IMHO the best thing about vim are movements and modal editing. Once you have the muscle memory for that it's really hard to go back. However, almost every major editor / IDE has a vim mode these days which for me is the best of both worlds. I don't need to mess with configurations for days but I still get (almost) all the power of the vim editing model.
For those s who want a nvim experience without the hassle of a config file as long as my arm : I warmly recommend you to try helix.
Exploratory terminal based interface (much like zellij if you use that) , terminal based, fast as fk, minimal config required(just having the LSP in your path is enough) and the documentation is mostly complete.
I switched from vim to jetbrains IDEs (with vim keybindings) nearly a decade ago because of visual debuggers being incredibly useful. Is there one of these for vim (or neovim) now that works well with popular languages?
I know it sounds like a pain, but I really am a big advocate for learning how to customize vim (or emacs) yourself. These are great places to start, but the power of terminal editors is that they cater to you at a very personal level. The problem with "IDEs" isn't that they are bulky, it is that they railroad you into doing something a very specific way. Terminal emulators put the custom configuration in your face because that's the point. You should edit color schemes if you don't like them. Select only tools you actually want or will use. Learn native commands (because so many plugins do things that are native and even taught in vimtutor). Turn it into a game if you want. Whatever, it is personalized __for you__, and that's the point. Start here, but make sure to move on and make the editor __yours__
some of us don't have time to play games? i mean definitely used to when i was a kid but now i have lots of deadlines and little enough time to play games with my human friends let alone with my editor.
> make the editor __yours__
a good tool is useful immediately and has the potential to be personalized. i mean imagine how little carpentry would ever get done if every hammer, drill, and tablesaw needed to be personalized.
the reality is that software tools, like software itself, are much more complex than carpentry tools (and carpentry), and thus maybe can't be immediately useful in the same way. but that's why ux engineering exists for software tools and not for hammers. so i'm happy to leave it to the professionals to help me become productive as fast as possible (even if not immediately) when using my tools.
At least for me, Vim is immediately useful, and I rarely do much personalization. I agree that personalization is not an adequate measure of an editor. I don't agree that the problem with IDEs has anything to do with personalization.
At least for me, it boils down to wanting an editor for text, rather than some specific programming language or environment. Traditional IDEs have been very "project" focused which isn't useful if you're editing an email or writing a poem or munging some logs.
> imagine how little carpentry would ever get done if every hammer, drill, and tablesaw needed to be personalized.
This is somewhat ironic to me not because of personalization, but because in traditional carpentry (i.e. a master carpenter) it is pretty common to make your own tools. That's kind of the beauty of woodworking and especially hand tools: your tools usually have a lot of wood parts. If they don't, they usually end up with a lot of wood parts anyways.
master carpenters produce artisanal works. those works are valued for the craftsmanship itself rather than the utility. so it makes perfect sense that master carpenters would be incentivized to put thought and care into their tools. me? i'm just a tradesman/laborer. okay not really but there's still no such thing as "artisanal software", at least for sure where the code itself has intrinsic value (instead of it generating value). anyway if i ever hit it big, make it to master software developer, and have enough freedom/time that i can afford to spend it on things like personalization, maybe then i will.
> This is somewhat ironic to me
double irony: i'm a compiler engineer and i chose to work in compilers in order to be able to have more control over what my progams did. but i still don't have time (or care) to personalize my IDE (or vim).
Ever try to cut wood with a dull blade? I really don't recommend it. Even a novice carpenter will benefit from taking care of his tools. Admittedly it's more important for carpenters because blunt tools can get you injured. Excepting RSI issues, the worst that will happen with a suboptimal text editor is very marginal inefficiency (typing probably isn't the bottleneck anyway.)
i do too - all i know is :bn, :bp, b, e, ciw, v and shift+v (and :wq) and it's all i've known for over 10 years. i use the arrow keys on the keyboard too! fingers crossed it'll last me the rest of my career too.
but i mostly use clion/pycharm and there the defaults are reasonable and the ux of shift+shift is absolutely unbeatable.
I'll give you an easy useful command: smart completion. In insert mode use <C-x> then <C-p> for a word or <C-l> for a line, or <C-f> for a directory path. You can repeat them because it is contextual. See `:h ins-completion`.
Also, get away from the arrow keys. And use <C-[> for escape. But it is also okay if you don't like vim. If you want to learn, there's a community out there and we're happy to help, but if you don't then that's okay too. You just do you and that's all cool :)
So don't. See the next part you quoted from me. But also, IIRC you're in grad school (too), right? Little time is kinda part of the deal. It sucks, I know.
But like others are saying, vim is useful right away. But I do disagree immensely with your premise. A good tool has no requirements to be immediately useful. There's lots of carpentry tools that require training to use, let alone use well. You can be good at vim or emacs in 30 minutes after using vim tutor, but like all specialty tools, it takes time. And that time really comes from using it, not from sitting down and reading about it. The same way you learn how to use a jigsaw, experience. Every carpenter has their custom set of jigs and way of organizing. Same is true for any engineer, or realistically any profession. Whatever it is that makes __you__ most effective, that's what you should do. Maybe that isn't vim at all and that's okay. I never even implied you needed vim, I'm just saying you should customize your environment. And like I implied, start with something someone else has put together, but learn to customize it to you. That'll take time and that's okay. There's no difference in using one of these than just using someone else's dotfiles. But making your own dotfiles is going to make you better in the long run because your tools will match you.
Be honest how productive are you? You probably waste more time during your workday than you do work. Not every day, you might even have very productive weeks, but think over a year how many hours you "waste" on taking breaks to read HackerNews or Reddit or make a Tweet or whatever.
You could spend that time fixing issues with your editor and that would lead to improved workflow when you get back to work.
And in my mind you should use your work time to improve yourself and your tools. From the day I started I decide that I wanted to be the best at what I do and I can't get there if I just do the work. So every day from the day I started working I've taken 30-60 minutes per day from my actual working time to improve. Be it learning something new or configuring my tools (editor, terminal, operating system, browser, whatever). And no employer has complained about my output nor should they since they are getting better output for the same investment.
> Be honest how productive are you? You probably waste more time during your workday than you do work. Not every day, you might even have very productive weeks, but think over a year how many hours you "waste
Lol. Except for the odd day a month, I have worked every single day for the last 2 years (July 15 2021, when I started an internship at FB). I'm in a PhD program and I have a 20-30 hour/week job during the academic year and full-time internships during summers.
Few last times I tried VSCode it wasn’t immediately useful. I believe that you’re speaking from your own familiarity with it. How big is your settings.json?
A hammer is more like a small linux command line utility like tr. An editor is more like a table saw. A table saw is immediately useful, but carpenters also spend tons of time building sleds and jigs and fences and table extensions etc for them.
I use lazyvim and you're still going to be configuring a _lot_ of stuff by hand with it. It's really just a framework for configuring neovim with an opinionated file structure. Compared to other neovim plugin 'distributions' this one is pretty hands off as far as out of the box config--it really just has the bare minimum to get popular language LSPs up, and a lot of missing LSP features that neovim hasn't implemented yet (like autocompletions). For everything else, like defining your own little shortcuts and commands, it's wide open and up to you to figure out just like regular neovim.
Basically this distro is useful if you want to play with neovim plugins but don't want to spend days surveying the landscape to see what are the most popular and usable plugins... lazyvim is doing that for you. As far as using neovim goes this doesn't do much and it's still up to you to do the work to learn and configure it.
Probably what I like about my NeoVim setup (an organic, home-grown completely from scratch mess of .vim and .lua files) the most is universal containerized language server for any project.
It gets me go to definition, peek definition, etc. in TypeScript, Python and probably anything else LSP-compatible without polluting my main machine with any of those development environments and only requires Docker.
The editor detects a special INI file in project directory and launches a Docker container that runs a language server. The INI file can specify a common Dockerfile (works for zero-install Yarn where it mounts repository root as read-only volume and just works(tm)) or a project-specific Dockerfile that does some system setup (useful in case of complex Python/Django backends, for example).
I’d be curious to try a configuration like LazyVim if it supported something like that out of the box, but last time I checked most of these were written in mind with LSP running directly on your host.
> but I really am a big advocate for learning how to customize vim (or emacs) yourself
I got caught into this and, for me, it was a waste of a month. I found that configuring your editor serves as a great way to procrastinate doing "real work". There's always that one last thing you wanna get right
Oh, I can definitely agree that it is easy to get caught in it. I think we've all done it. I'm not sure if it is wasteful or not because there are at least worse ways to procrastinate. I'm pretty sure if you weren't procrastinating configuring your dotfiles you'd be procrastinating by doing something else haha
I like a good starting point. All these things let you tweak them to your heart's content. AstroVim plus 20 lines of customization is my ideal Rust IDE. Really takes away my motivation to burn a couple weekends doing it all myself.
I'm still using this, but now I'm contemplating on switching to my system's package manager instead. It was pretty useful when I was on Windows, but now I'm just feeling less and less of its benefits. The scope is also intentionally limited, so you need to eventually install some tools manually anyways (e.g. ccls). But I can see the benefits if you work on both Windows and Linux.
the original vim has always been my daily editor, yes I did spend time learning it along the way and it worth every minute I invested, it does everything vscode or other IDE can do for me. typing while moving mouse and clicking here and there on an IDE is not as productive comparing focusing on keyboard typing, to say the least.
the beauty is that I can use it on any servers too.
LSP integration gives access to completion, linter or compiler warnings and errors, formatting. It adds file browser views. And it preconfigures a nice way to resume an editing session (preserve open files).
These don't usually take off because people who use vim and emacs are people who insist on customizability and aren't into all the bloat that comes with IDEs. People who want IDEs aren't interested in an editor that lives in the terminal. There is a very limited market for something like this.
I disagree, I think these are helping people see neovim as a an alternative, drop-in replacement for VSCode or other editors with the added benefit of being vim.
I also think once people start using these regularly, they tend to learn more about neovim and vim universe how it can be customised to their needs, this acts as a starting point for many without the need to spend days/weeks setting it up to what they are used to.
And for most it becomes easy to just rely on the maintainers to add new additions via plugins and/or update as and when required without the need to update/break/debug on their own.
Using LazyVim got me over the hump to switch to neovim from vscode. My previous attempts failed when it took too long to get an IDE-compatible setup. I suppose I am the type of person that wants and IDE/editor that lives in the terminal!
I did the same thing and it was also a great learning aid. Now I run my own my own set of plugins but this got me past that initial learning curve. I think it says something that it finally happened to me after 4 decades of software development.
There’s a lot of people who want to make the jump but haven’t yet because the configuration seems complicated/unapproachable and they’ll lose too much productivity trying to figure it out or using it with a blank slate. These are great in such cases, I think.
I use IntelliJ Idea for work, and the most bloated NeoVim setup in the world doesn't even compare. I type "vim ." in a project directory and NeoVim, with a billion plugins, has come up by the time my finger is a cm off the enter key.
There's plenty of people inbetween the extremes. I don't want the bloat but I'm also busy (tired) and don't want to spend a weekend getting my dev env setup. These pre-made environments are great to dip my toes in the water; I get the speed of vim with some of the "batteries included" ergonomics of actual IDEs.
The draw of these imo is as a framework for building my own config. Something as relatively niche as the lua config for NeoVim is hard enough to find good code examples that nicely flushed out configs like this are a goldmine.
Strange generalization. There are many people who want exactly something like this. LazyVim has a very active community on GitHub and YouTube and many people use it daily. The same goes for other distros like LunarVim.
I have been using nvim for 3 years as an in-terminal IDE while maintaining my own config and have switched to LazyVim.
A bit off-topic, but I wonder how much Copilot/GPT cuts into the market share of editors like vim and emacs. I used emacs for the past few years, but I recently switched (back) to vscode because the Copilot integration is really good. There are a lot GPT integraton packages for other editors, but they don't come close to the deeper integration that vscode has. And of course, vscode will probably get priority treatment from Microsoft.
At this point, this is (somewhat unfortunately, I really like vim and emacs) a big selling point for vscode.
Regular autocompletion also feels magical and unpredictable.
This is because I need a tighter visual feedback loop to confirm that the IDE has chosen the right identifiers and inserted extra parentheses and such, and so I couldn't get a few keystrokes ahead of what I see. It's nice for debugging where I only need to replace a few things in a few lines, and I suppose it might be nice if I am trying a new language and wasn't typing very fast anyways. It's not something I use regularly for development.
> A bit off-topic, but I wonder how much Copilot/GPT cuts into the market share of editors like vim and emacs.
So you think that the two editors that have been around for nearly 100 years combined and are extremely customizable and have survived every coding fad, language and technology trend, is in danger from AI features?
Short answer: no.
Both Emacs and Neovim has first class support/implementations of Co-Pilot and GPT plugins.
I've been using a text editor and a repl forever now and don't see myself adding to the workflow. I don't optimize things that are so far off the critical path of my productivity.
I use copilot, but I it’s not a super game changer in my opinion. I can live without it. I often turn it off when I’m using SQL or something when it hinders more than helps. It’s honestly best when I’m writing JavaScript because I’m not very good with the language. But when I’m writing a language like python which I’ve been using for a long time it kind of gets in the way.
copilot works wonderfully inside NeoVim; I use it daily. You are right that some of the more advanced integrations (Chat, direct analysis/explanation) aren't ported though. I use shellgpt in tmux for a (not as good but almost) experience.
I gave it a try the other day using copilot.lua, and it made the whole editor unusably slow. It somehow caused syntax highlighting to "lag" for tens of seconds every time I made any sort of edit.
Maybe I need to be using the official plugin, and maybe I need to disable LSP based syntax highlighting, but that makes me wonder what it's doing.
What languages and LSPs are you using? I've never experienced this with Python (pyright), Go (gopls) or Rust (rust-analyzer). I'm using tree-sitter for syntax highlighting. The only special thing is that I'm using lazy.nvim (the plugin manager) to load copilot.lua on the InsertEnter event.
I am using typescript with typescript-language-server. I'll give the lazy stuff a try, but I am not sure why this would make the editor more responsive outside of the initial load.
Does it really work wonderfully for you? I am often times shocked by how it just can't guess the most obvious completions. Then I jump into VSCode to sanity check, and it works fine there.
Copilot really does work wonderfully for me, as expected with any AI code completion. I run copilot and coc.vim simultaneously, to be noted. So when I just want to autocomplete a word, it'll be coc.vim, but when I want a whole line/method/etc built I'll let copilot be my copilot.
It's not perfect, but it's still generally valuable. I do still bounce between VSCode/NeoVim (depending how often my current task will need a stable debugger vs how often i need better neovim code search), so I see how the VSCode implementation is better; but I still prefer to live in neovim as much as possible.
It's the only thing that tempts me away from Vim. Vim does have an official copilot plugin but it seems gimped compared to VSCode. I wonder if that's intentional.
I don't know what kind of GPT you want in your editor. A colleague of mine attached the llama model to his vim, but that doesn't seem too useful to me.
But it has to use your code for inferencing, doesn't it? So it is sending it to someone.
I see this being a blocker at a lot of places. I know in my workplace the infosec people are apoplectic about it and we supposedly have a 'partnership' with OpenAI.
What was the name of the original Vim magic-auto-default setup project? I wish I could remember it! There used to be so many Vim questions on Stackoverflow from people who installed Vim ________ (?) and had no idea what it did. The advice was always: "Stop using that, and learn Vim." This project smells like that.
There are two types of Vim users:
1. "Stop trying to make Vim and IDE with all your fancy plugins, learn Vim!"
2. "Vim is so much more than a text editor, of course you can use it as an IDE."
These two Vim users are usually the same person.
You have to learn Vim's terrible, verbose, antiquated commands in depth in order to justify using Vim. If you don't use q: (q colon) and q/ (q forward slash) in Vim, for example, you probably don't know Vim well enough to justify the efficiency loss you have compared to you using a modern IDE with multiple cursors.
Aside: It blows my mind that there are still plugin managers being invented for Vim. That's a bad sign for an editor. This shouldn't exist in userland.
>You have to learn Vim's terrible, verbose, antiquated commands in depth in order to justify using Vim. If you don't use q: (q colon) and q/ (q forward slash) in Vim, for example, you probably don't know Vim well enough to justify the efficiency loss you have compared to you using a modern IDE with multiple cursors.
How is scrolling through your past commands and searches anything like having multiple cursors?
If I want to use the same command I just type `:` followed by the start of the command and press up and it automatically fills in the rest of that command and I can even go back and forward in that history. Same with searching.
Also how is any of this "efficiency loss". Whenever someone talks about efficiency loss or performance in their IDE it is usually some very niche thing that they have gotten good at, but often the house of cards crumbles when they try to do anything else.
> Aside: It blows my mind that there are still plugin managers being invented for Vim. That's a bad sign for an editor. This shouldn't exist in userland.
I'm not sure what you're talking about… the fact that plugin managers continue to be developed for Vim and Neovim tells us there are new use cases today that didn't exist 20 years ago. Neovim isn't your undergraduate Vi/Vim from back in the day.
What's amazing is the plugin managers continue to improve, especially for Neovim.
Lazy.vim [1] is amazingly good.
Refactoring eliminated 30% of Vim's legacy code and the choice of Lua for the scripting language has unleashed a stunning amount of creativity in Neovim/Vim community.
I would argue vim's cryptic commands like q/, gg, ciw, etc. are anything but verbose. Especially compared to gui editors where similar actions are achieved by clicking through menus.
Your example of commands is a bit odd; I've used many editors without knowing how to access search/command history without that being a detriment to my usability of the editor. If your argument is that one needs a high degree of understanding of vim for it to be useful (more so than IDEs), then I have to disagree. Vim motions alone skyrocket productivity. Anything you can do with multiple cursors, can be done with substitution, repeat motions, block select, macros, etc. Then there are always plugins, should the built in features not satisfy.
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