No, but time I spend setting up and tweaking a custom environment is time I could be spending internalizing the tools that exist everywhere and work well after the learning curve.
Since working on a foreign machine usually only happens when something’s broken, it’s already a stressful situation— my tools not behaving the way I expect won’t help matters.
You should be able to "internalize" the tools that "exist everywhere" in a year or two are most. If you start using vim at the university you would be done internalizing its internal tools when you graduate.
You then have the rest 30+ years of your career to use a nice environment, and it doesn't take much time "setting up and tweaking" to get non-internal tools like NerdTree, linters, git gutter, etc working. More like a week or so, on and off.
Absolutely not. I have been using vim for almost a decade at this point and still am internalizing new vim skills.
One decade? How long can this go on? Two decades? Three? If one is in the middle of their professional career before they've mastered all the "vim skills" (or even more so, the more numerous) Emacs skills, then they'll never gonna master them all in time to matter anyway.
And the point of internal vs third party is not if internal are numerous enough, but if they're productive, convenient enough. Internally vim has tons of features, but it doesn't have a linter, for example.
In any case, things one still discovers "a decade in" are not really an argument for not setting up a good main driver vim environment with more than built-in conveniences. Those wont prevent you from learning vim built ins, and you could get immediate access to features, and in a more convenient form, that could take you a decade to chance upon as built-ins.
I think you're mistaken in thinking there's a solution to this problem, or even that it's a problem.
The limiting factors here are your rate of learning and when you stop learning. Continuing to learn well into your career is a feature, not a bug.
> And the point of internal vs third party is not if internal are numerous enough, but if they're productive, convenient enough. Internally vim has tons of features, but it doesn't have a linter, for example.
I have a linter. It doesn't need to be in my editor, and I rarely make linting errors anyway. When I do make linting errors, I want it to be a bit painful so I stop making linting errors.
I'd argue that the bugs introduced by your linter are worse than the problem they solve. And the more plugins you have, the more buggy your system is due to the interactions.
> In any case, things one still discovers "a decade in" are not really an argument for not setting up a good main driver vim environment with more than built-in conveniences. Those wont prevent you from learning vim built ins, and you could get immediate access to features, and in a more convenient form, that could take you a decade to chance upon as built-ins.
Chance across? Don't plugins have the same problem, that you have to wait to chance across them? If you're actively out searching for plugins to solve your problems, you'll find them, but if you just google how to solve the problems with builtin tools, you'll find that too.
Plugins absolutely prevent you from using builtins, and frequently break the builtins to boot. You're probably right about the very basic stuff (i.e. movement, deletion, insertion) but anything beyond that is frequently broken on systems with a lot of plugins.
There are two assumptions I think you're making here:
Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment, and see zero evidence that this hampers my productivity in any way.
Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.
Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.
You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":
First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.
There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.
There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.
When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.
A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)
Assumption 2: Text entry is a significant bottleneck compared to other areas of your process. In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.
Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.
Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!
And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.
But it's not. In a modern editor, swapping two lines is ctrl-shift-up for swapping up, or ctrl-shift-down for swapping down.
Vim isn't that much more powerful any more compared to modern code editors, it's just weirder.
> I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim
So were you a faster typer? How was it faster?
I find there's two points that get me speed in a code editor: Language specific shortcuts (like go to definition) and multi-cursor editing for editing formulas and the like.
But I'm not sure if Notepad++ has multi-cursor.
I'm not sure if vim does, either? I know you can do stuff whose result is very similar to as if you were multi-cursor editing, but do you actually get intuitive methods to place multiple cursors in various ways and then interactively edit what's there while seeing it change?
Because that's no longer a "nice to have". There's a huge difference between formulating an incantation in your head firing, and seeing if the result is right--that gets really complex with multiple edit points--and doing it interactively. You actually see a block of code grow and unfold interactively as you edit it. And it doesnt involve regular expressions :) (which are cool, but almost never fail to take my mind completely off the problem at hand, I only benefit if it operates on a pretty large chunk of text)
Sure, if you really hate your hands. ;)
> So were you a faster typer? How was it faster?
Maybe I just was a faster typist. I don't know. It doesn't really matter to the point: if your text editor gets out of the way enough that text editing isn't your bottleneck, then all time spent optimizing your text editor usage is completely wasted. My argument isn't "vim is better than Notepad++", my argument is "vim in the default configuration is good enough to not be a bottleneck". Notepad++ may be good enough to not be a bottleneck either--I haven't used it enough to have an opinion.
> Language specific shortcuts (like go to definition)
I would argue that this is more of an IDE feature than a text editor feature.
> multi-cursor editing for editing formulas and the like.
I'm not sure what you mean here. There's two things I do in vim which might be what you're talking about: splits so I can be in two parts of the same file at once, or splits where I have a REPL open and am editing fragments in one half of the screen while running them in the other half of the screen. But if you're talking about something else, I'd like to understand it so I can learn how to do it in vim. ;)
Like all rules, this has exceptions. This is sort of a good "exception that proves the rule". Yes, PEP8 compliant Python development requires you make a few-line change to your .vimrc. My .vimrc contains this:
" Set tabs to width 2.
filetype plugin indent on
set shiftwidth=2
set softtabstop=2
set tabstop=2
set expandtab
" language-specific settings: tab width is 4 for python
autocmd FileType python setlocal shiftwidth=4 softtabstop=4 tabstop=4
Which I've never found much important.
If you know Vim basics (modes, basic commands, movements, etc), then you can use vim in any environment that you SSH to or happen to have to work temporarily on.
But why wouldn't you want the Vim on your main driver laptop, which you use every day to not have a nice custom setup, and some good third party plugins (e.g. file search, linting, etc)?
It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.
And it's also not like you should optimize for the random remote machine you'll get in, and not where you spend hours programming every day.
So unless one is a sysadmin and has no real "main" machine he uses vim in, this makes no sense to me...