is "vi" worth learning in 2022?

Editing the scheme language racket in the editor neovim,

test.png
 
You might decide it's not worth mastering, but you can learn enough to use the two primary modes and make simple configuration edits (slowly) in a few minutes.

# open a file and enter normal mode
$ vi file.txt

# normal mode
  • use h and l to move the cursor one character left and right
  • use j and k to move the cursor one line down and and up
  • use x to delete the current character
  • use dd to delete the current line
  • use u to undo the previous change
  • use i to enter insert mode and begin entering new text at the cursor location (insert)
  • use o to enter insert mode and create a new blank line below the current one (open)
# insert mode
  • vi will display --INSERT-- in the bottom left corner when you are in insert mode
  • enter text like any other editor
  • if you make a mistake, press esc to return to normal mode and then use u to undo the previous change or x to delete characters
  • don't sit in insert mode; always press esc to return to normal mode when you have finished typing the current word or sentence
# save the file and exit
  • press esc to return to normal mode and enter :wq to save and quit or :q! to quit without saving
That might be enough to get you through an emergency.
 
A tip to copy from a gui to clipboard & neovim,
Now i see, Ctrl-C to copy from GUI to clipboard.
Going to insert mode in console-editor
Shift+Ctrl+V to insert in console-editor
 
I learnt Vi(m) in the late 2000s as the command line text editor. During university I used various IDEs because various lecturers advocated for their use.
After university I dropped IDEs and did all my "coding" in editors/vim. When I got jobs in IT, everyone around me was using IDEs, but I always felt at home in Vim - I feel very comfortable in the terminal and it was nice having colours/fonts/etc identical with two windows side-by-side (one for Vim, another to compile/run what I was writing).

I used to use shells/bash before moving onto shells/zsh, with both shells I used "vi mode" because it allowed me to use Vi key-bindings to quickly move around the command line - typed a really long command and want to go back 10 words? Just type Escape, followed by 10B - and you're there! Want to now change the rest of the line? Just hit shift-c and you've deleted the rest of the line and can input something different.
Also, you can hit Escape followed by v and you enter $EDITOR (for me, this is set to vim) and you can type your potentially complex command - then just save and quit and the contents of that file is ready on your prompt for you to hit enter and run! I use this a lot when writing "one liner loops"...

A few months ago someone introduced me to devel/jetbrains-goland, an IDE for lang/go. I'm doing a lot of stuff at work with YAML and Go templating, and the IDE actually provided some useful autocompletions and help for what I was doing. I now use it for a lot of what I'm doing at work (mostly Helm, terraform, and markdown), though I still head to my CLI and Vim when writing shell scripts.
But even GoLand has a Vi mode, which I have enabled so I get the "rich editing experience" of an IDE, with all the familiar key bindings I'm used to from Vim so I can move around and do text transformations quickly.

Ultimately, if you are going to work with plain text a lot (rather than rich text applications like MS Word/LibreOffice/Google Docs/etc), I think learning the basic Vim key bindings will benefit you even if you move away from Vim - most IDEs have plug-ins or built-in Vi mode.
The more you use it, the more natural it will feel, and when you want to do something "interesting" you can search the web for how you might do it - something I commonly want to do but forget how to do it is delete all lines containing a pattern - my web browser just remembers that's a common search term and offers the linked article to me quickly when I type "vim" into the address bar.
 
reading all these posts is very enlightening and humbling. I'm obviously way behind the learning curve. There's someone in this thread with FORTY YEARS of UNIX experience, and I don't know how to use vi. (smh) I have a 1992 copy of the APUE book, so I'm finishing reading that. Maybe in 3-4 years if I work really hard I'll be an elite level programmer.
 
Deleting and moving blocks of text is easy with vi, Vim, and, I assume, with neovim. Here's a slightly shorter, "starter" command guide for the text manipulation operations I seem to use most often:

1. In normal mode:

