# is "vi" worth learning in 2022?



## chessguy64 (Dec 30, 2022)

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?


----------



## gpw928 (Dec 30, 2022)

I have no desire to master more than one good text editor.

Any application or IDE that requires me to learn a new editor is just another piece of junk software...

I think that the people who use vi generally understand how it works.

But you have to invest the effort to get the reward.

Vi was first.  There are other plausible options.

Emacs has always been bloatware, but not many care about that these days.

Consider sam, favoured by many of the crew from Bell Labs.


----------



## Eric A. Borisch (Dec 30, 2022)

#1 reason: it’s always there. Working on some embedded *nix? It’s there. Repairing a system? It’s in /rescue.

Do you _need_ to master it, or use it as your main editor, no. Should you know how to use it enough to move around in a file, change something, and save? Yes.


----------



## chessguy64 (Dec 30, 2022)

gpw928 said:


> I have no desire to master more than one good text editor.
> 
> Any application or IDE that requires me to learn a new editor is just another piece of junk software...
> 
> ...



So you actually use vi as your main text editor? I mean... most of the time I want a web browser so I'm in X11.. I think vim would be better no ? (more modern, graphical). Are you just in console without X running all the time or what?


----------



## richardtoohey2 (Dec 30, 2022)

Nah, I’d wait until 2023 

Seriously, though, as Eric said it’s a good thing to know the basics at least “just in case.”


----------



## richardtoohey2 (Dec 30, 2022)

chessguy64 said:


> Are you just in console without X running all the time or what?


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!


----------



## _al (Dec 30, 2022)

To make a decision, I would recommend reading "Vi Improved - Vim" (by Steve Oualline).  In my opinion, this is the best book about vim.  There are also many good books ("Learning the vi & Vim Editors" for example).  I've been using vim myself for not too long, since 2011. As a cross-platform editor for a programmer (I write in C, C++ and Perl on Linux, FreeBSD, Windows) , vim is one of the best (I think).


----------



## kodcode (Dec 30, 2022)

I recommend going through `vimtutor`.


----------



## chrbr (Dec 30, 2022)

In my opinion the biggest difference to other editors is the switching between editing and command mode. Once you have got that there is no much difference in the learning curve.


----------



## Alain De Vos (Dec 30, 2022)

I use only two editors neovim & vscode.
Neovim can be highly tweaked. For most programming languages it gives me "completion" & function-hints using an LSP-server (idem for vscode)


----------



## Profighost (Dec 30, 2022)

It's also worth learning it in 2023, 2024,.....

Because it's the *timeless concept* that makes vi-editors so extremely powerful.

I once started with emacs - very good, very powerful, very flexibel, very customizable... but simply not my style.
Geany also is worth a try (and there are others, too.)

But if you want the best:
vi - and it's family

When emacs is the Lamborghini of texteditors - fast and luxurious,
then vi is the Formula-one:
rock-solid, no luxuries at all, but by far the fastest there is.

After I overcame the prophecies of doom and laughter one may confronted with if people hear you want to learn vi,
I bit the bullet,  made the effort one needs to spent before vi can be even remotely useful,
and regretted not done it earlier.

With emacs you are seduced to stick to the GUI.
This is exactly the point which slows you down.
You cannot imagine how much this slows you down unless you flew warp speed.
vi is warp speed.
Because vi forces you to use the keyboard, and the keyboard, only.
That's why I recommend _not to use_ GVim, especially not for the start.
You'll try to use GVim's GUI as you are common to other (emacs-like) editors.
This will not work.
You'll miss the whole point of vi's core concept: use the keyboard, only.
That's where the speed comes from.
You will not learn vi but produce curse words, only, 'cause this sh#t ain't working _like_...

First thing you need to do when start learning vi:
Stop comparing!
Start completely new at zero!

Of course with emacs you may also use keyboard commands.
And you'll better do if you want to use _any_ editor even remoteful efficiently.
But with emacs you'll have to learn hundreds (thousands?) of keystroke combinations.

I like to compare vi and emacs with the comparison of the roman alphabet with graphical symbols.
At first one thinks: 'graphical symbols are so much easier, so much more powerful.
You don't even have to learn to read or write.
With the roman alphabet you have to learn all 26 signs first
and how to combine them to syllables before you can do even anything at all with this shit.'
..we all know the punchline:
that bitch bites back.

I started on pure Vim.
Console, only.
All my textediting I do in console only.
The best way to learn is to use it.
So force yourself to use vi for anything.
And be patient with yourself 

As mentioned by others above, also I recommend:

if you have lots of editing to do, or may in the future: learn vi/Vim/neovim - it will pay in the long term
do the tutorials, the internal one as others you may find on the internet - _you need to practise_
I could also recommend _Learning the vi & Vim Editors_, but soon I will get me a copy of Steve Oualline's _Vi Improved - Vim_ (thanks for the tipp!) (used books don't cost much) you'll learn lots of those
keep a writing book ready with a pen to write down your personal most used commands, to look them up quickly, and you'll leran better/quicker that way
get yourself a couple of cheat-sheets; those are most valuable if you just need to use vi by accident, but also at the start. best practise: write you own cheat-sheet


