> 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.
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.