a. Type ^G (i.e., [CTRL-G]) to see the name of the text file, its row number, and the number of rows in the file.
b. Use the arrow keys to move the cursor one row or character at a time.
c. Type ^D to move down 20 rows, or [PAGE-DOWN] to move down by terminal height (the number of rows defined for your terminal).
d. Type ^U to move up 20 rows, or [PAGE-UP] to move up by the terminal height.
e. Type the double-quote-mark followed by a letter, followed by a lower case number (a number composed of Arabic numerals), to begin a multiple row operation, as follows:
i. Type "X100dd to cut 100 rows of text from the current cursor postion. Note: dd is the command to cut (or delete) rows.
ii. Move the cursor to another row, and, after moving it, type "XP to insert those same rows under the cursor.
iii. Type "Xp with a lower case p to insert those rows below the cursor.
f. Type "X100y to copy (or "yank") 100 rows without also deleting them. Then you can use "Xp or "XP to insert them elsewhere.
g. Type :w to write the edited file back to disc.
h. Type :x to write the file and return to the shell's command prompt.
i. Type :q to return to the shell command prompt without writing.
j. Type :q! to avoid writing an edited file, and return to the shell command prompt.
k. Type :e file2.txt to switch from your current file to another file named file2.txt. Using only this short list of commands, you'll be able to copy and paste text between multiple files from a single text terminal or GUI-based terminal emulator window.

