> The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lua.
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Now how you integrate this into your config is again a little programming problem in and of itself. But it's not really a complex programming problem. You are after all not trying to write some large complex and scalable system. You probably have all the tools necessary to organize your code well. I went with a highly functional approach which passes functions around everywhere but you may be more familiar or happy with another approach. The beauty of a neovim configuration is that you are the only person who needs to maintain it.
I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.
> I agree that neovim is not for people who are not interested in learning their tools.
That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone.
I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this job otherwise.
However, my time is limited. I have to be selective in what I spend time learning. Much of that choice is determined by my employer, project and other requirements. Free time left over for learning other things is even more limited.
Learning another language and API and plugin ecosystem just so I can configure my editor? Maybe for some people, that's time well spent, but personally - having spent a fair bit of time with neovim to give it a fair shake - I realized that what I don't need is a perfect artisinal text editor, but a good-enough IDE that lets me do the things I'm either actually interested in, or paid to do.
Vim as a simple text editor? Perfect, use it every day when dropping into a headless server to edit a config file or two. For an IDE? I don't love vscode, but for what I need, it's fine.
I'm sorry that you read it this way, I think I could have written it differently. That being said, I don't agree that any of the things you listed are tools.
Moreover, reading what you wrote in your original comment from a more negative stance, I also think it's easy to read it as disdainful but I chose not to read it that way. I would appreciate it if you were more positive in your reading of what I write.
Tools in my mind are things like: a keyboard, your IDE/editor, your build system, your VCS, your userspace utilities (sed, awk, cat, ls, grep, etc), code formatters, code linters. I guess "tool" is probably not the best name for these categories given that I can understand why you would also call a library a tool but to bring in an analogy from woodworking, tools are things you use to make things from the materials (what would be libraries, frameworks, programming languages, etc).
So having this distinction in mind, I don't think it's necessarily incorrect to state that you are of the opinion that what I would categorise as "tools" are not worth learning and (I should add) modifying.
Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
In this sense, I don't think vim, neovim, or emacs are really appropriate for people who don't feel like time spent learning and writing or modifying (let's call them) peripheral tools is worthwhile. Whereas you feel constrained by the need to understand what to you might feel are "irrelevant details" (the need to know the API) about neovim, I feel constrained by what you might feel are "irrelevant details" (the need to adjust to a specific workflow which I might not be used to, the need to constrain myself to a specific set of plugins) about VScode.
That being said, I will say again, to claim that vim takes a lot of time to use and configure is simply wrong. But if you feel like having to learn an API to use an editor is a waste of time then it would explain why your experience might be like this. It's not possible to use vim quickly without having learned the API. Likewise, I feel like having to adjust to a specific way of editing as envisioned by a specific company and a specific plugin writer is a waste of my time and it would explain why my experience of VScode is that it takes a lot of time to configure and use whereas your experience is different. This doesn't mean that VScode takes a lot of time to use and configure, just that it's fundamentally not for me.
I hope the above clarifies things. I would be happy to agree on a different term than "tool" or a clearer way to distinguish between e.g. an IDE and a library or framework.
> Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.
I use zsh, with customizations. I know git, and mercurial, and a few other VCS I've forgotten. I know my way around the Linux toolkit. I can configure a Python or frontend or Go environment with whatever linters and formatters and pre-commit and so on and so on. I have a fat repo of dotfiles. Hell, I use vim whenever I need to work on headless servers or the odd config file and the like. Works fine, in that use case.
Every time I learn or modify a tool, I look at whether there is a net benefit in learning it, whether it makes me more productive. Zsh shortcuts for example are tiny, but I get a nice little productivity boost that adds up to many hours over time.
I have spent the hours learning and configuring neovim, but run up against that point where that time spent is no longer yielding that benefit, compared to just using vscode and putting up with its issues.
So, I chose one tool over another. But it's a generalization to say I somehow don't think learning "tooling" is worthwhile.
Okay, so it seems you certainly fall into the category of people who generally find it worthwhile to learn and configure/modify tools. So I really don't understand how you came to the conclusion that neovim and vim are not worth the time.
Neovim takes a lot less time (weeks to months) to learn than something like git (months to years), while I know both very well, I find that I am more often interacting with my text editor than I am with git.
It seems to me that the tradeoff of using something like VSCode, unless it perfectly matches your particular workflow, is much more friction than dealing with git vs something else.
To that end, if you have given neovim a chance and learned it, then I struggle to see how you had problems with something like e.g. making :Black run automatically before the file is written.
Autocommands are a fundamental vim feature, one of the most important for vim related automation aside from rebinding. Something you will have encountered as soon as you search for "vim how to do X when Y." Figuring out that the PSF black vim plugin is a good option for a way to run black from inside vim is a matter of a 10 second google search. I can understand this being a potentially difficult problem if you really had no neovim configuration experience, but if you have learned neovim then this really is a single line addition to your on_attach which you would have already had to configure for the python language server of your choice.
And even then, the black documentation page explicitly shows how to use vimscript (which can be embedded in nvim lua syntax using vim.cmd, again, a basic neovim feature you would have encountered in any guide to configuring neovim) to achieve this in 4 lines.
I use neovim because it eliminates friction. Whenever I do something and find myself repeating an editing or reading adjacent task and making mistakes I think to myself: "how can I solve this once and for all?" I sit down, fix it in neovim and lua in 20-40 minutes. How do I justify the time investment? The 40 minutes (or hell, even if it took 2 hours it would still be worth it) investment once every couple of months to improve some aspect of my workflow keeps the friction down and the reduced friction more than makes up for the 40 minutes or 2 hours of lost time because I would lose much more time on frustration and lack of motivation.
This friction doesn't affect everyone as much as it does me, which is why I notice other people, less affected than me, don't find dealing with learning and configuring/modifying/writing tooling to be worthwhile. But again, what you wrote indicates to me that this kind of friction _does_ matter to you.
So my question is, how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
> how do you justify the friction of VSCode (as you yourself put it, VSCode isn't perfect) when you have tools such as vim, neovim, emacs, or whatever else that are designed to help reduce friction for a modest but steep initial learning curve.
Because VSCode also is designed to reduce friction for a modest but (less) steep initial learning curve.
I have used vim a lot. I've also used VSCode a lot. It sounds like you haven't dived into VSCode in the same way you've dived into Vim. I'm trusting you that your Vim setup, after tweaking it to your liking and diving into it, is perfect for you. So I'm asking you to trust me (and the other commenter), and my VSCode setup, after tweaking it and diving into it, is perfect for me.
Using Vim emulation in VSCode, plus the richness of VSCode configurability, I have an environment I'm over the moon about, and it was less steep of a learning curve than Vim.
You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
>You seem to think that anything that isn't Vim or Emacs can not compare. I'm asking you to reconsider that.
I don't think you have read the discussion between me and the other commenter very thoroughly if you came to this conclusion.
I have repeatedly re-iterated my stance so I would rather not do it again but tools such as VS code are inherently inflexible (I have put a couple of weeks into trialling and configuring vscode) for good reasons and to tailor to a specific audience.
My argument is that for the other audience, tools such as Vim or Emacs (or in some extremes, writing your own editor or using something even more obscure) offer superior flexibility and offer the possibility of much reduced friction in exchange for more time needed to learn, configure and maitain and that this setup is worth it for that different target audience which the person I was talking to has indicated membership in.
For a more in depth overview of my stance, please don't skim read what I wrote and as a result jump to incorrect conclusions.
First off, editing Python (I am not familiar with Javascript enough to make any claims about it) doesn't require any sophisticated IDE and can be done quite proficiently in any decent text editor. I don't say this having written 3 lines of Python in my life, I say this with about 9 years of experience writing at least some python almost every single day. I think the powerful baseline that an editor such as vim or neovim provides is sufficient for most development tasks in most languages which aren't e.g. Java. That being said, integration of a syntax and type checker can be nice to make development a little bit more painless and tab completion can sometimes take something which might take 20 seconds to look up and verify and turn it into a 3 second task.
Genuinely the initial up-front work for these features for a new language for me is to make sure a language server is installed in the path and add it to the list of active LSPs in my configuration file (one line change).
This takes about a minute or two depending on how quickly your package manager can install the language server. Sometimes it's some obscure language where the language server isn't easy to find. There's a plugin for automating the installation and configuration of language servers. There are pros and cons to this plugin.
> Furthermore, the community does not have a good culture of documentation and learning: too many plugins have very sparse docs
This is still true about the lua API for neovim, that being said, once you learn it once, it stays mostly stable (and when stability breaks, it's mentioned publicly in the changelog) and leaves a lot of power at your fingertips. When it comes to third party plugins, a lot of them are just snippets of code which someone wrote and found useful, I think expecting a book on that is a bit excessive, a lot of the time you can just read the code or write your own more tailored version.
> other online resources such as the Neovim subreddit are hostile to newcomers with "RTFM" a common answer
My personal experience is with the neovim IRC channel which has generally been helpful. Although, again, if you learn the APIs which neovim exposes, a lot of questions can be answered by simply solving the programming problem which presents itself. I rarely find myself reaching for a support forum.
> The community is also fragmented, with too many ways to do the same thing in the name of some platonic ideal of personal freedom over practicality.
There's a difference between the editor having many ways to do the same thing and the community having written many solutions for the same problem. I would struggle to find a community of programmers who don't have the latter problem, but neovim doesn't really have the former problem to any major extent.
> A simple question like "How do I set up Black with neovim to format my Python files on save?"
... is a programming question. What events does neovim expose hookpoints for to do things such as auto-formatting? There are many events but BufWritePre seems the most appropriate. How do you call black from neovim? Well the PSF official neovim plugin is probably a good starting point. How do you glue this together? Well, the on_attach function of the LSP for python seems like a good starting point.
Something like:
Now how you integrate this into your config is again a little programming problem in and of itself. But it's not really a complex programming problem. You are after all not trying to write some large complex and scalable system. You probably have all the tools necessary to organize your code well. I went with a highly functional approach which passes functions around everywhere but you may be more familiar or happy with another approach. The beauty of a neovim configuration is that you are the only person who needs to maintain it.I don't find any of this particularly time consuming. I normally don't touch my neovim configuration for months at a time as it continues working. I keep it tracked in a git repository and synchronise this across machines whenever I change something. My only personal annoyances with neovim are the fact that they haven't stabilized it yet and that package managers for neovim aren't as mature as e.g. something like cargo where you can use a lockfile. That being said. It's a powerful tool which requires a time investment to learn. But if you learn it, you can achieve really quite sophisticated things without needing to spend time looking for a very specific pre-existing solution. Usually to solve your problem you will need only a small handful of lines of lua.
> In the meantime, I can just Ctrl+P and install what I need in vscode and be on my way in a few minutes.
That's nice, but what if you want to run a different auto-formatter depending on the codebase? What if you want to automate this? What if you want to disable auto-formatting altogether in some cases? What if you want a configurable list of auto-formatters per codebase? With neovim I have this particular highly flexible feature working in ~20 lines of lua. How much would it take to modify or make a vscode plugin to implement these features?
My most common issues with vscode were: lack of flexibility, lack of customizability, and lack of transparency. But these are expected tradeoffs of such a system. I understand why vscode exists with these tradeoffs but I am not willing to make them.
I agree that neovim is not for people who are not interested in learning their tools. For people who want to just start typing code with whatever automations they are reasonably familiar with, and willing to accommodate any weird variations in the workflow which using a different tool might entail then vscode seems like a fine choice. But the main problem with neovim here is your own perspective of it. It is first and foremost a powerful text editor with an IDE building toolkit. It is not an IDE itself. You can use it to very quickly design a bespoke IDE which you like, without writing very much code. But you need to spend the time to learn its APIs first. If spending the time needed to learn it and then writing ~20 lines at a time to get it working how you want is not your cup of tea, then don't use neovim, it's clearly not for you.