is "vi" worth learning in 2022?

[chrbr]

But there is choice and I have to run it once per 2-3 years. Sorry but I forget the "menu" key every time.

If you do not use it frequently a printed cheat sheet is sufficient. It is good to have the choice. By the way, as far as I know there is no "menu" key in vi. I think nano/pico or so have such a key. And be comfortable with one editor is better than have lousy practice in multiple editors .

 

[scottro]

Easy. For vi (or nvi, which is what FreeBSD uses), type

:help

With vim, if you open it by typing vim in a console or x window, what to type to get help appears on the screen.
But like chrbr says, it's no different than learning alt+f to open a menu in many GUI programs.
The shortcuts are also used in mutt, less (which you use to view man pages) w3m, as a start.

 

[drhowarddrfine]

I forget the "menu" key every time.

Same problem for me for any editor you use that I don't.

 

[ralphbsz]

And be comfortable with one editor is better than have lousy practice in multiple editors .

Beware of the man who has only one gun, because he knows how to use it.

 

[Grell]

As mentioned before, vi is really not that hard to learn. Just spend a little time doing vimtutor on FreeBSD. It doesn't take you very long and by the time you're done you'll be proficient enough to handle most tasks with vi/vim.

 

[k3y5]

I've always used nano to edit text files. Is it even worth spending the time to master vi/vim ? I'd rather put my time towards learning new FreeBSD commands, shell scripting, or programming in C.. and for code editors there's stuff like geany. I just don't see the advantages of going through the trouble of learning the ins and outs of this editor, when I can use something much simpler and get the same thing done. Maybe someone can explain ? Anyone actually still use vi in 2022 and what for?

I love neovim. The plugins/package manager is much easier to customize. I would highly recommend it.

1. You can build a really great ENV that works everywhere. It's super nice to just pull your own config onto a remote server and have everything "just work," nicely. If you use multiple machines. You get the same editor across all systems. Learn once, utilize everywhere.
2. Increased development speed. You can build custom functions, and layouts that help you to bootstrap projects or scripts. When you have your initial hot commands down, you can really start to move. This is the same with other editors, the main difference is targeting. You're fast across all machines, in all environments.
3. Ultimate control, and customization without limits.
4. Cool guy points.

Learning VI is like learning Tai Chi. Will it help you in a fight directly? Probably not. Will the discipline, and form factor help to improve overall? I believe so.

 

[1lya]

Why do you need to study the Vi text editor? I have been using FreeBSD for more than 6 years and during this time I have always tried to use the "ee" text editor. This text editor is also bundled with the basic system, but it is much easier to manage. There is no need to learn and memorize any commands to control. In addition, you can install any other text editor via the Internet, if you need it.

 

[Holger]

1. You can build a really great ENV that works everywhere. It's super nice to just pull your own config onto a remote server and have everything "just work," nicely. If you use multiple machines. You get the same editor across all systems. Learn once, utilize everywhere.

I second this. Having an editor/IDE that works, e.g., over SSH on a remote server is an issue to be considered.

 

[cy@]

I've always used nano to edit text files. Is it even worth spending the time to master vi/vim ? I'd rather put my time towards learning new FreeBSD commands, shell scripting, or programming in C.. and for code editors there's stuff like geany. I just don't see the advantages of going through the trouble of learning the ins and outs of this editor, when I can use something much simpler and get the same thing done. Maybe someone can explain ? Anyone actually still use vi in 2022 and what for?

Yes.

I used to use ISPF Edit on the IBM mainframe. After having used vi for ~ 25 years (6 years ago) I found myself on a mainframe again, helping out. The modal nature of vi is super handy. My hands don't leave the home keys on the keyboard much. Though I need to keep track of which mode the editor is in but that is not nearly the PITA it is to move around a file using cursor keys or worse yet, the mouse.