2. Multiple text buffers (also in normal mode- I don't know of any other text editors which will allow multiple text buffers, they all seem to be limited to a single clipboard which handles only one text buffer at a time - although this might be possible with KDE):

a. Type "a100y to yank 100 rows into text buffer a.
b. Type "b200y to yank 200 rows into text buffer b.
c. Type "A1000y to yank 1000 rows into text buffer A. Use similar commands with letters c,d,e, ... z, and B,C,D, ... Z.

There are seemingly endless command variations, which makes vi seem intimidating at first, but you don't have to learn them all, only the ones you use.
 
These are the commands I use most often. They haven't all made it into this thread. By far what I do most often is copy-paste or cut-paste a line
  • dd cut (delete) the current line.
  • yy copy (yank) the current like.
  • p or P (note the capitalization) pastes either before or after the current line. I always forget which is which and wind up trying both.
  • u for undo when I invariably use the wrong paste command.
I also use "go to end of line" all the time. This is shift-4, AKA the dollar ($) sign. Also handy that that's how you specify end-of-line in regexes. Vi commands also take an optional number of operations to perform. For example "3yy" yanks three lines into the clipboard. And of course you should always end with colon-w-q (:wq) for write the current file and quit.
 
For the heck of it, I'll add that dwm and probably some other tiling window managers use vi shortcuts by default, for example in dwm mod1+j moves to the next window. (In vi hitting j moves down a line.) One also uses h to expand the left hand window and l (lower case L) to expand the right, both of those are vi shortcuts.
I'm going to say that a basic knowledge of vi makes a lot of other programs easier. Of course, you may not use any of those programs. :) But I do, and I think a lot of people here also prefer things like mutt and window managers over desktop environments. Not everyone of course, but a reasonable percentage.


I tend to use either dwm or openbox and in openbox I've also set up my shortcuts to mimic vi, for example, super+j moves a window down. Lots of other things mimic vi, off the top of my head, the very useful vimium extension for either Chrome or Firefox, mutt, and so on.

A post a page back mentioned, in response to my saying nano might be the default, that that doesn't hold true on BSD systems. That's true. The only one where I know it to be the case is Debian where nano is the default editor. I don't know about Debian derivatives such as Ubuntu and Mint. But in Debian itself, if you type visudo, it will open the file in nano, not vi. It's easily changed, but it is the defaul.
 
To survive as a developer with some sys admin duties today, you need to know how to use vi (or vim) well enough to do simple modifications to a short file. That's because while installing or maintaining a system, sometime you find yourself in a situation where you have only vi(m) available, and nothing else.

Until a few months ago, I would have said that you also need to know at least one powerful coding editor (text editor) really well; whether that's vim or emacs is not important, as most environments provide both. The reason for that is two-fold: First, sometime you had to work on machines and code bases where only CLI access is available. And GUI-based editors were not good enough to be universally accepted.

However, these days I know there are environments with good GUI-based coding editors, and no need to work via ssh. And when I say "good", I mean: really really good, so good that dozens of very experienced developers prefer to use them over CLI-based tools. Since I've used Unix only for 37 years, I don't know whether I count as "experienced". So today, it is possible to be a serious developer using GUI-based tools only (most of them actually run in web browsers today, that having become the lingua franca of GUI development).

Having said that: Those GUI-based editors still have lots of useful keyboard shortcuts. And the ones I know can all be configured for either emacs or vim mode. So learning one of those editor's user interfaces (keyboard commands) well is going to enhance productivity, even if we are now in a world where there are alternatives to these text-based editors.
 
ralphbsz said:
To survive as a developer with some sys admin duties today, you need to know how to use vi (or vim) well enough to do simple modifications to a short file. That's because while installing or maintaining a system, sometime you find yourself in a situation where you have only vi(m) available, and nothing else.

Until a few months ago, I would have said that you also need to know at least one powerful coding editor (text editor) really well; whether that's vim or emacs is not important, as most environments provide both. The reason for that is two-fold: First, sometime you had to work on machines and code bases where only CLI access is available. And GUI-based editors were not good enough to be universally accepted.

However, these days I know there are environments with good GUI-based coding editors, and no need to work via ssh. And when I say "good", I mean: really really good, so good that dozens of very experienced developers prefer to use them over CLI-based tools. Since I've used Unix only for 37 years, I don't know whether I count as "experienced". So today, it is possible to be a serious developer using GUI-based tools only (most of them actually run in web browsers today, that having become the lingua franca of GUI development).

Having said that: Those GUI-based editors still have lots of useful keyboard shortcuts. And the ones I know can all be configured for either emacs or vim mode. So learning one of those editor's user interfaces (keyboard commands) well is going to enhance productivity, even if we are now in a world where there are alternatives to these text-based editors.
Click to expand...
Your experience is about as long as mine, Mr. Bsz., and a bit more modern, since I retired from the IT biz in 2017. Tinkering with computers is just a hobby for me now.
 
I see that the convention in the vim help system is to use the word "line(s)" instead of "row(s)", so I'll start doing that here, too.

3. Search (and replace) commands:

i. Type :s/foo to search for the first occurrence of the string foo on the current line.
ii. Press n to search for the next occurrence of foo (and the next foo, and the next foo, etc.)
iii. Type :s/foo/bar/& to replace the first occurrence of the string foo with bar on the current line.
iv. Type :s/foo/bar/g to replace all the occurrences of foo with bar on the current line.
v. Type :s/foo/bar/g3 to replace all the occurrences of foo with bar on the next 3 lines, including the line under the cursor (with the cursor positioned on the first column of the line).
vi. Type :s/foo/bar/g900 to replace all the occurrences of foo with bar on the next 900 lines, including the line under the cursor (with the cursor positioned on the first column of the line).

Again we have many other syntax variations available, but these are enough to get me by, and the ones I use.
 
ccammack said:
# save the file and exit
  • press esc to return to normal mode and enter :wq to save and quit or :q! to quit without saving
That might be enough to get you through an emergency.
Click to expand...

Has done, quite a few times!

Good summary thanks, but I've never warmed to it, more an ee / nano / pico / joe user for quick scripting and notetaking, and kwrite for serious programming.

Interesting discussion though.

:q!
 
Whilst I mostly use an IDE for heavy work, I still recommend learning vi. There are always situations when you only have the terminal (in my experience, when the NoMachine servers are misbehaving at work and when KDE doesn't quite want to start at home).
 
The way I learned vi/vim was learning the basics first. Then, when I wanted to do something a little more advanced, I learned that. I didn't concern myself with something I may never use. I built the skill up a little at a time as needed.
 
richardtoohey2 said:
For me I have servers without any GUI installed; I work on client machines with a GUI and a terminal/console and ssh in to the servers and tweak code in vim and refresh the browser on the GUI machine.

Works for me, but there’s plenty of ways to do things!
Click to expand...

Wait.... there's servers with a GUI?
 
To learn Vim, I'd recommend starting with the vimtutor provided with editors/vim to learn the basics. Then just use the program, and learn new features (look 'em up) one every day and use them to make the nodes in your brain.

For reference 'Practical Vim' from Drew Neil is a good book.
For reading and learning 'Mastering Vim Quickly' from Jovica Ilic is great.

Print out a Vim cheatsheet, the one linked here is IMHO the best.

If you just need the basics of vi(1) just use the man page or the attached 1995 sheet.
 

Attachments

  • vi_cheat_sheet.pdf
    61.2 KB · Views: 87
In my opinion; no, not really.

I use micro in the command line and vscode for actual projects. My knowledge of vim begins at entering insert mode and ends at save&exit command. Personally I find editors like vim/emacs to be incredibly cumbersome but knowing how to use them to write in to a file and save it only takes a minute and saves you stress if backed in to a corner and forced to use them configuring a machine.
 
You must log in or register to reply here.
Back
Top