----------



## covacat (Dec 30, 2022)

there is not enough time left in 2022 to learn vi


----------



## drhowarddrfine (Dec 30, 2022)

If one is working in a professional *nix environment and doesn't know vi*, I will not hire them or at least look at them sideways.



> I think vim would be better no ? (more modern, graphical).



vim is "vi improved". Not necessarily "graphical". You don't need the gui to use vim.


----------



## gpw928 (Dec 30, 2022)

chessguy64 said:


> So you actually use vi as your main text editor? I mean... most of the time I want a web browser so I'm in X11.. I think vim would be better no ? (more modern, graphical). Are you just in console without X running all the time or what?


There are many variants on vi, since AT&T wrested ownership from BSD when they settled the Unix lawsuit with the Regents (I believe that Bill Joy had used the code from `ed` when implementing line editing mode).  It's still distributed with Unix variants originally licensed from AT&T.

Keith Bostic re-implemented a clean copy, distributed with FreeBSD, called nvi.

There are others, most notably editors/vim which comes with Linux.

I have always used vim on Linux and nvi on FreeBSD -- it's the choice of least obstacles -- always available.  My .kshrc, .viminfo, and .vimrc smooth over the differences.

These all work perfectly well on a console, traditional tty, or any modern X11 terminal emulator.


----------



## hardworkingnewbie (Dec 30, 2022)

It's worth learning the basics, because vi as editor is ubiquitous on *NIX like OSes. So if you want to edit config files, you will need to know it because you will surely not use ed to do that, trust me.

Learning more than the basics: you decide. Vi is not for everyone.


----------



## Profighost (Dec 30, 2022)

chessguy64 said:


> think vim would be better no ?


No.
See History of Vim
Vim is console - text only, GVim is GUI.
Vim offers (many) more features as vi, but the basic usage is the same.



chessguy64 said:


> more modern


I don't care about how old things are.
I care about of its usefulness, efficiency.
You also would not ban all tables from your flat just because the concept of those are thousands of years old...



chessguy64 said:


> graphical)



This the whole core point.
GUI have their benefits, no question there.
They seem to be very comfortable on the first look.
And for minor tasks, or graphical jobs (Gimp, CAD, games...) the best.
But within editing texts, _nothing _beats the keyboard.
I even have no filemanager installed anymore,
because with the shell and its tools I am so much quicker.
And for more complex tasks ("rename >100 files within a directory") you need the shell anyway.

You all get into the new year best!


----------



## meine (Dec 30, 2022)

IMHO the best editor is the one you feel most comfortable to work with. Comfort might be there instantly, or after some/serious investment in learning to use the tool.

editors/vim might need some learning in the beginning. vimtutor is a good starter. Just start with the things you need, learn the rest when you're comfortable. vi is the same in it's basic, but the _improved_ version is more refined.

Last week I made a vim-ish cheatsheet for MS Word -- Vim is my favourite editor, but at work it is MS galore. Making that cheatsheet, I discovered the nifty features Vim has for editing, only using keystrokes -- next word, beginning of word, end of word, append, delete, change, searches, etc.

The nifty editing features and use of the keyboard instead of the mouse might be something to base your choice and time investment on.

Maybe this article is of any help on choosing. It also underlines the 'brain structuring' effect of Vim Grammar, a consistency that other programs often lack.


----------



## sko (Dec 30, 2022)

Another fun way to learn basic vim usage is https://vim-adventures.com/


----------



## Ogis (Dec 30, 2022)

O always use edit. Simple and powerful.


----------



## scottro (Dec 30, 2022)

When I took my first IT job, I had already learned pico, sort of nano's forerunner, because we'd used pine as the email client--this was the late 90's  maybe early double oughts.. Anyway, my first week on the job, my boss asked me to edit a file on the main server, which was an AIX machine.  I logged in, probably by telnet to give you an idea of how long ago it was.  I typed pico <filename> and there was no pico. I called my boss and said, There's no pico on the machine. He said, Can't you use vi? Oh, never mind, I'll do it. 
I learned the vi basics that night.
So, as one of the  first answers said, vi is always there. Though these days, I think nano may be too. There's a joke about what happens when a sysadmin logs into a Debian server for the first time, runs visudo, and realizes that nano is the default editor. These days, I wouldn't know what to do in a nano session. Nothing against it, it's just one of those things I haven't done in so long, I've forgotten it.


----------



## chrbr (Dec 30, 2022)

For Geocachers:
This is one of my caches, unfortunately only in German language.
The title is "Vi dieses Mystery entstand". The title in English should be "How this mystery has been created. In the german title it should normally be "wie" but it sounds as "vi". This should be an additional joke.








						Vi dieses Mystery entstand
					

Solve the mystery and then use a smartphone or GPS device to navigate to the solution coordinates. Look for a small hidden container. When you find it, write your name and date in the logbook. If you take something from the container, leave something in exchange. The terrain is 2 and difficulty...




					www.geocaching.com
				




The story is about a most stupid user (the German abbreviation is DAU) who has lost his backups. The evil admin has found them and has hide them somewhere. The GPS coordinates can be resolved by typing lots of vi commands. Geocachers with IT background use a script or macros. Others end up with bloody fingers .

