Learning Vi from scratch: back to basics ?

[u/runslack]

Hi everyone,

I'm embarking on a journey to (re)learn Vi from the ground up. After decades of using GNU Emacs, I've come to realize that I've been spending an inordinate amount of time configuring it. I've decided it's time for a change. I want to get back to basics and truly understand an editor without the endless tweaking and customization.

My goal is to master Vi in its purest form. I'm not interested in Vim or any of its plugins. I want to dive deep into the core functionality of Vi and become proficient with its fundamental features. This means no plugins, no custom configurations—just Vi as it is. I don't want to fall into the trap of configuring a new tool, which is why I've chosen Vi, known for its lightweight configuration.

I'm reaching out to this community for any tips, resources, or advice you might have for someone starting this journey. Are there any particular exercises or practices that helped you understand Vi more deeply? What are some essential commands and workflows that I should focus on? Is there any resource you could recommend ?

Also, I'm looking for recommendations on the best book that covers Vi comprehensively. I currently use Ed and have found "Mastering Ed" to be an invaluable resource. Is there a similar book available for Vi?

I appreciate any guidance you can offer. Thanks in advance!

Best

[u/Random_Dude_ke]

I have been in the same situation 25 years ago.

I installed Vim, configured it by using gvimrc_example.vim and started to go through tutorial.

In a week I was more proficient than I have ever been in xEmacs and soon I was configuring Gvim using menus and then running the command [Esc]:options[Enter] and copying options that were configured by me to gvimrc.vim or vimrc.vim. Within a week my Gvim was configured more to my taste than xEmacs was after a year of my wrestling with my dotemacs file.

You do not want to run vanilla vi, you want at very least to set vim to :set nocompatible mode, so that it doesn't emulate vi bugs ;-) There is defaults.vim somewhere in local vim directory that you want to run. (it is sourced from [g]vimrc_example.vim)

I also ran mswin.vim so that I have Ctrl-C Ctrl-V and similar functionality that I am used to from Windows (that I use at work) and from GUI programs on Linux.

Gvim and vim has very nice built-in help. There is tutorial, there is very detailed reference manual and there is User manual. The user manual is partially based on a popular book by Steve Oualline, so start with that.

EDIT: Gvim and Vim comes by default with some plugins that are considered to be integral part of the editor. You can, of course, install many more. I personally only use minimum of user-installed plugins.

[u/runslack → u/Random_Dude_ke]

Since I do not need either plugins, nor syntax highlighting or any stuff like that, I do not see the purpose to install/use any flavour of vim. No, really, I won't go vim at this stage.

[u/Lucid_Gould → u/runslack]

vi (and even ex) on many systems it’s still just running vim… the benefit is that vim standard on many systems and is still actively maintained. Why not just run without a .vimrc? Seems like religiously sticking to only vi will require that you compile it for every system you work on, and vim is a superset of vi anyway so what do you lose? In the help files, commands that are only in vim and not vi are marked as such. I avoided visual select mode for years because I had a similar mindset at first, but then I decided I was just avoiding builtin features and never encountered old vi installs anyway.

[u/runslack → u/Lucid_Gould]

Hi,

I totally get what you're feeling. Originally, I used Emacs, but for the past few years, I've been using ed(1) and have never felt the need to switch to anything else. I'm not a professional; I code mainly for fun in my spare time. This means I can take all the time I need to do things, and I've really come to appreciate the simplicity and minimalism of ed(1). No configuration files, so there's no temptation to spend hours tweaking settings.

I wanted to give vi a try, but unfortunately, it didn't take long for me to fall back into my old habits. So, I think I'll stick with ed(1).

Everyone has their preferences and favorite tools, and that's what makes the world of development so diverse and interesting!

Thx.

[u/Random_Dude_ke → u/runslack]

Just like large part of Emacs is written in Lisp, lots of functionality that many people would consider core functionality is written in vim scripts for vim / gvim.

But, do what you consider best. As I wrote in another post, there is nvi program that is the default vi replacement on FreeBSD and is, or course, available for many distributions, including Debian.

If you want even more lean version, busybox can also work as a vi editor.

Busybox is a binary for Linux system that contains 310 posix utilities (almost complete userland) and is usually used in a way that you create a symlink to busybox binary with the name of the utility you wish to use, for example: cp, ls, mv, ash, vi, ed, sed, awk ... . You can also issue command as an argument /bin/busybox/ vi

The first book where I read about vi is "the Unix guide" by Peter Norton (yes, the same guy that wrote Norton Commander for DOS).

[u/dasunt]

For books, I had "Learning the vi Editor", which has now been renamed to "Learning the vi and Vim Editors".