Having said that, when I do work on larger projects I use gvim instead of the vi editor in /usr/bin. The colours are handy when writing code and since gvim backgrounds itself I can work on many different source files without opening multiple windows running a shell.

Simply, not a PITA other editors are.

 

[rrsum]

As a person whose first editor was a card punch, vi was a welcome editor on the newly invented monitors! I still love it and am always uncomfortable moving my hands off the keyboard to move a mouse. It still amazes me how well it was designed, especially for the environment in which it existed.

 

[Alain De Vos]

Neovim integrates good with language-servers.
But i'm not a fan of neovim lua configuration, i use, "init.vim"

 

[gpw928]

As a person whose first editor was a card punch...

When I first started we had a "punch room" which operated just like a typing pool, but with Hollerith card punch machines (IBM 026 and 029). Turn around to get cards punched from coding sheets was about a day. Then it took another day for the return trip by courier to the computer centre to get your program run. For quick and dirty changes to card decks, we had a small manual punch. Everybody was quite adroit at using it.

Once an application was working and in production, a binary executable "dump deck" was produced on Hollerith cards using a card punch attached to the computer. Each card in the deck had a sequence number and checksum in the last few columns. "Dump decks" were loaded directly into memory from the card reader for immediate execution.

For "urgent application patches", which could not afford the turn-around times for punch room code changes and re-compiling, we used to get the source code listings and relocation maps, then change binary "dump deck" executable programs by reverse-compiling from binary to symbolic assembler, figuring out where to put a branch to add assembler instructions, converting back to binary code, re-calculating and applying the appropriate sequence number and checksum, manually punching the cards that needed to be changed and/or added, and re-assembling the dump deck to be sent off for execution.

And people complain that it's too hard to figure out how to exit from vi...

 

[chessguy64]

You have to remember the original question where I was asking if it was worth mastering vi, not just learning introductory commands and navigation. Yes, I've done vimtutor and learned the basics of vi/vim, and I get it's useful to know in certain situations. But I don't do heavy daily text editing, to the point where I'd need to recall 100+ commands I memorized and edit at high speed. I would always choose the option of learning / training in programming, shell scripting, or getting better at FreeBSD itself vs. mastering an editor. If I was troubleshooting an issue in FreeBSD... something I could have learned about months earlier and had already solved had I not spent the time reading vim books and becoming a vim guru.. I would feel like I wasted my time for no good reason. Life is too short. I've always had a hard time completing fiction books as well, even though I own a small library of them (~50 books. I've finished maybe 3.) To me it's all just dispensible entertainment that has no real practical application. But anything to do with *NIX, programming, certification, or anything else technical I can read over and over again no matter how long the book is and never get tired of.

 

[smithi]

When I first started we had a "punch room" which operated just like a typing pool, but with Hollerith card punch machines (IBM 026 and 029).

"Spin me back down the years and the days of my youth ..." Jethro Tull ~'72

Turn around to get cards punched from coding sheets was about a day. Then it took another day for the return trip by courier to the computer centre to get your program run.

We had in-house punch girls (yes all girls, a whole floor) and computer (another floor) but it still took half a day except in emergencies.

For quick and dirty changes to card decks, we had a small manual punch. Everybody was quite adroit at using it.

Needs must. At my first job, in idle times we'd hand-punch mini programs in binary onto a single card to be booted and run, flash a few lights and such. NCR-315 12-bit words, 12-row cards, 80-slab programs ... ah, nostalgia ... <sob>

For "urgent application patches", which could not afford the turn-around times for punch room code changes and re-compiling, we used to get the source code listings and relocation maps, then change binary "dump deck" executable programs by reverse-compiling from binary to symbolic assembler, figuring out where to put a branch to add assembler instructions, converting back to binary code, re-calculating and applying the appropriate sequence number and checksum, manually punching the cards that needed to be changed and/or added, and re-assembling the dump deck to be sent off for execution.