Have fun,
Christoph


----------



## hardworkingnewbie (Dec 30, 2022)

scottro said:


> Though these days, I think nano may be too.


Nano might be a thing on some Linux distributions, on all of the BSDs it is definitely not something which is installed by default.


----------



## cracauer@ (Dec 30, 2022)

Of course it is worth learning, the question is whether there is something more worth your learning time.

If you already know one non-GUI editor well enough then I would say it is more important to learn -say- /bin/sh really well.


----------



## Vull (Dec 30, 2022)

I've used it for over 40 years. It takes maybe an hour to learn to use it adequately, and in 4 hours, you can learn to use it well. You can use it to copy and paste blocks of text between documents without a mouse, or, with a mouse and GUI environment, you can use it to copy and paste between scrollable terminal emulator windows. What could be easier? If you can type, you can use it. It's been built in to the base and made readily available on every OS I've used (except of course, MS-DOS and Windows), from AIX to SCO OpenServer to FreeBSD, and to every flavor of Linux I've ever tried, and even the Macbook. Its command syntax is compatible with sed and many other common utilities in the Unix base. It's very well documented. Vim is just an enhanced version of the same familiar vi software, that uses the same basic easy-to-learn keyboard command set. With Vim's color syntax highlighting, you can find syntax errors in long blocks of structured code that used to take hours for me to find. It's as well worth learning in 2022 as it was in 1982, in my opinion.


----------



## Argentum (Dec 30, 2022)

chessguy64 said:


> 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?


Over years, I have tried many others, but still using `vi` today. It is a matter of taste of course, but *vi* seems timeless...


----------



## Alain De Vos (Dec 30, 2022)

Editing the scheme language racket in the editor neovim,


----------



## ccammack (Dec 30, 2022)

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.


----------



## Alain De Vos (Dec 30, 2022)

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


----------



## Alain De Vos (Dec 30, 2022)

Another tip, copy paste,





						Copy & Paste in Vim / Vi
					






					www.warp.dev


----------



## forquare (Dec 30, 2022)

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.


----------



## chessguy64 (Dec 30, 2022)

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.


----------



## Alain De Vos (Dec 30, 2022)

To start it's not that difficult. You just memorize maybe 10 key-combinations by hart. That's it.
[Like Ctrl-c Ctrl-V on Windows]


----------



## Vull (Dec 30, 2022)

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.


----------



## Jose (Dec 30, 2022)

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.


----------



## scottro (Dec 30, 2022)

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.


----------



## richardtoohey2 (Dec 30, 2022)

Also the pagers e.g. :q to quit a pager like more or less.


----------



## ralphbsz (Dec 30, 2022)

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.


----------



## Vull (Dec 30, 2022)

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.
> 
> ...


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.


----------



## Vull (Dec 31, 2022)

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.


----------



## smithi (Dec 31, 2022)

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.



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!


----------



## fernandel (Dec 31, 2022)

Vi tutor
And I have a book from Linda Lamb and Arnold Robbins 1st edition which help me a lot. But I am using vi just for keep my gray cells active like Poirot said


----------



## Paul Floyd (Dec 31, 2022)

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).


----------



## gkontos (Dec 31, 2022)

You don't need to master vi but you definitely need to know how to use it if you want to be a Unix sys admin


----------



## Crivens (Dec 31, 2022)

Vull said:


> followed by a letter, followed by a lower case number,


<nitpick> please supply an example of upper case numbers, WITHOUT referencing xkcd. </nitpick>


----------



## drhowarddrfine (Dec 31, 2022)

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.


----------



## Ome Ko (Dec 31, 2022)

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!



Wait.... there's servers with a GUI?


----------



## meine (Dec 31, 2022)

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.


----------



## Vull (Dec 31, 2022)

Crivens said:


> <nitpick> please supply an example of upper case numbers, WITHOUT referencing xkcd. </nitpick>


UPPER CASE: I, II, III, IV, ETC. ...
lower case: i, ii, iii, iv, etc. ...


----------



## Jose (Dec 31, 2022)

Ome Ko said:


> Wait.... there's servers with a GUI?











						Windows Server 2022 | Microsoft
					

Increase security, evolve your datacenter, and innovate faster with Microsoft Windows Server, the cloud-ready operating system.



					www.microsoft.com


----------



## rorgoroth (Dec 31, 2022)

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.


----------



## eternal_noob (Dec 31, 2022)

vi isn't a good editor. Unfortunately, people still use it because "it has always been there".

In my opinion, vi and its sources should be put in a museum as an example on how to not write an editor.

There are much better ones to use. nano is such an example.


----------



## _al (Dec 31, 2022)

If _Multi-Edit_ was cross-platform I would use it.  But I need cross-platform editor.  I have tried many cross-platform editors.  One of the best is _fte_.  But in the end, I chose _vim_.  And not because it's always here, but because it does everything that I need to work.


----------



## forquare (Dec 31, 2022)

Crivens said:


> <nitpick> please supply an example of upper case numbers, WITHOUT referencing xkcd. </nitpick>