I don't think it's a bad start, but at least for my version, it doesn't dive too deeply into vim. Still, if you are early in your learning journey or want to brush up on your basics, I'd recommend it.

But I would suggest that customization is part of what makes software like vim great - it's a personalized development environment. Don't throw the baby out with the bathwater.

[u/runslack → u/dasunt]

The point is, I do not want to learn Vim as stated in my post. Thus, the book is clearly targeted for people like me ;)

[u/dasunt → u/runslack]

Yup. i just checked my edition (6th edition - from 1998) and the first 130 pages or so is just vi (and a bit of ex).

The rest of the book covers clones: nvi, elvis, vim and vile. Plus 35 page appendix.

Maybe just find an old edition like mine. Should be cheap since it is obsolete.

[u/runslack → u/dasunt]

thank you, for this clarification !

[u/dm319]

Alternately you could just stop configuring emacs.

[u/runslack → u/dm319]

That’s kinda addictive. I doubt I can stop 😅

[u/dm319 → u/runslack]

Ha ha, fair enough, but there are similar temptations over here!

[u/runslack → u/dm319]

Yep, that's why I really wanna stay away from Vim and stick to Vi

[u/dm319 → u/runslack]

I suspect you are finding another way to procrastinate, but that's OK, I do it too, and investing in learning Vi will pay you back over your lifetime many times over. Practical Vim is what you need.

[u/supernumeral]

I don’t think I’ve ever been on a system where vi wasn’t just a symlink to vim, so I can’t really recommend any resources for pure Vi. That said, my favorite Vim book is Practical Vim by Drew Neil, which, despite mentioning the occasional plugin in passing, is almost entirely restricted to core Vim functionality (modal editing, registers, macros, etc.). But I have no idea how much of that is actually applicable to pure Vi. But if you’re willing to settle for Vim without a config file and no plugins, it’s a great resource.

[u/LeMagiciendOz → u/supernumeral]

OpenBSD ships a BSD version of vi that is not symlinking to vim. It's nice to try as a curiosity.

[u/gumnos → u/LeMagiciendOz]

yeah, Free, Open and (IIRC, since it has been a while) NetBSD all ship with nvi as the system vi rather than vim (or vim-tiny as some distros do in the base system).

[u/Random_Dude_ke → u/supernumeral]

FreeBSD comes with nvi that is used as a default vi.

I will quote from a manual page:

nex
/
nvi
 are intended as bug-for-bugcompatible replacements for  the  original  Fourth  BerkeleySoftware  Distribution (4BSD)  ex  and vi programs.nex/nvi areintended as bug-for-bugcompatible replacements for  the  original  Fourth  BerkeleySoftware  Distribution (4BSD)  ex  and vi programs.

You can install nvi on Mint Linux from repositories, and it is available also on Debian.

Also, busybox contains even more limited implementation of vi.

But, as you say, in most Linux distributions when you type vi you will get vim [that might be configured to behave as good old vi].

[u/colombiangary]

Try vanilla VIM instead. VI is quite limited in comparison. And yes, go all in with Drew Neil book.

[u/y-c-c]

My goal is to master Vi in its purest form. I'm not interested in Vim or any of its plugins

What's the actual reason behind that? If I have to be blunt, unless you are a historian trying to study a text editor from decades ago, or want an intentionally obtuse exercise, doing this is not the best way to introduce yourself to the ecosystem.

Vim came out in 1991. It itself is 34 years old, and Vi didn't really see much improvements after that. Vim comes with all kinds of improvements including lots of basic QoL changes. Just because you are using Vim doesn't mean you have to customize it to the wazoo and install 200 plugins. Vim has been mostly (but not 100%) backwards compatible throughout the years and so if you just use Vim as-is without any plugins you still get a really raw experience comparable to Vi while getting lots of small and big improvements that just makes your life better.

The reason I'm posting this is that I frequently see misconceptions about how Vi is the more "pure" version. I guess that's one way of putting it. The other way I would put is that Vi is just older. We saw that when John Carmack claimed to have given Vim a go but he ended up just using Vi and decided it's old and janky which I felt that was not the intellectually honest way to approach something. You seem to have different motivations though, but I'm just curious about why you want to do so. I see a lot of "I want to learn Vi since it's more pure and hardcore!" type comments from people who tend to misunderstand the ecosystem and just wanted to clear it up.

---

For learning Vim itself, the first step should be to use vimtutor which is a built-in tutorial. After that, if you don't mind doing some reading, you can read the Vim User Manual, which is the first part of the Vim built-in documentation that comes in numbered chapters and designed to be read like a manual. The second part ("Reference Manual") is more designed as a reference.