Kudos! We had the luxury of proper 15" assembly listings, but patching broken COBOL programs in hand-assembled S/360 machine code was often challenging, even with generous 'patch areas' left in executables.

I never stooped to writing in COBOL, but knew what ugly code it generated.

And people complain that it's too hard to figure out how to exit from vi...

:q! is all the vi I need!

 

[drhowarddrfine]

chessguy64 You don't need to learn 100+ commands--and I'm not sure vi has that many, though vim might--and I doubt anyone here knows half of those. You don't need to master your car but you know quite a bit about it as you drive around every day for years.

I can probably guarantee you will use vi/vim as long as you are using BSD and any other Unix-like system. Depending on the type of programming or editing you do, you'll find it's more handy and available than any other, too.

 

[chessguy64]

[FONT=monospace]chessguy64[/FONT] You don't need to learn 100+ commands-

I know. It's almost like I've said that before in my previous post. Wait... I did. And yes vim does have 130+ commands.

I can probably guarantee you will use vi/vim as long as you are using BSD and any other Unix-like system. Depending on the type of programming or editing you do, you'll find it's more handy and available than any other, too.

I never said I wouldn't use it for the lifetime of my use with FreeBSD. That's why I went through vimtutor. Again, I'm talking about mastering vim, which goes back to my previous post, my original post, and my original question. Mastering vim... which makes zero sense for me to do. Those weren't anti-vim posts. Please think before posting.

Side note: Is it just me or does it seem like the same info is being posted over and over again in this thread?

 

[chrbr]

What is the meaning of mastering? In my opinion the best master never stops learning and improving the skills.

 

[chessguy64]

What is the meaning of mastering? In my opinion the best master never stops learning and improving the skills.

master​

[ mas-ter, mah-ster ]

noun
a person with the ability or power to use, control, or dispose of something: a master of six languages; to be master of one's fate.


adjective
being master; exercising mastery; dominant.

verb (used with object)
to make oneself master of; become an adept in:to master a language.

 

[ayleid96]

I recommend you learn the minimum needed to do basic editing.

The day will come when freebsd-update wants to merge files and you're dropped into vi.
So yes.

Just edit EDITOR env var and you can have emacs instead of vi.

 

[scottro]

Unlike vi, emacs isn't included in every system. It usually has to be installed as a 3rd party program.

 

[kent_dorfman766]

I'm late to the show, but YES, as it is a good least-common-denominator for when you end up at a root disaster recovery shell.

 

[cracauer@]

I'm late to the show, but YES, as it is a good least-common-denominator for when you end up at a root disaster recovery shell.

Yeah. One disadvantage that I sometimes feel about emacs is that is can (relatively) easily stop working when the pkg structure has a problem and some shared library becomes unavailable or broken. Or /usr/local is no longer mountable.

 

[kpedersen]

and some shared library becomes unavailable or broken. Or /usr/local is no longer mountable.

Typical GNU software that does tend to spread its tentacles into a few too many dependencies.

However if you like the core of emacs and rarely require its more "engineered" features; then OpenBSD's approach of a small emacs-like editor in the base is quite useful. mg(1).

FreeBSD ports has a static flavor of it; so it should be fairly robust if anything goes wrong.

 

[cracauer@]

Typical GNU software that does tend to spread its tentacles into a few too many dependencies.

However if you like the core of emacs and rarely require its more "engineered" features; then OpenBSD's approach of a small emacs-like editor in the base is quite useful. mg(1).

FreeBSD ports has a static flavor of it; so it should be fairly robust if anything goes wrong.

It also helps to `make config` on the emacs port and turn X11, gtk and a few other things off. Right now the default config pulls in a hundred dependencies or so. I never use those features.

 

[kent_dorfman766]

Also, as a purist at heart, vi is just...the thing you use. That and knowing how to effectively do vi macros is kind of elitist cool. If I'm gonna be in an emacs world then I choose TECO. :^)