Vull said:


> UPPER CASE: I, II, III, IV, ETC. ...
> lower case: i, ii, iii, iv, etc. ...








This is what I learnt when I became interested in typography a number of years ago.  
Almost nobody uses lowercase numbers, to the degree that systems such a LaTeX call them "old style numbers".


----------



## gpw928 (Dec 31, 2022)

Technically, "upper case" refers to the lead slugs sorted into the wooden boxes that were physically highest...


----------



## drhowarddrfine (Dec 31, 2022)

I've never understood the fascination with nano. vi/vim is so far advanced compared to it and its DOS like Windows-user interface.


----------



## decuser (Dec 31, 2022)

I heart vi . It's always there and just knowing there are two basic modes - edit and commands and knowing q!/ZZ and :wq and hjkl for directional stuff is much easier than emacs squirrely key combos - is it CTRL-Q-C or CTRL-ESC-X while holding down the A key, I can never keep it straight. That said, I detest nano and it's prolly just laziness on my part - I'm sure it has rational nav keys besides the goofy arrows. vim's fine, but somewhat unnecessary once you get used to canonical vi. ed's ok and vi's built on ed, but it's clunky in its own way. However, for extensive copy and paste - I prefer kedit, kate, whatever editor cinammon comes with, gedit, leafpad, etc. Cutting and pasting in a console based editor is tricky business and hard to remember how to do properly.

edit: I should say marking text for copy paste is tricky... yanking and putting text is drop dead easy nyy and p .


----------



## richardtoohey2 (Dec 31, 2022)

decuser said:


> edit: I should say marking text for copy paste is tricky... yanking and putting text is drop dead easy nyy and p


I use m’a (mark) at the first line and y’a (yank) at the last and then p to paste. But think that’s vim rather than vi.


----------



## eternal_noob (Dec 31, 2022)

drhowarddrfine said:


> I've never understood the fascination with nano.


The striking highlight of this editor is its ease of use and minimal learning curve.

If you need a masters degree in informatics just to use an editor, this raises questions about the usability of said editor.


----------



## richardtoohey2 (Dec 31, 2022)

eternal_noob said:


> The striking highlight of this editor is its ease of use and minimal learning curve.


That’s not what I say when I try and use nano. But YMMV etc and there are plenty of choices so we’re free to use what works for us. Different people have different ways of working and mental models - there is no one true perfect editor. But to answer the OP’s question - knowing a little vi(m) doesn’t hurt. For every day use you might prefer something else.


----------



## drhowarddrfine (Jan 1, 2023)

If one feels learning vim is difficult, I have many more questions.


----------



## eternal_noob (Jan 1, 2023)

Yeah, sure. I would be ashamed if a product of mine would need a thread on Stack Overflow on how to exit it.

UI should be intuitive. It's a matter of quality.


----------



## Holger (Jan 1, 2023)

Once you've learned how to exit Vi, you are much more efficient in doing so than with other editors.


----------



## Vull (Jan 1, 2023)

If I don't know how to get out of a program, I usually try, in this approximate order: ESC, q, quit, exit, \q, \quit, CTRL-C, CTRL-D, CTRL-C 3 more times, out of frustration and an old familiarity with CTRL-C, then :q, then my old pal, the Micro$oft 3-finger salute ([ CTRL ] [ ALT ] [ DEL ]), then CTRL-C out of frustration again, then the power button if it's available to me. If I didn't already know about :q from frequent use of with vi and related *nix-like software, I might ask the question on some forum or another.

Everyone has to start somewhere and I'm glad older people gave me the slack to ask a lot of questions.


----------



## richardtoohey2 (Jan 1, 2023)

eternal_noob said:


> UI should be intuitive. It's a matter of quality.


vi is from 1976. Things were different then. You seem to be judging it by today’s standards. Anyway, my Atari ST is better than your Amiga, etc.


----------



## decuser (Jan 1, 2023)

eternal_noob said:


> The striking highlight of this editor is its ease of use and minimal learning curve.


Ha. 
	
	



```
man vi
```
 ... an editor that won’t let you edit an entire page without littering the screen with key mappings and cruft that are easily discoverable and learned is not easy to use it’s just got training wheels for tots.


----------



## decuser (Jan 1, 2023)

decuser said:


> Ha.
> 
> 
> 
> ...


That said to each their own. I disagree but can totally see how some folks (especially folks growing up with Windows) would like nano/ee/etc.


----------



## ct85711 (Jan 1, 2023)

I would say, even learning the basic commands wouldn't hurt to know and isn't really any difficulty.  Personally, I rarely needed to learn/use much more than write/save, dd to delete/cut, and of course paste and searching.  Sure, vi/vim can be a very powerful tool that I barely scratch the surface of; in the end it is just another tool in the toolbox.  Having the knowledge to comfortably use it, even basic usage is still worthwhile.


----------



## meaw229a (Jan 1, 2023)

Crivens said:


> <nitpick> please supply an example of upper case numbers, WITHOUT referencing xkcd. </nitpick>


whatever²
or the other way round H₂O


----------



## meaw229a (Jan 1, 2023)

