As someone who has wasted like 30 years off and on learning how to edit like it's 1979 in vim, I recommend you do not do get peer-pressured into that. Take a look at micro or TextAdept or use gedit with sshfs or VSCode or.. just something from recent decades.
In my experience, that's not a real option in large, professional system admin settings. You wouldn't dare do that on a production machine without your change management process, and your team of admins won't care about installing micro on the thousands of machines you have to manage. You'd have to do a pull request to some kind of config management repo, and no one will agree your pet editor merits a deploy, and your boss will think you're wasting everyone's time.
I'm not covering half of it. Trust me, it is just generally not an option for system administration in the large.
You're right, of course it's impossible for anyone to approve installing a modern editor. How ignorant of me to suggest that. Everyone must use the editor and paradigm from the late 1970s. That's the only way professional system administrators and organizations can operate. No one has time to approve a pull request, no matter how outdated the editor is. We all learned it. Everyone else has to learn it also. Until the end of time. Amen.
I mean, I’d be surprised if the percentage of SAs that are proficient in vi is less than 90% (even that percentage is probably low), so I really don’t think it’s a problem that needs to be solved. vi/m works superbly as the main text editor on *nix servers. Sounds like you just hated it from the get go and refuse to learn it. And that’s also fine.
I learned it and use it all the time. It's just an outdated editor and religion. And there is no logical reason not to replace it with something modern and superior. And it's a shame that people are suggesting that young people waste their time with it.
It's just amazing that says admins are literally suggessting they can't install a program.
Given its prevalence in the SA landscape (which I don’t think even you can deny), to state that learning Vi would be a waste of time for any young person interested in the industry, would be, well, completely inaccurate. But we obviously completely disagree. We can just probably leave it at that.
*nix system administration at many companies means that there are 1000s of RHEL or CentOS or older Solaris servers that you may very often need to edit a file if there is no config management (which is often the case). What all these servers will have to do that will be vi (or vim if you’re lucky). In most cases you can’t just go install some random other text editor that you happen to like better or be more proficient in. That means you have to be at least somewhat functional in vi to be able to perform basic tasks.
If you literally have to log into an ssh session on 1000s of machines running discontinued operating systems to manually edit files and can never install new tools for editing or anything else in those machines, then you deserve to go out of business.
you don't need to eschew model editing if you go to something like vscode... there's a great neovim plugin for vscode that gives you full vim in the background but also has a nicer vscode interface for the frontend.
I just suspect that people who advocate for modal editing and hjkl etc. think that those things are some grand UX secret that only real nerds know about. But really they are just artifacts of that particular historical circumstance.
"How did vi's mode switching idea came from?
Back in 1970s, terminal screen are 80 columns by 24 lines. There's no real-time editing. You edit by typing a command, then call another command to have the screen update to show the result of your command. Vi's “modal editing” is evolved from this. This is also why emacs's manual calls itself “Real Time Display Editor”. Emacs is the first or one of the first “Real Time Display” editor.
Why vi uses j k h l for cursor movement?
Unix vi's use of j k h i for cursor movement, and the choice of Escape key for mode switching, came from the keyboard it was developed on, the ADM-3A terminal."
> I just suspect that people who advocate for modal editing and hjkl etc. think that those things are some grand UX secret that only real nerds know about. But really they are just artifacts of that particular historical circumstance.
while it's true that it was born of historical necessity and the decisions for it were partly due to keyboard constraints and the other constraints, I disagree vehemently with the assertion that it's not a more efficient way to edit code. writing a screenplay? maybe not but programming? yes... especially in the context of a larger ide.
