> This article describes my Vim journey, starting from heavy personal customization and ending with a renewed love for defaults
this exact pattern is found in so many vi|m articles and is touted as a triumph of vim's default patterns, when it is really a failure of vim to support whole ranges of functionality. as a daily user of neovim, i know that vscode is a superior alternative and am waiting for a month off to transfer all my vim customizations to a real ide
This pattern is also seen in almost every enterprise application purchase I've seen over the last 10-15 years. The process is as follows:
1) RFP, RFQ then purchase your ideal enterprise application.
2) Start customizing it to meet your old way of working (and before you really understand it) while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
3) Complain that it won't really let you work the way you did a) on the mainframe which was designed based on b) the way you did it with paper and pen.
4) Throw in the towel or force your users to adopt some practice that was neither a) your original process or b) the vendors optimized process.
I've seen this pattern with:
1) Oracle ERP
2) SAP
3) Jira (twice)
4) PeopleSoft (twice)
5) Workday
6) ServiceNow
7) Remedy (twice)
One of the most solid recommendations I can give is that when you purchase a software system, don't do any customization for the first 12-18 months.
> while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
Do they?
If you've seen the pattern you describe almost everywhere, and the key second steps (well, “customize out of the gate to fit your business processes”) are exactly what the vendor markets heavily, what makes you think there huge numbers of customers who are both not customizing and doing just fine?
I've seen and heard of a few cases where customers use software of that kind and minimize customization of the software and instead try to adapt their business processes to the software. And usually those are at least as much horror stories as any heavy customizers.
Really, as much as it's not in the vendor’s interests, big bang implementation of this kind of software that becomes immediately central to a wide array of business processes is probably a bad idea for the same reason that big bang software system replacements usually are, even when there is no existing software system being replaced. Incremental, iterative improvements to business processes and supporting tools are probably a better idea. But big-bang, notionally close-ended projects are more succinct “achievements” on manager/executive CVs resumes, and no one is courting buyers and giving out swag for continuous improvement.
Oh yes. I'm going through exactly that with Jira right now. Not that I'm at all a fan of the thing, but when you look at what's there, you get at least a sense of how Atlassian thought it should be used.
Enter some individuals who think that they know better and have determination to force that Jira-shaped peg through their round hole, even if they have to use a jackhammer to do so. The result is the worst possible outcome, and every user gets to pay each day for it. m(
Do you disagree in only this specific case or do you disagree in general and cite this specific case as being emblematic of why they're wrong? It's not clear to me what your point is.
I also find that vim defaults are very lackluster, I could spend all day listing its faults:
- hjkl is not a reasonable default mapping for motion, for one it doesn't make it obvious that j is down and l is up since the keys are next to one another (which makes it a lot harder to memorise in the first place) but on top of that it wastes two very premium home row keys, h and l, for something that you really shouldn't end up using a whole lot (b, w, f, t, e and friends are usually much more efficient for moving on the current line).
- To make matters worse, the one key that's easiest to access on any keyboard, the space bar, is... just doing the same thing as l, it moves right. So now you have two of the best keys on the keyboard mapped redundantly to a relatively little used function.
- What about the enter/return key? It does the same thing as j, it moves down. Brilliant.
Those are just minor nitpicks of course, but I have a laundry list of those if anybody cares to hear them. It's littered with small inconsistencies and idiosyncrasies that stem from historical baggage and not actually trying to design an ergonomic editor.
That being said I don't get where you're coming from with VScode. Do you consider the editor part of VSCode to be better than Vim, or are you talking about Vim failing as an IDE?
It's important not to mix things up, VSCode is an IDE, Vim isn't. If you wanted an IDE and tried to get Vim to do that by adding 3MB of vimscript from various sources to make it work I can't blame you for giving up, it's probably going to end up being a mess.
> but on top of that it wastes two very premium home row keys, h and l, for something that you really shouldn't end up using a whole lot
Even if with all the advanced search and move features, I still use the h and l keys pretty often. Being able to skip to a certain character is nice, but I find pretty often I just need to move a few characters forward or back, and a mindless `lll` is much easier than doing the mental math of which character I want to stop at and using the appropriate navigation command.
I've also grown to appreciate that the default keys are the most basic commands: on the right side, single-unit navigation, and on the left, basic character entry/removal.
> To make matters worse, the one key that's easiest to access on any keyboard, the space bar, is... just doing the same thing as l, it moves right. So now you have two of the best keys on the keyboard mapped redundantly to a relatively little used function.
I'm actually very thankful for this. I never thought about it before, but I realize that I never use my thumb when in Vim (other than to add spaces when typing normally) and I _think_ I like that. It let's me concentrate on the other fingers. Might be a matter of practice, but as it is I don't feel a need to incorporate the space bar or my thumb into my vim commands. It lets my thumb stay "dumb" so it doesn't interfere with any non-vim typing habits.
> If you wanted an IDE and tried to get Vim to do that by adding 3MB of vimscript from various sources to make it work I can't blame you for giving up, it's probably going to end up being a mess.
Agreed with this. For people that want to work in an IDE, they shouldn't work in Vim. Personally I dislike IDEs, and in part use vim to stick to a (relatively) simple editor.
> hjkl is not a reasonable default mapping for motion, for one it doesn't make it obvious that j is down and l is up since the keys are next to one another (which makes it a lot harder to memorise in the first place)
This, people in this thread are talking like the defaults like they were handed down by devine beings from the ancient past. The truth is that they are often just warts from and old past that can't be removed for backwards compatibility.
My personal vim ethos: You can, and you SHOULD tailor it to yourself.
I've always seen it as a trade-off based on what I'm using Vim a lot for. When I'm using Vim remotely on a hundred different systems I admin, then having a good grasp of of being comfortable using the defaults is extremely useful, and it feels painful to try to use something that's not enabled by default that is my preference. When I'm doing developing something more complex, I definitely appreciate more customization.
Vim (or at least some vi derivative) is semi-unique among many of the more complex tools we use in that it exists by default on just about every Unix host you connect to, so it has sort of a dual life in that respect. It's many people's go-to tool for local development, but it's also the default tool you can rely on for text editing remotely. Those use cases have somewhat separate pressures they place on how people use it.
Managing servers was why I started using vim other places. I started to use it for basic text editing and for coding, just so I could practice and not feel dumb when I needed it (far too often) on a production box. I also avoided too much customization for this reason too.
Still use vim for as much as I can. The language is too rich, and there’s a lot of muscle memory I’ve built up. It also tickles some part of my brain that’s always looking for better, faster, more effortless ways to do things, so I feel like it prompts learning in ways no other software I’ve used does.
It’s found on an matter really. People just get bored, obsessive and eventually "fatigued". No editor makes a boring job better, but some make it worse.
Honestly same. The vim integration in vscode is good enough, and the IDE features make refactoring and editing so much easier.
I know that you can get good LSP integrations in vim, but the problem is that discovering the features available to you is impossible in a text-first UI. In vscode I can go through menus, I can right click and see available refactoring options, etc.
this exact pattern is found in so many vi|m articles and is touted as a triumph of vim's default patterns, when it is really a failure of vim to support whole ranges of functionality. as a daily user of neovim, i know that vscode is a superior alternative and am waiting for a month off to transfer all my vim customizations to a real ide