I have basic knowledge about VI. Well enough to edit config files in case I have to. I think basic knowledge about VI is a must on
any *nix system and the good thing is, it's always there when you need it most.

However I do not want to write a book with it or some program code. For that there are better tools out there.


----------



## Minbari (Jan 1, 2023)

Vi is universal.
Learning the vi and Vim Editors


----------



## fjdlr (Jan 1, 2023)

I'm using ee editor on console, (user and root), vi is fascinating and needs far too much effort to master it completely
Happy year to all of you since the France


----------



## drhowarddrfine (Jan 1, 2023)

eternal_noob said:


> I would be ashamed if a product of mine would need a thread on Stack Overflow on how to exit it.


I would be ashamed that I couldn't figure out the documentation or use Google that clearly states how to quit vi. This is child's play. I've read things online about the inability of some to quit vi and it's the most ludicrous thing I've ever read.

How do such people even start vi when they can't even quit. For that matter, how did they ever install or turn their computer on in the first place?


----------



## scottro (Jan 1, 2023)

Sigh, stop being so grumpy.   Haven't you seen everyone's first vi session? Let me find it, don't go away. Ah, here it is.


			QDB: Quote #795779
		


I think I mentioned the other joke earlier, but I can't find it online. Something to the effect of ssh-ing into a Debian machine, running vi sudo and finding yourself in nano.  I guess Debian feels very tied to Gnu which is why they've made it default.


----------



## eternal_noob (Jan 1, 2023)

richardtoohey2 said:


> You seem to be judging it by today’s standards.


Yes, of course. Because i want to use software today, not half a decade ago.

I agree that vi WAS a good editor back in the days, but by today's standards it isn't any more.

People really should stop living in the past.


----------



## decuser (Jan 1, 2023)

Back to the original question. vi is worth leaning because it is ubiquitous. It’s not simple, but it’s consistent and nearly always present. It’s unbelievably fast, even with unbelievably large files. 

People who dis it because it has been around are naive, if not ignorant. It is very powerful and sophisticated - much more so than most fancy looking or modern editors. The UI appears antiquated, compared with this other editors, not through apathy or entropy, but by choice related to the vast number of users who know it and love it as it works today. Whereas some projects could care less about backward compatibility this is not the case with vi/vim, thankfully. What newbs and casual users often fail to grasp about vi is that it works. Period. Not that it kinda works, does some of the stuff right, some of the time. If you take the time to learn it, it can do practically any editing task that’s possible (I say this with the expectation that there may exist some capability it lacks that I don’t know about, but so far as I know it’ll do anything)!


----------



## meine (Jan 1, 2023)

blimey, I only see this now...

"_is "vi" worth learning in 2022?_" asked on 30 december.

In my experience just two days is a bit short to learn vi or vim well enough. You might consider practicing during 2023 as well.


----------



## Vull (Jan 1, 2023)

meine said:


> blimey, I only see this now...
> 
> "_is "vi" worth learning in 2022?_" asked on 30 december.
> 
> In my experience just two days is a bit short to learn vi or vim well enough. You might consider practicing during 2023 as well.


I've been using vi since the early 1980s and am still learning new things about it, even today. It includes a veritable cornucopia of editing features.


----------



## Jose (Jan 1, 2023)

eternal_noob said:


> Yeah, sure. I would be ashamed if a product of mine would need a thread on Stack Overflow on how to exit it.
> 
> UI should be intuitive. It's a matter of quality.


What a great answer to that thread!








						How do I exit Vim?
					

I am stuck and cannot escape. It says: type :quit<Enter> to quit VIM  But when I type that it simply appears in the object body.




					stackoverflow.com
				




I never though of explaining vi's modes as a state machine, it works really well. See vi is "helping" you learn state machines. They're important in several areas of computer science.


----------



## Jose (Jan 1, 2023)

scottro said:


> Sigh, stop being so grumpy.   Haven't you seen everyone's first vi session? Let me find it, don't go away. Ah, here it is.
> 
> 
> QDB: Quote #795779


Have you ever heard the one about Vi has two modes? Edit mode and beep mode. Beep mode is super fun if the machine you're on is configured to use a visual bell. Debian used to be configured that way. I dunno if it still is.


----------



## Vull (Jan 1, 2023)

4. Using shell scripts and environment variables to define long filenames which you use most frequently (here we assume use of sh or bash as your default shell interpreter language):

i. Prepare a short shell script to define any number of long filenames and/or pathnames which you edit most frequently:
	
	



```
$ export b=$HOME/bin; mkdir $b; export PATH=$PATH:$b
$ fd=$b/filename-definitions; touch $fd; chmod +x $fd; vi $fd
```
ii. Press *i* (for insert) in vi in order to insert the following lines in /home/user1/bin/filename-definitions:
	
	



```
b=$HOME/bin
h=/usr/local/etc/apache24/httpd.conf
wd=/usr/local/my-web-application-directory-name
f1=my-textfile1.txt; f2=my-textfile2.txt; f3=my-textfile3.txt
s1=my-script-1; s2=my-script-2; s3=my-script3
export h wd f1 f2 f3 s1 s2 s3
```
iii. Press ESC followed by :x to return to normal mode, write the file, and return to the shell prompt:
	
	