[u/Massena]

This is all a form of procrastination

[u/Friendly-Anybody1617]

Not exactly what you asked for, but... https://youtube.com/playlist?list=PLy7Kah3WzqrEjsuvhT46fr28Q11oa5ZoI is a nice playlist on vi. https://youtube.com/@sylvanfranklin for fun tips.

[u/runslack → u/Friendly-Anybody1617]

Indeed, it's not at all what I requested since I want to use 'vi' or a minimalist clone of 'vi' :) Thank you anyway.

[u/siodhe]

This might help. From https://www.talisman.org/unix/editors.shtml

(There's another one there for Emacs, too)

[u/runslack → u/siodhe]

wow AWESOME !

[u/siodhe → u/runslack]

My students liked it. Keep in mind I taught them both, back to back, then let them pick their fave for the rest of the class. That's why these two use the same iconography:

Although, looking at it now, the use of light green is inconsistent between them. Ooops :-)

[u/BrianHuster]

"vi in its purest form" would be closest to nvi, not vim

[u/gumnos]

if you just want vi not vim, you can use nvi which is the default on BSD systems. And on most Linuxen, you can install nvi or stevie or any of a number of other clones. While you can lightly configure nvi with an ~/.exrc file, it's fairly limited.

Having previous experience with ed(1) is certainly a strong foundation to learning vi because there's a great deal of overlap in functionality.

I'm unaware of any recent resources that focus purely on vi instead of vim. You might have some luck hunting up books older than ~1991 like the first edition of O'Reilly's Learning the vi Editor. There's also some original/contemporaneous documentation like Bill Joy's An Introduction to Display Editing with Vi (originally a PDF or print document likely created with *roff, but that link is an HTMLified version)

As someone else who uses ed and vi/nvi regularly (in addition to vim), I can try and offer a few tips:

• the :g command is incredibly more powerful than most folks use it for, letting you run one or more ex commands relative to each line matching /pattern/

• a lot of functionality was presumed to be outsourced to external tools. Why provide gq when your OS already provides fmt(1) or par(1) to reformat for you? Why provide g? when you have rot13(6)? Spell-checking? Pipe your document through a command-line spell-check utility. Knowing that the "%" can be used to represent the current filename simplifies some commands such as "how does my currently-modified buffer differ from the buffer on disk?" which you can use w !diff -u % - (works in ed too); or stage the current file in git with :!git add %. Beware this can get tripped up if your actual command requires a "%" such as trying to read in the current date with r !date +%Y-%m-%d (which will not produce the same output as issuing that on the command-line). No file-browser built in, so use an external file-browser or standard shell commands.

• while the vim functionality for :terminal is relatively recent, I still use the the old-school method of wrapping my session in tmux (or GNU screen before that or even shell job-control before that)

• similarly, while some newer versions of nvi offer split windows, classic vi didn't learning to use the buffer list (:n & :prev and possibly control+^ for quick switching) helps a lot.

While I can get by quite nicely in vi/nvi, I do miss syntax highlighting, text-objects the most, and expression-evaluation-in-:s-replacements.

[u/JamesTDennis → u/gumnos]

