Understanding the Origins and the Evolution of Vi and Vim
88 comments
·April 15, 2025bsenftner
porridgeraisin
If you can recall, what were the individual assignments? Would love to understand how the modules added up
bsenftner
Now you've got me digging through archives, I've got all the homework assignments stored. I need to find someone with an exabyte tape reader...
qsort
It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs.
I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)
sudahtigabulan
> It's incredible how good of a design Vi is.
It's interesting how this design was forced into existence by the extremely limited hardware at the time:
TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem.
That's why we got commands like d), d{, D, etc. Trying to achieve the goal in one go, without any intermediate redraws.
teo_zero
>> It's incredible how good of a design Vi is. >It's interesting how this design was forced into existence by the extremely limited hardware at the time
Can we learn that if you design something for a constrained environment, it will shine when the limitation is lifted?
flomo
That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.
chongli
For people who love vi/vim, it's not really about being "a significantly faster programmer." It's about reducing friction between the changes you want to happen and them happening on screen. Editors with a lot of friction (that make you do lots of intermediate or repetitive steps to accomplish a task) can be really annoying to use. For some people, minor annoyances can be very distracting to the point where they take you out of your comfort zone and break your concentration.
Having your concentration broken when you're trying to solve a tricky problem can be a huge productivity drain. So in the end, an editor which may only save a keystroke here and there on average can end up being very productive for some people.
davemp
I’m not sure. Command based editing opens more doors than just optimizing keystrokes. There are edits I somewhat regularly do with Vim macros that save me minutes of typing and cognitive burden of examining refactor locations. It’s probably not going to be make or break, but I do think it’s significant in a p > 0.05 sense.
I imagine Vim is only just a local optima too. There are newer editors [0] that are more AST aware that I haven’t been able to fairly evaluate yet (not in the boring corp approved software list).
arbitrandomuser
This imo is a shortcoming of vim on modern systems, the action precedes the selection.
I would like to select first have a visual feedback of what I selected before taking action on it . Helix and kakuone have got this right .
I often find myself going to visual mode to emulate this.
teo_zero
I don't think it's fair to talk about "shortcomings" and "getting it right": it's a different approach and we must agree that personal preference will diverge.
Personally, I tend to use action-selection for small changes (1 to 3 objects), and selection-action for larger ones (as my brain, I've learned, becomes slower at counting above 3). So "delete 2 words" will be "2dw", but to delete the next 5 words I'll reach out for "v".
codesnik
it's not "emulating", it's exactly what you describe. And it's just one additional "v" away, can't be shorter than that.
nottorp
That's the only reason I know some vi commands to be honest.
It's unbeatable when editing files on a remote server in a hurry and from random places that may or may not have good latency and/or bandwidth.
eimrine
> That's why we got commands like d), d{, D, etc. Trying to achieve the goal in one go, without any intermediate redraws.
This is 1/2 of explaining why vi family is the GOAT. The remaining explanation is that vi family is the only text editor which is able to be used completely without looking at the keyboard or touching the mouse even once. You can not achieve this if you have to use accord commands which are typically binded to what is selected by mouse. No vim-less text editor can ever provide one-click analog of o command (make a new line under the cursor from wherever column the cursor is at the moment of clicking).
pugworthy
I have used VI for many, many years and honestly use perhaps 25% at best of its abilities. But still I get comments about how fast and smoothly I can use it from other developers. Which I think speaks to how powerful even the basic editor can be.
And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.
jxm262
Same here. Tbh, you're comment just inspired to do a deep dive on VI. Wonder how much more productivity I can squeeze out if I spend an weekend focused on it.
skydhash
The productivity comes from not having to think about your editing while simultaneously realizing that you can do some complex editing really easily. I use Emacs and Vim both (I prefer Emacs) and It's quite nice when you can streamline some quick code edits.
My latest experience with Vim was helping a friend fixing some import with a React Native project. A quick grep on one terminal (I could have used quickfix) and using the vim fzf plugin to quickly locate the file. VS Code could have done this but the context switching and UI clutter is not great there.
As for emacs, the main advantages lies in the fact that so many great tools already exist there. Things like Occur, Shell Mode and Compilation Mode (relying on Comint, a more general feature for anything REPL), Project, Eglot, and Magit.
jghn
It is worth knowing pure vi to some extent. To the point you raise, it's pretty much guaranteed to exist on any system you're on. That's not true of anything else, even vim
null
nikanj
As a pure cutting tool, a traditional saw is more powerful than a chainsaw.
That doesn’t mean it’s actually the fastest tool for the real job. Programming is not text editing
thenthenthen
What is the experiment?
CalChris
I've always considered TECO as the ur editor.
Of course, TECO is the explicit ancestor of emacs, as emacs was originally implemented as TECO macros. However, I can't find a paper trail giving similar credit to TECO for vi. That said, istuff<esc> is the same in TECO as it is in vi and TECO (1963) well predated vi (1976). RSTS (along with TECO) was used at Berkeley in 1974 before v6 Unix was installed by Ken Thompson on a sabbatical to his alma mater in 1975. Bill Joy started as a grad student at Berkeley that same year. emacs (1976) wasn't ported to Unix until the 80s.
There's no hard evidence and neither Ken Thompson nor Joy has ever mentioned TECO. So I'm probably wrong.
But I still consider TECO to be the ur editor.
ajross
TECO was just a DEC line editor, not entirely unlike ed/ex. The idea of TECO managing a display terminal (i.e. the environment in which emacs was written as a bunch of macros) came much later, and really only existed at MIT.
Glass TTY terminals were very new in the early 70's. TECO was primarily written to the "Knight TV" system, which was a fancy MMIO framebuffer array hooked up to a PDP-10 that would multiplex a bunch of displays and keyboards. There really was no "terminal" device per se, it was all software. There were other such devices (the MIT one was actually inspired by a similar system at Stanford), but nothing compatible enough to target an editor.
So basically if you were at MIT you'd understand TECO as the pinnacle of editting . But no one else could use it.
By the time Joy started writing vi, the idea of a "terminal" being a serial-connected device speaking a byte protocol with a handful of reasonable operations (position cursor, clear screen, etc...) had solidified. So a portable editor that would work with multiple devices was feasible. Emacs wouldn't get that for a few years yet.
WalterBright
I started with TECO (Text Editor Character Oriented) on Caltech's PDP-10 back in 1975. There were no glass ttys, just DECwriters and ASR-33s (ugh). I.e. TECO was a line editor.
A couple years later, ADM-3A's arrived. And so did a TECO macro that turned TECO into a screen editor! Oh, what joy!
Isn't it a amazing that a macro could turn a line editor into a screen editor?
I also used TECO on my H-11 PDP-11 computer.
SulphurCrested
We had TECO on our DEC VAXes running VMS in the early-mid 1980s. It had a ”VT52” mode (as you say, a macro), and at least one of the terminals on my desk supported those escape sequences. Wikipedia says the VT52 terminal was made from 1975 to 1978, so those macros were probably fairly early. By this stage, TECO distribution was fragmented with various incompatible versions around, so probably some lacked that macro or other full-screen macros.
Although I had a terminal which could run TECO full screen, I found that too slow and just used it in line mode. You could conveniently reprint surrounding lines by adding a few characters to the end of a commmand (I still have HT <ESC> <ESC> burned into my brain.) The VT52 macro had you typing commands into line 24 like an emacs minibuffer.
I never used it for all my editing, but it excelled at certain things.
The version of TECO we had was the one which shipped with VMS. At some point later on, I think, DEC stopped shipping it, and we migrated to a TECO-inspired full-screen editor developed by another university. Once that arrived, we hard-core TECO users, all 4 of us, were won over within a week.
iDon
The name I recall from using it on a PDP 11/04 was 'Text Editor and Corrector' https://en.wikipedia.org/wiki/TECO_(text_editor)
I vaguely recall it had a line-open / visual mode, like ex/vi, which we didn't use because we were on a dot-matrix line printer / teletype. The ADM-3A had the Ctrl key on the home line; this design made it easy for editors from that period (vi, emacs) to make heavy use of Ctrl.
Thanks to those who posted bits of TECO - I'd forgotten how the character movement was similar to vi. A fellow student in our CS honours year had a semester thesis project analysing the grammar of vi commands and specifying it in a formal grammar. The combination of action x movement is powerful, simple and concise.
WalterBright
At the time, I was told that a student once claimed that TECO was a complete programming language. He was challenged to write a FORTRAN compiler in TECO, and did.
I'm not sure if that was true.
WalterBright
Here's that TECO macro (have fun!):
[4 [5 [6 [7 [8 [9 +0U7 0,0X4 10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4
^D ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED '
@^U5/U9 ET#1ET 27^T Q9^T ET&(1^_)ET/
@^U6/.U8 ZU4 -3U6 ^^HM5 13^T ^^KM5 10^T ^^KM5 13^T :G4
< ^TU7 !F! Q7^T ZJ Q7@I%%
Q7-10"E 13^T ^^KM5 -1%6 '
Q7-21"E Q6^W 0U7 0; '
Q7-127"E -D Z-Q4"N -1AU9 -D Q9-27"E 32U9 '
Q9-31"G ^^DM5 ^^KM5 1+ ' 0"E
13^T -Q6-2< ^^KM5 ^^AM5 > 10^T 13^T :G4 Q4,ZT '
' '
Q7-27"E ^TU7 Q7-27"E !F0! 27@I%% Q4,ZX4 ^^HM5 13^T -1U7 0; '
Q7-^^?"E ^T^[ @O!F0! ' @O!F! '
> Q4,ZK Q8J Q7/
0,0X7 G_ ^YX8 ^YK 0,0X9
^^HM5 13^T ^^=M5
< !A! 0U4 0U6 !B! 1U5
ET#32ET ^TU7 ET&(32^_)ET Q7"L -1^W ^TU7 ' !V!
Q7-127"E .-Q5"L .U5 ' -Q5D @O!A! '
Q7-31"G Q7@I%% @O!A! '
Q7-26"E 0; '
Q7-21"E 0K @O!A! '
Q7-11"E Q5K @O!A! '
Q7-8"E Q5L .-1"G 2R ' @O!A! '
Q7-4"E Q5K @13I%% 10@I%% 2R @O!A! '
Q7-3"E 0; '
Q7-27"N Q7@I%% @O!A! '
^TU7
Q7-^^C"E Z-.-Q5"L Z-.U5 ' Q5C @O!A! '
Q7-^^D"E .-Q5"L .U5 ' Q5R @O!A! '
Q7-^^?"E ^T&31#32U7
Q7-^^0"E Q5L @O!A! '
Q7-^^1"E Q5-1"E 0U5 ' Q5J @O!A! '
Q7-^^2"E ZJ @O!A! '
Q7-^^3"E 0L @O!A! '
Q7-^^4"E -Q5L @O!A! '
Q7-^^5"E Z-.-Q5"L Z-.U5 ' Q5D @O!A! '
Q7-^^6"E @FR%% @O!A! '
Q7-^^7"E Q5< 13@I%% 10@I%% 2R > @O!A! '
Q7-^^8"E Q5P @O!A! '
Q7-^^9"E Q5-1"E ^TU5 ' Q5@I%% @O!A! '
Q7-045"E @^U4%Search: % M6"F @O!A! ' G4 ^Y-2X8 ^YK @O!S! '
Q7-^^."E 0U6 !S! Q5:@S%^EQ8%^[ Q6"N Q6^W ' @O!A! '
@O!A!
'
Q7"D 0U5 < Q5*10+Q7-^^0U5 ^TU7 Q7"D > ' @O!V! '
0U8
Q7-^^A"E -1U8 '
Q7-^^B"E 1U8 '
Q8"N Q5*Q8U5 Q6"E 0U7 .U8 0L
Q8-.%6< 0A-32"L 0A-27"N 0A-9"E 6-(Q7&7)%6^[ -2U7 ' %7 1%6 ' ' C %7 > '
Q5L -Q6U9 0U7 Q6< .-Z; 0A-32"L 0A-13"E 0; '
0A-27"N 0A-9"E 6-(Q7&7)%9^[ -2U7 ' %7 1%9 ' ' C %7 1%9"G R ' Q9; >
0U4 @O!B! '
Q7-^^Q"E @^U4%Command: % M6"F @O!A! ' G4 ^YX9 ^YK @O!C! '
Q7-27"E 0U6 !C! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' M9
10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4
^D ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED ' -1EU
Q6"N Q6^W ' @O!A! '
Q7-^^R"E G7 @O!A! '
Q7-^^P"E Q4"E .+1U4 ' Q5L Q4-1,.X7 Q4-1,.K G7 0U6 @O!B! '
>
ET#16ET ^^>M5 ^^YM5 23+32^T 0+32^T ^^KM5 13^T
!Z! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' ]9 ]8 ]7 ]6 ]5 ]4
CalChris
TECO was a character-oriented editor. Also, it was widely available on RSTS, RSX, RT-11, ... and other DEC systems in the mid-70s. There's a character cursor. So if you opened a file with:
The quick brown fox jumped over the lazy.
These fingers of mine learned TECO before they learned vi and then found vi easier to learn as a result. Besides the basic editing syntax, it was a programmable editor, hence the TECO emacs macros.
Funny thing is that as fondly as I remember TECO, I've tried emacs a few times and have always worked my way back to vi/vim. I particularly like neovim now. I like using ex/command mode for doing bulk editing. Of course you can do the same thing in emacs but I've gotten used to it in vi. I remember programming TECO but I don't remember ever doing programmed editing.
ChuckMcM
I was a TECO user on RSX-11M, then switched to FINE (Fine Is Not EMACS :-)) on Top 10 & 20. When I started at Sun I started using vi but on the Amiga I continued to use MicroEMACS which felt a bit like FINE[1]. After Sun I pretty much stuck to vi because it was so much faster over a remote X11 connection than EMACS was.
Also used PFE32 for a while on the Amiga, sad that the source for that never made it out.
[1] I still have Craig Finseth's thesis "A Cookbook for an Emacs" which talks about designing FINE.
fuzztester
>Also used PFE32 for a while on the Amiga, sad that the source for that never made it out.
I also used PFE32 (on Windows), and for those who may not know, the acronym stood for Programmers File Editor, IIRC :), and the 32-bit version, probably. It was a nice lightweight text editor. One feature it had, that not many other editors might have had at the time, was the ability to open fairly large text files (for that time, at least).
sunshine-o
vi and the UNIX shell are just beautiful tools.
It always amaze me that I was only introduced to them in my adult life way after Windows, but still for me they are the definition of what computer is.
So this is not really about (personal) nostalgia.
Also in the age of 8K screens, VR, AI and AI ready computers, a lot of people still use and love vi.
Call me crazy but my guess is there might still be vi users in 50 years.
nickandbro
Vim is awesome! For my hobby project, Vimgolf.ai , I am trying to make it easier and more fun to learn vim by being gradually introduced to the different motions. I am eventually trying to create different bots to create a standard of difficulty for each level but that is TBD at the moment.
kjellsbells
Retrocomputing spelunkers might also look at EDLIN, a line editor that shipped with MS-DOS that had a great deal of similarity to UNIX ed.
ggm
Aside from neovim, no mention of nvi, Keith Bostic's fork which was BSD mainline, and the Japanese hacked on to add utf handling.
The main divergence of note is tab expansion.
bch
And one probably wouldn’t notice, but the buffer is backed by a “recno”[0] Berkeley DB instance[1].
[0] https://edoras.sdsu.edu/doc/BerkeleyDB/ref/am_conf/logrec.ht...
ggm
Isn't that how most editors manage infinite undo/redo? I wondered if there is some magic "prune the backend and its now linear" model.
bsdz
In a, thankfully past, role working remotely for an antipodal organisation with badly configured networking; often, the lag between typing several characters on the keyboard and those characters appearing on my screen could be measured in seconds! Vi key bindings were a godsend as I could send commands (eg global search & edit etc) and be confident they were being applied before recieving a (delayed) visual update. I feel my experience seems to echo (albeit slightly) that of Bill Joy's vi development on a 300 baud modem!
drbig
Reminded me of CygnusED, which apparently has even a working website[1]. I really wish the core idea of ARexx had become popular enough.
teo_zero
There was another editor for the Amiga, possibly only known to the users of Matt Dillon's DICE compiler, that integrated so well with ARexx that at a certain time I suspect ARexx code surpassed the core C code. The name's DME and the source is still available.
I can't agree more on the beauty of a OS-endorsed scripting language embeddable in every application! Lua might take that role one day...
bodyfour
> The creator of MINIX, Andrew Tanenbaum, asked the community to choose between Stevie and Elvis to be adopted as the main text editor for their OS. Elvis was chosen and it's the default text editor on MINIX until today.
Point of order: Minix switched to BSD nvi in 2013 https://github.com/Stichting-MINIX-Research-Foundation/minix...
Not that it matters -- Minix itself hasn't had a commit since 2018 -- but the last five years of its life were spent without Elvis
litoE
Up to now I have been using elvis exclusively, rather than vim, both on Windows and Linux - I never saw the need to switch, since elvis does everything I need. I just retired it last month, when I upgraded some systems to the latest release of Debian Bookworm and the elvis graphic interface started crashing the whole X windows manager. I have the source code, but I don't have the patience to recompile and debug it.
jiehong
Side note: that ADM-3A bears such a beautiful design. I like how its curves are akin to the screen curvature.
dingaling
A product of Lear-Siegler so it shares heritage with the Learjet family, through Bill Lear.
jasperry
Bram's first version of vim was for the Amiga! Indeed, as the article says, this deserves to be more widely known.
On the other hand, an Emacs clone (MicroEmacs) actually came with my Amiga 500's bundled extras disk...
Harvard University used to teach an assembly language class back in the 80's, taught on a mainframe - a VAX 11/780 or similar I seem to recall. This was an open enrollment class, available to evening and summer students. That class was, well it as Assembly, so it was difficult. The homework assignments were odd, seemingly unrelated. At the midterm, the professor handed out a makefile that combined every assignment to date, and if you did your homework correctly, a mini version of Vi was produced. The rest of the class with polishing that version of Vi, all in assembly 11/780. Taught me one hell of a lot!