```
ESC
:x
```
iv. Edit your shell profile to make this all work automatically in the future:
a. Enter *cd; pwd* to verify that your present working directory is your home directory:
	
	



```
cd; pwd
```
b. Enter *vi .shrc* (or *vi .bashrc*) to edit your profile file:
	
	



```
vi .shrc
```
c. Press *G* to position the cursor on the last line of the profile:
	
	



```
G
```
d. Press *o* to enter insert mode after the last line:
	
	



```
o
```
e. Enter the following line to invoke the /home/user1/bin/filename-definitions script every time you login in the future (don't forget the period and space before the command:
	
	



```
. bin/filename-definitions
```
f. Press *ESC* followed by *:x* to write your changes into .shrc (or .bashrc):
	
	



```
ESC
:x
```
g. Log out and log in again.
h. Start the new login session by, for example, editing the /home/user1/my-textfile1.txt file using the environment variable *$f1*:
	
	



```
vi $f1
```
i. To edit /home/user1/my-textfilel2.txt:
	
	



```
vi $f2
```
j. You don't need to return to the shell prompt every time you start editing a new file. Because you have exported your environment variables, you can now enter them from *vi*'s *:* prompt:
	
	



```
:e $f3
```

As you add additional files to your developing project, create new environment variables for each file, and add it to /home/user1/bin/filename-definitions.


----------



## ayleid96 (Jan 2, 2023)

chessguy64 said:


> 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?


Traditional editors(vi/emacs) have their own benefits. But learning pure vi is waste of time unless you want vim.


----------



## richardtoohey2 (Jan 2, 2023)

ayleid96 said:


> But learning pure vi is waste of time unless you want vim.


Unless you work with Unix-like systems where you may have to work with a machine without a full-blown modem editor.

It hasn’t happened to me *that* often but it’s been worth having vi-knowledge in my mental toolbox. And probably getting less likely by the day.

If you’re just looking after a machine or two of your own then probably not much point (but you’d possibly get stuck in a pager wondering how to search or quit).

Probably getting to the point you should try it and see.  If your eyeballs start to bleed then stop. That’s what happens when I try and understand “ed”.


----------



## freebuser (Jan 2, 2023)

ccammack said:


> # _insert_ mode
> 
> vi will display --INSERT-- in the bottom left corner when you are in _insert_ mode



Good info, thanks for posting.

I have used the arrow keys and i for editing and :wq and :q! for saving. So many time ended up getting a capital letter when I pressed del and sometime for unknow reasons multiple copies of the letter I wanted to delete.

When I enter the insert mode, there is no --INSERT-- at the bottom left (over SSH console)? is this related to FreeBSD vi too? not even sure if there are different versions (GNU etc.)


----------



## rsronin (Jan 2, 2023)

Vull said:


> 4. Using shell scripts and environment variables to define long filenames which you use most frequently (here we assume use of sh or bash as your default shell interpreter language):
> 
> i. Prepare a short shell script to define any number of long filenames and/or pathnames which you edit most frequently:
> 
> ...


I am using aliases instead:



Spoiler: vim aliases



`v='/home/amw/.config/vifm/scripts/vifmrun .'
v3='vim /home/amw/.config/i3/config'
vX='vim /home/amw/.Xresources'
va='vim /home/amw/.config/i3/app-icons.json'
vab='vim /home/amw/bin/autostart-bspwm.sh'
val='vim /home/amw/.config/alacritty/alacritty.yml'
vb='vim /home/amw/.config/bspwm/bspwmrc'
vba='vim ~/.bash_aliases'
vc='vim /home/amw/.config/conky/conky.conf'
vcolors='cd ~/.vim/plugged/vim-colorschemes/colors'
vf='vim /home/amw/.config/vifm/vifmrc'
vk='vim /home/amw/.config/kitty/kitty.conf'
vl='vim /home/amw/.config/lilyterm/default.conf'
vp='vim /home/amw/.config/polybar/config'
vs='vim /home/amw/.config/sakura/sakura.conf'
vswm='vim /home/amw/.config/spectrwm/spectrwm.conf'
vsx='vim /home/amw/.config/sxhkd/sxhkdrc'
vthemes='cd ~/.vim/plugged/vim-airline-themes/autoload/airline/themes'
vv='vim /home/amw/.vimrc'
vx='vim /home/amw/.xinitrc'
vxs='vim /home/amw/.xsettingsd'
vz='vim /home/amw/.zshrc'`


----------



## Profighost (Jan 2, 2023)

eternal_noob said:


> vi isn't a good editor. Unfortunately, people still use it because "it has always been there".


Sorry, but in this point I disagree with you.

You name all the points of someone who fumbled around a bit with vi,
presumbly when being forced to used it (while under stress within a emergency situation [Linux]),
cursed loudly and a lot (I felt the same way many times)
...decided to hate it,
and that's it.
But never really got past the hurdle,
grasped its true concept.
I bet if you did you'd talk otherwise.

Okay, vi needs two things to get through to it:

DON'T _compare_ vi with any editor you've learned before. Start fresh all over as you never used any texteditor before.
Practise. You'll need at least a couple of hours, biting bullets (cursing is permitted [see 1.] as using backspace and cursorkeys (Vim and neovim) for the beginning. Don't stick too strictly to the tutorials! Use ZZ to leave the editor, not :wq
A Formula-one is no mobility scooter.
Even as an experienced driver you have to practise.

And of course, it's absolutely up to you, to rate if it's worth the effort.
Only you knew the amount of textediting you have to do.
Learning vi only pays off in the long term for someone really doing large amounts of textediting.
For anybody doing just smaller or medium amounts of textediting I wouldn't recommend to learn vi.

Under some commercial Unix or Linux have a cheat-sheet ready, because vi may be the only editor available in some situations your system doesn't fully boot.
Within FreeBSD you don't need on.
Under FreeBSD vi is always available, but by system's default settings FreeBSD's basic editor such as for emergencies is ee ("Easy Editor")
It's small (and slow), but self explaining by having the help always online.
It's good for small editing tasks like commenting a line within /boot/loader.conf that prevents your system from fully boot, and you don't know vi 

Btw:
having the handbook/help/command's explanations always visible is very helpful, but neither intuitive nor efficient.



eternal_noob said:


> I would be ashamed if a product of mine would need a thread on Stack Overflow on how to exit it.


An old vi joke:
"How to produce a  random file?"
"Set someone who never used it before infront of vi and ask him to leave the editor."

ZZ - don't need a thread for that.

When unsure hit Esc - that always brings you back in editing/command mode.



eternal_noob said:


> UI should be intuitive.


It is.

Don't confuse things.
Intuitive means how to create new things by successfully guessing and combining things you've already learned,
and not "avoid learning."
Once you grasped the concept of vi - and yes, you need some training to do so - *vi is very intuitive and very logical* structured.
That's why I told the example with the romans alphabet.
If you do not know the signs and how to combine them to words, it's just chaotic rubbish to you, seems to be the total opposite of intuitve.
But once you know all 26 letters and learned to combine them you can write anything with them - very intuitive.

The *core problem most people have with vi is the two modes of editing and entering text are seperated*,
while within other editors they are always avaible at the same time.
The reason is:
Most of the time you're doing more editing than entering text.
That's why vi starts in editing mode.
Starting in textenter mode would make sense, if the most tasks someone does were producing new files.
(You see: vi is finetuned to spare even the lessest superflous single keystroke.)

While in *texteditors with both modes combined* (most) the editor has to distinguish between text and command.
That's why commands usually done by combining special keys with other keys.
You also have to learn those. Otherwise you stick with GUI's menus, making mouse-kilometers, which is editing at snail's speed. 
And even if your learned those, in all other texteditors I know you cannot guess commands or combine those - you just depend on pure rote learning.
That's not intuitive.

When you have a *seperate editing mode*, you don't have to distinguish every single time.
Then single keys become commands.
That's much less typing, thus speeding up the process significantly.
They can easily be combined to create whole command-chains.
This way you don't have to check your long list of rote learned editing commands, their according keystrokes, and how to do them in which order to reach the editing task.
You "program" your own editing command for the very editing job you're currently want to do every time _tailored exactly to the point_.

Of course, I admit,
this requires thinking while editing,
and doing a bit math in your head is also very helpful.
(I recommend to have line numbering activated by default.)
But if you have no problem with mental arithmetics,
and willing to bite bullet,
once grasp and loved Vim's and neovim's concept of registers and macros you will agree:

Vi is not outdated.
Its concept is timeless, and almost ingeniuos (at least for people who prefer thinking above rote learning )
Vi is very powerful.
Vi is very intuitive.
Vi is very efficient.
Vi is editing at max-speed.

You may say:"I don't like vi", "it's complicated to learn", "its usage is strange/very special - nothing for everybody" or "to me vi is no useful", even "it may not worth learning" (depends) 
but you cannot say "vi is outdated" or "bad."
Because that's simply not true.


----------



## gpw928 (Jan 2, 2023)

I have spent a lot of time in the vicinity of people who work with and on Unix.

To use vi(1) effectively, you have to be able to use ex(1), or ed(1).  You also have to have a reasonable grasp of regular expressions.  None of these skills are trivial.  Happily, they are not requisite for the most casual of use.

But, vi is not truly rewarding to use without some practice and commitment.  Neither is Unix...  and most of us would not be here unless we already understood that...


----------



## scottro (Jan 2, 2023)

I don't think I've seen in this thread, another useful shortcut for commonly typed things. For example, I've been going through a shellscripting book that uses bash. As, in FreeBSD, I'd have to type #!/usr/local/bin/bash or #!/usr/bin/env bash for each script. I have in $HOME/.nexrc (for FreeBSD's included nvi--if you prefer vim you can make a $HOME/.vimrc), 

```
abbr rbash /usr/bin/env bash
```
I chose rbash at random, I don't remember how I chose rbash instead of something else. I have a few other standard things like a shortcut to turn on numbering and another to turn on spell check. I think this thread has evolved into little vi/vim tips which, to me, is a good thing because there's always something to be learned. 
By the way, as we've mentioned Ed, and I'm a big Michael Lucas book fan, he has a book on Ed, available for only $4.99. (And no, I don't get a referral fee. This is an unsolicited fan blurb.)  








						Ed Mastery
					

New for 1 April! Let me be perfectly clear: ed(1) is the standard Unix text editor. If you don’t know ed, you’re not a sysadmin. You’re a mere dabbler. A dilettante. Deficient. Forty years af…




					www.tiltedwindmillpress.com


----------



## bqv (Thursday at 4:21 AM)

I always think of vi not as a program, but as a protocol, for the interface between my fingers and some text. That in mind, it's timeless and essential learning - e.g. you may find neovim more palatable, but you'll find vi on any unix, and it's close enough


----------



## Crivens (Thursday at 4:58 PM)

Can we summarize all this thread with this quote? 



_View: https://www.youtube.com/watch?v=pGxyOeypYFs&t=45_


----------



## kpedersen (Thursday at 5:37 PM)

Vull said:


> I've been using vi since the early 1980s and am still learning new things about it, even today. It includes a veritable cornucopia of editing features.


I find this a good example. Can anyone name another text editor from ~1980 still in common use? How about early 2000s?

From this I can project that in another 40 years (~2060), *vi* will still be known and all current "modern" "trendy" text editors will have disappeared into obscurity. VSCode will become the new E. Notepad++ will become the new RHIDE. Etc.

The Lindy effect is real!


----------



## freezr (Thursday at 6:08 PM)

My problem with `VI(M)` is that has always appeared on my way in any panic situation I have had so far! 

Is unavoidable building a bad relationship with it, personally my default editor is Micro...


----------



## leebrown66 (Thursday at 7:12 PM)

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.


----------



## Sergei_Shablovsky (Thursday at 8:46 PM)

Hi! Let me put my 5cents in this thread:

1.
HUMAN PSYCHOLOGY
Human's psychology and neurobiology determine that well known things looks like BETTER for us. And of course, we will find A LOT of arguments why.
This mean “If You start from vi, using vi several years, 99,999% that any other editor would be refused”

2.
Suggesting “good old tool” from 80' for newcomers of 2020’ - is a stupid things.
*Because (and this is logical) FreeBSD newcomers seek for productive and usable tool with well known features like:
- hotkeys are intuitive (the same 'traditional' Ctrl-C, Ctrl-V, Ctrl-X, Ctrl-Z...)
- Syntax highlighting
- screen split between 2-4 files or the parts of same code file
- spellcheck for most common programming languages & config file formats
- useful find/replace and copy/paste
- useful comment/uncomment for blocks of code
- several clipboards
- cursor position, file coding format (ascii, utf-8, etc...)
This is just “must have” for ANY code editor or IDEs nowadays. *

Most of this concepts / features not exist (and not asked for) many years ago. But this not mean You need to be sticky to “old great tool” that born 100 years ago!

In 2022 shells/zsh (+ shells/zsh-autosuggestions, shells/zsh-syntax-highlighting, shells/ohmyzsh) in conjunction with misc/mc and editors/nano (or editors/micro) pretending to be great toolset.

looks like more flexible, powerful, easy to switch on, and with a ton of features if You wish...


----------



## 6502 (Yesterday at 9:44 PM)

Most important hotkey of *vi* is how to exit 

I prefer *nano* (in Linux there is *pico* which is similar).


----------



## scottro (Today at 12:57 PM)

I suspect that most Linux distributions have nano, not pico. Pico is part of the pine (now alpine) email program. Debian Linux, for example, has nano as its default editor. For example, if working on a Debian system, if you type in visudo, the /etc/sudoers comes up in nano, not vi or vim. (This can be easily changes with alternatives, a Linux program to reset things like editors).


----------



## covacat (Today at 1:09 PM)

people who find vi hard should check out teco


----------



## drhowarddrfine (Today at 1:12 PM)

covacat said:


> people who find vi hard should check out teco


People who find vi hard should check out another occupation or hobby.


----------



## 6502 (Today at 2:10 PM)

drhowarddrfine said:


> People who find vi hard should check out another occupation or hobby.


Why I have to remember non-standard shortcuts "invented" 40+ years ago?


----------



## chrbr (Today at 2:53 PM)

6502 said:


> Why I have to remember non-standard shortcuts "invented" 40+ years ago?


There is no difference in learning shortcuts for vi, emacs, nano or other editors or applications. They make the handling of the tools fast and efficient. The vi, emacs and wordstar shortcuts are different but all are almost standards. They will survive all of us.


----------



## 6502 (Today at 3:24 PM)

If *vi* is the only text editor, I will remember its keys. But there is choice and I have to run it once per 2-3 years. Sorry but I forget the "menu" key every time.


----------



## chrbr (Today at 3:46 PM)

6502 said:


> 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 (Today at 3:47 PM)

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 (Today at 6:09 PM)

6502 said:


> I forget the "menu" key every time.


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


----------



## ralphbsz (45 minutes ago)

chrbr said:


> 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 (31 minutes ago)

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.


----------