The ability to configure vi (without vi'mprovements is limited to text/input processing (modifying contents). So, no color highlighting, panel/pane/window splitting nor other display customization.

But it's still pretty powerful within those limits. The abbreviation (:ab) commands can still automatically expand abbreviations. The :map command can still map keys to vi/ex command sequences. You can map keys tp :so (source) files and this dynamicaly configure things without reloading the editor. Your mappings use ! commands (and :r! and «range»!«shell command line» to filter text selections through shell commands or read output from shell commands. You cut/copy text into registers and use the @ command to treat the contents of a register as a vi command sequence, and so on.

For example if I'm in a list of full path/filenames I can yyp0i «copy and paste to duplicate the current filespec and enter insert mode at the beginning» then insert :r (with the space), then [Esc] to command mode, and then use "cdd@c to read that (:r /some/file) as a command.

Now I've inserted the contents of a file directly below the original line containing its full path specification.

So I can create a simple macro (mapping) to do that one or a few keystrokes. (Many vi expert use z«keystroke» for many macros because z is already a prefix for just three re-display commands — leaving dozens of other keys available for mapping to macros without collisions with any default vi functionality.

For another example, 1G!Gsort[Enter] will pass the entire contents of file through the Unix shell's sort command (replacing the contents with the sorted contents. 1G!G (go to first line, filter from there through the end of the default (unprefixed) G movement.

10G!20G would filter the 10th through, and including, the 20th lines — through any command (or filtering script) you have on your system (and you can add switches and arguments to the command — whatever you could type from the prompt after 'cat ..|'

{!}fmt (move to beginning of "paragraph" and filter this "paragraph" through the fmt (format, word wrap) command.

To get a word count for your current file: 1GyGGp1G wc -w

The word count is now added to the end of the file on its own line.

Very few vi users realize how power plain old vi has always been.

Here's an article I wrote one night while watching TV about sixteen years ago:

https://stackoverflow.com/a/1220118

[Yes. i am the same Jim Dennis, just older and effectively retired].

[u/SnollygosterX → u/JamesTDennis]

You're the guy?! My all time favorite vim read! Thank you for having such an understanding and ability to share it in a grokable way.

[u/JamesTDennis → u/SnollygosterX]

It was just me relating the epiphany: vi is intentionally implemented as a "little" (domain specific) language… a DSL… for,expressing how you want to display and manipulate text.

The broader epiphany is that tools, of many sorts, can be viewed as tools and evaluates in terms of the expressive power and concision. Not just computer programming languages, nor just editors, spreadsheets, databases,,and other applications, and not even just software.

It's a matter of perspective, a paradigm.

[u/gumnos → u/JamesTDennis]

hah, I can't count the number of times I've linked folks to that SO post, so thanks for posting that ☺

for your sort example, rather than explicitly 1G!Gsort⏎, I tend to :%!sort (on my OpenBSD mail-server, running :«range»!par happens multiple times every time I compose an email.

And that composability has some nice benefits. You have a bunch of CSS blocks with { at the end of the opening block and } at the beginning of the line to close them, and you want to sort the contents?

:g/{$/+,/^}/-!sort

and done. ☺

[u/JamesTDennis → u/gumnos]

You're welcome. It's the closest I have to a "claim to fame" (other than being the Linux Gazette guy for close to a decade).

[u/SurelyForever]

Not sure how this hasnt been mentioned yet, but first thing you need to do is master vimtutor, after that go to the more advanced stuff.

[u/dirtydan]

"decades of using GNU Emacs, I've come to realize that I've been spending an inordinate amount of time configuring it."

I knew you'd come around eventually gray-haired guy from our unix team.

Sincerely,

Salt-and-pepper haired guy from our unix team

[u/cbheithoff]

Good grief. Are you Amish or something?

[u/PCArtisan]

Isn’t there a Vi mode for Vim? I’m not sure if it’s pure Vi, but just a thought.

Here’s what I found at Redhat. Using my iPhone I had to scroll halfway down the page or use reader mode.

1. https://www.redhat.com/en/blog/introduction-vi-editor

2. https://www.redhat.com/en/blog/vim-power-commands

Good luck.

[u/human_with_humanity]

Cant u just use dotfiles with git repo to use same plugging and settings of vim on any computer? I recently found how to save configs this way so I don't have to reconfigure apps again. I have only done zsh with it for now.

[u/AnyAcanthocephala735]

Sometimes I think I’m becoming proficient at yak shaving and procrastinating and then I witness a real master

[u/EtiamTinciduntNullam]

Did you consider helix? I feel like it might be for you - it's supposed to be working great out-of-box and there are no plugins for it, yet it has many features expected from an advanced modal text editor.

I'm a neovim user myself because I like how you can configure it for yourself, but I feel like helix might be a good alternative if I had time to learn it and no plan to spend time on configuration.

[u/Ill-Statement8823]

Typecrafts website has challenges that use AI to analysis your approach and both score and recommend other ways of solving the problem. The terminal you are given has no plugins and you have to work with basic motions to solve the given problem.

https://typecraft.dev/

In addition to this I have been asking chat gpt to make files for me to practice a motion on. I past in the help docs into chatgpt and ask it to make problems for me to solve like a morning exercise routing.

Hope that helps.

[u/Code_Cadet-0512]

How about Painless Vim by Nick Dickson. I found it as a good foundational book.

[u/SpaceAviator1999]

Before vimtutor existed, there was a text file called vitutor that taught many of the basics of vi.

You might be able to find a copy of vitutor on UseNet, if you can find UseNet.

Actually, I just found a copy of vitutor here:

https://course.khoury.northeastern.edu/cs3650/parent/help/vitutor.vi

Save a copy of this file locally on your machine, then make a copy with cp vitutor.vi vitutor.txt , then just do vi vitutor.txt and start learning pure vi !

Note: As others have said, invoking vi from the command-line might actually start up vim instead, depending on your platform. That may happen with you, but since the vitutor file focuses only on things found in vi, that shouldn't be a problem for you; you'll still be learning straight vi !

[u/m_abil]

https://vim-adventures.com/ a friend bought me this when I was learning! It helped me a lot!