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...
Note that however crtl-c and esc are not strictly equivalent: if you do esc or ctrl-c, the position of the cursor when back in normal mode will differ. You can see this if you do insert then esc repeatedly, seeing the cursor moving. Cursor doesn't move with ctrl-c (which somehow I prefer).
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.
The freaking movement keys. The amount of rationalizing about them is INSANE. CRAZY. MADNESS. "Touch typing"/"more efficient"/bla bla, with 0 studies backing it.
Why do I say this? They shouldn't be in a line. No mass manufactured device in the last 30+ years has them in a line. They're... you know, up is up, down is down, left is left and right is right. Yet some people will defend the setup to their deaths.
And the reason they're like that is... because a terminal 50 years ago, that probably only sold tens of thousands of units, at best, had the setup like that to make it cheaper to produce:
http://xahlee.info/kbd/history_of_vi_keys.html
It's basically the QWERTY keyboard story all over again.
Backwards compatibility is a major pain in the neck.
They're just dumb but people have been beaten over the head with them for so long that Stockholm syndrome is SUPER strong, as proven by these comments.
I use QWERTY because I have to, I don't like it and I can't do much about it in practice. People frequently defend Vi's HJKL vehemently - just like - if I'm not mistaken - you, presenting it as a superior option for some reason.
Personally I don't want to move my hands from where I'm writing to the other side of they keyboard just to move the cursor.
In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.
They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.
Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.
HUJK, for example. WASD is the standard example.
Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).
As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.
That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.
I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).
Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.
Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.
For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.
Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.
The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
(I wouldn't blame vim so much, but more the vim greybeards who think they're still using a 70's terminal)
HUJK instead of HJKL, basically WASD moved to the right :-)
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 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...
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.
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’ve definitely been down the Vim config rabbit hole and struggled to find the right balance between “cool” (actively developed with newer features) vs. “best practice” (more mature and stable). My current approach is to search Hacker News comments for “vim plugin-feature-I-want” and the most popular comments usually point me in the right direction.
For what it’s worth, I use Neovim with ALE at the moment and it works just fine.
I 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 don't care about your problem, you're holding it wrong."
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 translating 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 "less cluttered ui" and "generally more 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.
That's fine, a person's wants and needs change, if you require an IDE using vscode is fine. Demanding vim/neovim bend to your needs perfectly is less so.
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 is covering 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 use "black nvim" and head to repository boy. There are genuine docs and installation instructions, why would you ask other people to rephrase it?
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.
The amount of work needed not only to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
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.