LazyVim
lazyvim.org
lazyvim.org
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 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.
It’s now in a stable enough state that I haven’t had any issues.
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.
Just because you have a bunch of custom quirks doesn't mean that I do.
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.
I did find this comparison not too long ago https://medium.com/@adaml.poniatowski/exploring-the-top-neov...
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.
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.
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.
It worked out of the box, the method of simply overriding a few settings https://www.lazyvim.org/configuration/general was a lot easier to understand.
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'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?
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.
For vim, this is exactly the same. I started with Python so my vim became the best Python IDE (for me) and that's all. What I said to junior dev is "Here my vim conf, you are allowed to copy/paste only what you understand". Then I did some Typescript and added a configuration that works for me. Thus, some pain point came from my old config in python, I found new good plugins and added them. And so on with rust and ruby. Everything is commited so now, on a new machine, it takes me the time to copy/paste my config and write :PlugInstall.
Everytime I test vscode, it does not do what I want and when I look into it, I can't configure it correctly. Vim has always my back.
I do miss vim editing constantly, and I could never feel vim emulations as a native thing, but vscode is really awesome, particularly its keyboard centric design and sync.
Once vim has this "works everywhere and my setup installs in 1 command" I will get back to it.
Just copy/clone the dotfiles, launch neovim and run a command to update the plugins and everything is good to go.
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.
Not as customizable. But I pretty much would configure vim to do what helix does out of the box anyway.
I will keep using Sublime Text. No need to suffer needlessly.
The language server protocol works perfectly fine with ST4, and it is better than ever. Whatever our small community needs, it's there.
The fact it is not a "full IDE" is also one of the reasons I like it.
It uses the standard bindings I learned with Windows decades ago, and builds on that.
Vim forces me to change it all to the vim-like model.
It's about having to learn a new set of key bindings just for that program alone.
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.
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.
Can you expand on this? What specifically does not work for you on vscode?
However, I can tell you my main pain point in using VS code vs vim: project switching. Many times I have to go quickly to another project and close it. When I code in vim this this :
ctrl+Z (go back to term) workon project_2 vim ctrl+P (select the file I need to see or quickly edit or show to a colleage to explain) :q! (let's say I didn't edit anything) fg (Go back to my main task)
Did not know how to be that fast to open/close project with a _real_ IDE.
To oppose this, there is one feature I envy of vs code: code in docker through ssh seamlessly. Unfortunately this is not even available in vscodium.
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.
[1] https://marketplace.visualstudio.com/items?itemName=sadesyll...
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...
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.
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.
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.
`autocmd BufWritePost *.py !black %`
"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."
> 'left' actually means right
But yeah I agree with the sentiment of parent OP
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?
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.
[1]: https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
EDIT: removed comment about cursor behavior of ctrl-c, which comes from my vimrc config ^^ Turns out I learned that long ago, but never used it :-D
More alternatives: https://vim.fandom.com/wiki/Avoid_the_escape_key
What if you need to type `jj`? Not uncommon to do so while writing math or physics papers. a_{jj}
Happy vscode user these days. If I find myself fiddling with an editor it's a huge red flag to me that I hate what I'm working on.
What if you need to type "fd" in insert mode? Like fd0, fd1, etc. Isn't that going to be a pain? Do you never have to type "fd"?
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.
JJ Abrams disagrees, though.
For that use case, it's absolutely great. No complaints.
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.
- https://news.ycombinator.com/item?id=12886067 - https://news.ycombinator.com/item?id=23902124
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.
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.
Chainsaw is very good at doing chainsaw things.
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 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.
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.
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.
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.
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).
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.
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.
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 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).
[1] https://marketplace.visualstudio.com/search?term=python&targ... [2] https://github.com/williamboman/mason.nvim [3] https://github.com/VonHeikemen/lsp-zero.nvim
Then just use the chainsaw... and accept that the knife may be absolutely perfect for the tasks of somebody else.
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.
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.
And yes, it was also a reference to the Gimli glider.
After an unfortunate bout of Java development, I was flung into the arms of Intellij, steadily won over by the indexing and the reliability of the refactoring tools. The Vim plugin was good enough and defining some chords for editor shortcuts resulted in a kind of fucked up fat vim emacs mode that was quite productive.
I, too, got fed up of spending inordinate amounts of debugging vimscript and incompatibilities to end up with something that was slower or buggier than an IDE in certain crucial ways or with highly debugging resistant niggles.
But I'm also far from in love with Intellij these days. It's slow. Prone to index corruption with lots annoyances I can't easily fix myself. I may churn to vscode. But I'm definitely in the gravity well of Intellij.
However perhaps this is worth a look. I have historically had a fairly high tolerance to plowing hours I'm never getting back into fiddling with tools. Just less than I used to. More nixos gnome, alacritty than gentoo, xmonad, urxvt...
[0]: https://github.com/dense-analysis/ale [1] https://github.com/CGamesPlay/dotfiles/blob/master/files/.co...
OK, how do I set up efm-langserver with Neovim? Good luck! You could probably use a plugin, or maybe not. You'll need a way to install LSP servers. nvm-lsp-installer? Nope,that's also deprecated, use Mason. OK, MasonInstall Black. Wait, it's not formatting anything. Oh, you might need nvim-treesitter. Um...ok, but that's installed already. Ah, you just haven't configured it correctly...here is my setup (pastes 300 lines of Lua or vimscript with zero context as to where you are supposed to load it)....Why are you using efm-langserver? Formatter.nvim is all you need! What? That's old hat! You should be using neoformat!
If you mention Ale or coc.nvim...they stare at you as if you have just stepped out of a time machine from the 19th century.
I’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.
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 :)
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.
[1] which is still maintained by the way.
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..
Install https://github.com/folke/which-key.nvim and you will always have a popup that will tell you what keys to use next.
So yeah, highly recommended! Of course, I use the evil mode for Vim keybindings.
To get a feel for its development status I recommend reading their news post for their 23.03 release.. https://helix-editor.com/news/release-23-03-highlights/
I wish they'd add a Vi mode. ;)
[1] https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
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.
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.
Related: Imagine having to remember the full scp / rsync command to sync source file(s) between your local machine and server, but it's just a drag and drop on VSCode.
I've just come around to accept that we've been blessed with great hardware over the years, and it's a waste if those extra CPU / GPU cycles aren't translated to significant dev productivity improvements. I'd take slower (~ ms) editor paint times over saving hours messing with vim configurations.
What's hard about this?
rsync -a dir/ server:dir/
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.
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.
If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys.
If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.
An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing).
If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, finding the needed plugins for your languages, getting familiar with each plugins commands, resolve any conflicts between them, then you need file pickers, debuggers, task launchers, snippets, split screens, multi tabs, etc... Even then, you only made things work once... Good luck figuring that out in one hour...
Then you'll need to keep the config working, practice and memorize the commands, movements, and maybe customize your workflow.
Configuring vim to replace your IDE may be worth it, but "set it up in one hour" is, in my experience, extremely unrealistic.
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.
The horror!
I am talking purely about going from a vim without IDE-like tooling to one including it. That can be done in an hour.
Unless you find the correct plugin :-)
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.
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..)"
which i translated to "cluttered ui" and "not responsive".
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)
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.
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.
So, no, an IDE is not a better choice for everyone who want's "IDE like features". It is for some, but not everyone.
Because vim ships with any *nix machine and provides a consistent experience no matter where you use it.
Vim is the DE part and people add plugins or whatever to enrich the text editing experience with LSPs or other language aware plugins, and the I in IDE is in the form of the integration with the tooling already available on the host.
This[0] might shed some better light on the "why"
(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 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.
I don't think vim is meant to be an IDE. If you want an IDE, go get an IDE. If you want a text editor, vim works well. But vscode is unwieldy as a text editor, and vim is painful to contort into an IDE.
Obviously people have made things for VIM to be IDE like, some are cool to me, but completion-integrations-lang-servers always seemed so anti-vim to me. Make an HTTP request every key stroke to get suggestions? The. Latency.
The issue isn't with the fact people try to use it that way, it's that those who use vim are adamant it's the best option for doing so and berate the Other until they try.
Edit: I did use Helix for awhile (long enough to still have muscle memory for their editing model) but it’s just not there yet and eventually moved on to Zed.
Even if they succeed commercially, chances are some day Microsoft just buys the whole thing and shuts development down a week later. No thanks.
By the way, if you need an IDE for Python then you're missing the point of Python.
But right now, today, at work, I have a large legacy Django project to maintain, and it's kind of nice having little things like auto code formatting and linting to help me as I go and prevent me from making dumb mistakes and saving me a ton of time so I can focus on the problem at hand, not making the code look nice for review and I can hop between buffers to fix up the tests as I change the code.
I can certainly just run black/isort/ruff what have you manually, or with pre-commit, sure. But it's more productive to be able to see changes as I work.
Sure maybe I shouldn't be using Python, and maybe the original developers should have written it in Rust or whatever. Fine. But that's not what I'm being paid for.
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.
One can never be satisfied with the results. "There is no endgame", right?
1-2 hours is more than enough to get to work with autocompletion, syntax, filesystem explorer and a few more plugins for your convenience.
>coming from another IDE and trying to replicate something
This. Some people try to replicate IDEA or something like that. Obviously you can spend weeks trying to do this
Hell, configuring https://github.com/mfussenegger/nvim-dap + https://github.com/rcarriga/nvim-dap-ui can take a week alone I guess.
This was something which took some time for me to notice. There are some plugins which have the best documentations I have ever seen, but you need to read it from the Vim.
Example of coc.nvim: https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt and https://github.com/neoclide/coc.nvim/blob/master/doc/coc-con... and https://github.com/neoclide/coc.nvim/blob/master/doc/coc-api...
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
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.
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.
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.
It will never be a ctrl+p install away from feature X system though. You do have to put some effort in.
I started with this config. This made it a lot easier to start.
I'm looking forward to some kind of open source VS Code killer with vim editing and native platform builds.
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.
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Something like:
vim.api.nvim_create_autocmd('BufWritePre', { buffer = buffer, command = 'Black' })
I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.
That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this job otherwise.
However, my time is limited. I have to be selective in what I spend time learning. Much of that choice is determined by my employer, project and other requirements. Free time left over for learning other things is even more limited.
Learning another language and API and plugin ecosystem just so I can configure my editor? Maybe for some people, that's time well spent, but personally - having spent a fair bit of time with neovim to give it a fair shake - I realized that what I don't need is a perfect artisinal text editor, but a good-enough IDE that lets me do the things I'm either actually interested in, or paid to do.
Vim as a simple text editor? Perfect, use it every day when dropping into a headless server to edit a config file or two. For an IDE? I don't love vscode, but for what I need, it's fine.
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.
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.
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.
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.
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.
> That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
> I realized what I… [is] a good-enough IDE that lets me do the things I’m actually interested in…
By your own admission, you’re not interested in learning tooling.
No one reasonably claims that vim is easy. If you don’t want to learn it, then don’t, but don’t take offense when someone points this out.
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.
If you want Black to format your Python files on save, write an autocommand. That's what they're there for. If you need help to do that, ask for it.
Or if you don't want to take the trouble to learn how to use (neo)vim, then don't use it; that decision is fine too.
The real question would be:
Why does the 50 year old editor with supposedly a huge community and tons of editors not have support for a popular formatter for probably the most popular programming language on the planet, and instead everyone has to write their own (probably buggy) variation of that integration?
If the tool doesn't suit you, build your own or find another.
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:
https://github.com/psf/black/blob/main/plugin/black.vim
And then the autocmd would be
autocmd BufWritePost *.py silent! Black
This stuff is documented here: https://black.readthedocs.io/en/stable/integrations/editors....
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 :)
E.g. for me, "vim" is more like an input scheme that works across editors, less a particular product.
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.
You’re not though, there’s no lock-in.
This is not lock-in, just a different feature set.
I've personally been test driving JetBrains Fleet and have to say that it's pretty okay for most of my lightweight dev needs: https://www.jetbrains.com/fleet/
It's still a bit early for it and it doesn't have the same ecosystem that VSC has, but it'll probably be even better in 1-5 years and is decent already.
For most of the more heavy work I just use JetBrains IDEs, but that's very clearly a no go for the less capable devices like my netbook.
For even lighter options, on Windows there is Notepad++, which has been okay although not an IDE.
There's also CudaText, which feels quirky but has decent language support: https://cudatext.github.io/
Maybe even something like Geany is worth a look, depending on your needs: https://www.geany.org/
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?
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.
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.)
Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the problem of being clunky on older laptops, but it is an amazing experience to use. I get the best of both worlds, I get really good vim emulation so I don't have to relearn editor shortcuts, I get the benefits of a modern full fledged IDE with many useful features that work out of the box with basically 0 configuration (debugger, git, tasks, etc.)
I do have a personal all-products license as well, but I hesitate to go “all in” and be dependent on them.
But it is ok to just use a lot of editors for different things. VS Code is ‘good enough’ a lot times. I like writing notes in emacs org-mode. NeoVim on the command line. Sometimes I use Helix, I think it hits a sweet spot between snappiness and minimal configuration.
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.
Vim doesn’t have to be the tool you use when there are others. If it was the only tool, I’d agree that people should know it better. Thankfully it’s not the only one.
To honor the many-years of vim, I relearned a new vim feature now: using :g to run a macro like this: https://stackoverflow.com/a/5292858
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.
All in all it looks like we had a wildly different experience. I suspect the real issue is that I like to work with vim a million times than I did with vscode. You might me biased the other way. I feel better on the command line and it's amazing how much people have figured out already to make things run well and look nice.
Kickstart nvim: https://github.com/nvim-lua/kickstart.nvim
Furthermore if you want to customize a vsc extension to do something unique for your set up you have a whole new set of issues like finding the settings, documentation etc.
Now if you can get over all of that it’s still a bulky, slow and cluttered IDE that is constantly sending telemetry data and other nonsense around the web
While I haven’t tried LazyVim I would strongly recommend LunarVim to anyone new to the vim ecosystem. It installs fast, needs minimal set up and packages can be installed with a single line in the config or through packer. Most things work out if the box. But if they don’t vim is so mature you can just ask chatGPT.
Seems like ease of use is also the aim of lazyvim so I would not discourage anyone from trying this flavour as well.
In the end it is whatever works for you.
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.
Vim has some core concepts that are unique and (for those of us who adopt them) very sticky.
My entire career has been spent trying out IDEs every few years in hope of switching, dating back to Eclipse. I always try their vim modes too.
But the reality is that the core editing experience in vim is so central to how I work that I can never manage it.
I like features, and I have no love for arcane configuration of plugins. Yet to this day I've found nothing better for me than vim.
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.
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.
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 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)
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.
Very easy to setup. Moreover, when I'm on a different computer and open (vanilla) vim without any configurations. I know that everything is more or less the same as my default vim environment. I think it's not that hard to learn developing in the default vim environment, with some minor tweaks.
Also related, How to Do 90% of What Plugins Do (With Just Vim): https://www.youtube.com/watch?v=XA2WjJbmmoM
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 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.
set ts=4
set sw=4
set softtabstop=4
set expandtab
set hlsearch
set incsearch
set wildmode=longest,list
Basically: tabs are 4 spaces, searching works better, and tab completion works like bash.
And lots more is needed for decent Vim IMO. smartcase, set hidden, etc.
These are the three lines I always use on any vim install.
let loaded_matchparen = 1
syntax off
map ; :
The last line is really handy for not having to hold down shift so much.
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 was absolutely thrilled to find that VSCode’s vim emulation included vim-surround! I guess someone out there has the same problem I do.
So much programming is editing various text surrounds: parents, braces, brackets, quotes of various flavors.
I also really like having semantic completions. I get by with YouCompleteMe, but it’s a little jank in my build system.
I 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.
I'm not going to sacrifice my 95% use case for the 5% of time (probably even less) that I am in a situation where I don't have access to my own config. If I am just editing a few lines in a config file on a server, it doesn't really matter that I don't have my config.
With that being said, not everyone wants or needs plugins and their needs are different from mine. Do what serves your needs. I would simply advise anyone to consider if their workflow is serving themselves or not. A lot of people get stuck in the mindset that they need to simplify in order to facilitate easy transitions to situations that just don't come up all that often.
I don't play many games these days, and I certainly don't use their hotkeys (I play exclusively on consoles these days, lazily).
None of this likely has anything to do with the article. I'm sorry to report that I did not read it. I come here for the commentary, not the article. I am guilty of that.
While my custom keybindings are something I would not want to give up they can be replicated in any other editor that provides this basic functionality. What cannot be replicated is the whole reason why I prefer emacs, I like being able to use it like a file explorer, like a terminal, I like being able to open or edit pretty much any type of file I ever use. When you combine the ability to work/view most of the files with consistent keybindings, that is the killer feature that emacs provides, its never been about the keybindings.
I'm curious though, I never really got into vim as soon I realized that it only makes sense if your layout is qwerty. Is vim just its keybindings? or is it like emacs in that the keybindings are not the main reason people use it?.
Edit: TLDR - vim is sometimes better than sed for making changes to files, but in my mind that's about it.
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.
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.
Everyone who types on a computer eight hours a day should learn the Vim language. Yes it's hard initially, but that's the case with everything new and different. But getting better every day and having more fun coding or writing should be motivation enough. Also, imagine, if you work over a decade, how many times you had to learn a new editor (notepad++, atom, eclipse, ...) some of which do not exist anymore. If you once learned the vim language, you are getting stronger. There is a reason the editor has existed since the eclipse of programming.
The Vim grammar is exceptional, as spoken language has verbs, subjects, and objects, as does the Vim language. The grammar has different verbs, to begin with. Copying (or yanking) in Vim with y, deleting with d, pasting with p, changing with c, and so on.
You can also see in the comments here people fight over Vim and VSCode, where the natural beauty is the language behind Vim. If you do not want to configure and customize your own, use VSCode and add the Vim extension. But if you're going to get better at your job, you should try the Vim language.
Once mastered, you edit text at the speed of thought. Sounds cheeky, but it's true for me. Instead of thinking, "I want to edit that word," my fingers jump to it and change it with a few keystrokes.
I wrote more on https://www.ssp.sh/blog/why-using-neovim-data-engineer-and-w... in case you are interested.
I also would not say learning vim makes you a better programmer or a better writer. It makes inputting and changing text easier and faster, but that's not what programming or writing is about.
I agree that the vim grammar is nice, but the bigger thing that differentiates editing text in vim versus other editors is its modality. And it is the modality that allows it to have a grammar in the first place. And that grammar does break down in places, just look at every keybind starting with g.
So yes, try vim, because it is pretty great. But if it doesn't work for you, move on to something that does.
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.
- 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
config path: $XDG_CONFIG_HOME/nvim/ -> $XDG_CONFIG_HOME/$NVIM_APPNAME/
data path on Windows: $LOCALAPPDATA/nvim-data/ -> $LOCALAPPDATA/{$NVIM_APPNAME}-data/
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.
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.
Looks like the last edit I published to my Vim config was 5 years ago https://github.com/fvgs/.vim
But hey, maybe I'll find some "lazy" time to give LazyVim a go and give VSCode a break.
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.
Modal editing is awesome though. I use modified Vim keybinds for everything, even web browsing.
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.
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'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
NvChad: https://github.com/NvChad/NvChad
AstroNvim: https://github.com/AstroNvim/AstroNvim
LunarVim: https://github.com/LunarVim/LunarVim
Never got into any of these, but I love that they showcase what's possible.
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.
Stuff like having code locations in irb hyperlink back to the code buffer in another window.
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.
Visual Studio is a bit shit outside of games, .net, or windows desktop software though.
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|
This might work nicely with any editing model, imo.
https://github.com/orgs/community/discussions/12426#discussi...
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'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?
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).
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).
Interview with a VIM Enthusiast: https://youtu.be/9n1dtmzqnCU
also, Interview with a Emacs Enthusiast: https://youtu.be/urcL86UpqZc
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.
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.
https://github.com/folke/lazy.nvim is maybe a more interesting link
If I wanted an IDE, I'd switch to the terminal version of Emacs.
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.
Btw, if you this is your first trying it check out Elijah Manor's video: https://www.youtube.com/watch?v=N93cTbtLCIM
Here's to hoping we get a nice way to play with containers in neovim. I'm sorely missing devcontainers from vscode.
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.
Most plugins only contain examples for some of them, but in the general case you can just add the GitHub url to the manager and you're good to go.
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.
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.
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.
[1]: https://nvchad.com/
Try it out
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, 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).
Vim is useful immediately! I use it without customization all the time when I ssh into a new system for instance.
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.
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 :)
Lol empty
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.
This kind of metaphor gets thrown around so often in this context. The editor is not your hammer, it's not your drill, it's your entire workshop.
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.
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.
> HackerNews or Reddit
I read hn before bed for a couple of minutes
>I have worked every single day for the last 2 years
That sounds super unhealthy
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
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.
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.
In my opinion there is no "One size sits all" configuration of vim that could be packaged up for mass adoption.
I compiled vim 8 recently, looks even better that my distro package by default. Its a new fresh start to me.
the beauty is that I can use it on any servers too.
For everything else, I use a GUI.
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.
Emacs is a graphical application. gVim is a graphical application. Neovim supports embedding in various GUI clients, including Neovide and VS Code.
I have been using nvim for 3 years as an in-terminal IDE while maintaining my own config and have switched to LazyVim.
At this point, this is (somewhat unfortunately, I really like vim and emacs) a big selling point for vscode.
However, there are plugins to use LLM’s while coding with Neovim and Emacs, so, you can still use these editors for that if you want.
copilot for business exists https://docs.github.com/en/enterprise-cloud@latest/copilot/o...
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.
As you said though.. It won't compete with 1st party love given to VSC. For example, I have no idea if "neighboring tabs" is a feature in neovim.
Talking about tpope's official neovim plugin
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.
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.
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.
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.
For example ChatGPT.nvim [1].
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.
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.
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.
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.
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.