Understanding the Origins and the Evolution of Vi and Vim | Hacker News Reader

Understanding the Origins and the Evolution of Vi and Vim

pikuma.com

284 pointsamosjyng122 comments

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!

If you can recall, what were the individual assignments? Would love to understand how the modules added up

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

If you do find someone I’d love to hear more as well.

I found part of my homework assignments, some printouts. I'd forgotten the big reveal at the end of the class. If all the homework assignments were done correctly, a makefile given out as the class ended, "a surprise gift", turned all the homework in a subset of a C compiler.

The class's TD was also very interesting. He was 13, a child prodigy in their CS PhD program. I remember when I learned his age, he told me not to tell anyone, it would impact their ability to learn from him.

> C compiler

Nice. So were the HWs split along the usual lines of lexer, parser, codegen, etc? You said it was a surprise, so I wonder how else it was split to actually make it surprising. Or was it hard enough to judge the purpose of the assembly version that it didn't matter?

I remember we were not given names for the pieces and parts, just these paragraph or three descriptions of what the written code would receive and what it would output, and what CS fundamentals we should use in that assignment. A good portion of the class's difficulty was in these weird assignments with these really weird I/O requirements. It was explained that companies that work in assembly are often working on DoD contracts, and these were the nature of one's work assignments: obtuse I/O requirements with no idea what they plug into or are used for... clever indirection.

I'm now reminded of an unrelated mini-vi: https://github.com/ioccc-src/winner/blob/master/1991/ant/ant...

minor: Vax 11/780 was a minicomputer, though DEC itself refered to it as a 'supermini"

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

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

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

We're only seeing the rare examples that worked out well.

For instance you don't want to code in assembly Facebook's backend. Blender would also be a completely different program if it was primarily optimized for the 68000. You usually will want different tradeoffs and architectural choices when the target platform drastically changes.

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.

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.

I don't think it's even so much about keystroke count as it is the "commands" are more like a language that you can keep getting better in. For example, from above:

> d), d{

That's not two different commands, it's one action (delete) and two different motions (forwards one sentence, backwards one paragraph). Motions work on their own for moving the cursor, but can be combined with different actions and repetitions to multiply the sentences (commands) you can make. As you increase your vocabulary over time (there are a lot of motions and selectors (which are slightly different but used similarly)) you can keep reducing that friction between thought and screen.

Yes, I'd say the composability of commands is vi's key feature. I can't remember any but the most common shortcuts in other editors. In vi I get so much more bang for the buck since I have easy access to all the commands I remember multiplied by the motions I remember.

And these commands are useless for programming unless you format source code in a very specific way, adding white space such that everything is split into "paragraphs" that can be thought of and operated on as a single unit.

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

That's assuming you're spending all day editing files written in the language(s) supported by your IDE. That assumes a great deal about your programming environment, toolchain, plugins, and configuration. Switch to a different language with different syntax, different idiomatic style, different IDE plugins, and you may be faced with a totally different editing paradigm.

This is where vi shines: the tool is excellent at editing text and is therefore 100% language-agnostic. It can easily handle jumping between files written in different languages, including plaintext files, configuration files, domain-specific language files, and otherwise many other files with syntax that may not be supported by your favourite IDE. Furthermore, it is equally happy working on files that combine different sections written in different languages. Sure, some other editors (such as emacs) and IDEs (such as RStudio) also support this sort of editing, but vi doesn't need any special support for it.

This philosophy, of making text the first-class citizen, in many ways mirrors the Unix philosophy. It also happens to be the case that vi (as well as its ex command line) provides a very convenient command for piping lines, paragraphs, and any other motion you desire through a shell command (or pipeline) of your choosing. This makes it very easy to format text using commands such as `fmt` or `column`, or apply line-numbers using `nl`. This, I believe, makes vi the ideal text editor for developers working on Unix or Linux software.

Yeah, vim was invaluable when I worked in the semiconductor industry. Lots of perl, TCL, SKILL (a lisp dialect) and giant verilog netlists. Languages which don't really have proper IDEs or great all in one tooling.

Now I'm a webdev with everything written in typescript and just use Cursor (basically vscode) with the vim plugin. i miss the tab model from vim a lot, but apart from that the vim plugin is close enough.

> As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST.

Then why does your IDE not look like Scratch?

It is because nobody has found a better representation then text when it comes to editing concrete syntax trees.

Yes, you will rarely reach for d) or d} when editing Java or JavaScript. But the Vi paradigm does not stop at prose. And it does not stop at modern IDE capabilities either.

The Vi paradigm just enables people to do it faster. With less friction.

> I don't think it's even so much about keystroke count as it is the "commands" are more like a language

It was about minimizing the number of redraws, but this indirectly might have led to fewer keystrokes too.

As you mention later in your comment, there are a lot of motions (which could be combined with deletion too). This is probably related to performance too, because they make it possible to achieve something quite specific like c3), with only a single redraw, and three keystrokes.

The "language" is undoubtedly a very good choice on part of Bill Joy. It wasn't necessitated by the hardware constraints, I believe. The separate modes neither. It's just that he would have wound up with less ergonomic key mappings.

Without the modes we would have to suffer using chorded shortcuts with modifiers, but they could still form a language. Think "M-3 C-d C-)" instead of d3).

Without neither modes nor composition (the "language"), it would have been even worse. A large number of single-purpose shortcuts, likely with multiple modifiers; he would have run out of (memorizable) single modifier combinations.

Absolutely, some people just love vi. Sometimes it fits their mental model, other times someone told them "real programmers use vim/emacs" and so they internalized and studied it. That's why most modern editors still have a vi mode. Obviously it works for people.

But if the 1980s UI Scientists came back with their stopwatches, I don't think the median vi-mode user would "win". Unless they were using a really slow terminal. (obv, we probably have some 1%ers on HN)

That may be true because 1980s UI scientists were most concerned with building efficient and intuitive UIs for the vast majority of people, not for 1%ers.

I know that I, personally, would not have been able to take some of the notes I took in university if it weren’t for vim and its affordances. Trying to keep up with a fast-writing math professor while typing a complete set of notes in LaTeX would not have been possible otherwise!

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

[0]: https://helix-editor.com/

> There are newer editors [0] that are more AST aware…

With Neovim, you get the best of both worlds: it's Vim with AST support via Treesitter and LSP support baked in.

Any good recommendations for plugins to add commands to work on asts?

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.

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

it's not "emulating", it's exactly what you describe. And it's just one additional "v" away, can't be shorter than that.

It's the same for selections, but motions are a little different. To use an example from above, d) is "up to" the next sentence (excludes the first character of the next sentence), while v)d moves the cursor onto that first character and so includes it when deleting.

As someone who started modal editing with Helix and then moved to NeoVim (LazyVim):

After a very short transitioning period (a week or so), I don't have this issue anymore (at all). Keeping coming back to visual mode is probably counterproductive for your transition. So maybe you should stop doing this for some time. Then you'll hopefully find yourself using the visual mode rarely.

> I often find myself going to visual mode to emulate this.

It's just an extra key press. And you can choose which visual mode you'd like!

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.

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

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.

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.

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.

Now with neovim I feel like the plugin ecosystem is catching up to Emacs. Lua has unlocked the potential.

Typescript dev ex in neovim is light years ahead of what I achieved in Emacs. Neovim’s lsp integration is better than Emacs imo. Blink.cmp is so fast.

Magit is definitely far superior to anything in neovim though and so is org mode.

I think Vim and Neovim is better suited as editors, meaning quick launch, fast localization of files and fast editing actions. And I like plugins that support this philosophy.

But the goals with emacs is to be a complete platform for anything plain text (with a bit of extra widgets). Almost whatever you need the terminal for can be replicated there, and they will share some common convention. Mail, file manager, music players, feed readers, PKM, PIM,… Tect editing is not so great, but text actions are (Slime is the best example).

I use both, but I prefer emacs’ extensibility.

Yes Emacs is still a better platform for building applications on for sure. Emacs lisp is a better language than Lua although harder to learn.

I used Emacs with evil mode for years until switching to neovim last year. It was really great.

> And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.

First thing I install on any IDE/Editor.

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

I can count on one hand the number of times I’ve had to use vi or nano and not had another option in 15 years programming. Optimising for that use case is not an efficient use of time.

Same, except it goes back 30 years, but it sucks when that one time comes up. I'm not suggesting one becomes a wizard. I'm suggesting understanding basic commands.

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

I would say it’s incredible to see the quality and “durability” of Linux/Unix tools. The other day I wondered “how old is grep”, looked it up and realized that I use a piece of software that’s over 50 years old on a daily basis.

The fact that these tools have stood the extreme test of time is really something.

Back in '94 I remember motherfsking some paper I was writing late at night in the computer lab. I think the wordprocessor was AmiPro, and it was giving me grief to the extent that I was at the point of violence.

Another person in the lab came over, invited me to his machine and showed me LaTeX in Emacs. We became friends (he a mathematician, I a zoologist). I bought beer; he brought 'computer wisdom'. Thirty-odd years later, those files are still perfectly reproducible. All of my kid's school reports from elementary onwards... LaTeX.

It's hard to overstress how important is longevity in a toolset.

Side rant on Emacs' keybinds: with orderless and vertico (and marginalia and whichkey) it is almost as fast for me to `M-x dir` as to `C-x d`, and in both cases I get a dired buffer. Aaand, `dired` is magic. History also tells me that it is older than Emacs.

\end{rant}

What is the experiment?

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.

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.

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.

The cursor would start before the T. 4C would position the cursor before the q. The 6D would delete quick . Then <esc><esc> would execute the command buffer.

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.

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.

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.

A lot of the "elite" compsci students at my college in the early-ish 80s were still using TECO on our DECSYSTEM 2060 but some of the cool-kids were trying that new Emacs thing ;)

Me, being just a lowly compsci minor, prefered the full screen editor called FOXE. Was very simply to use and did the job fine for writing/editing programs of the length typical of homework assignments. Don't recall all the particulars to comment on search, replace, etc.

Unfortunately, there is like zero internet info on it beyond: "Little (if any) information is available for this visual editor available for TOPS-20 in the early 1980's. It was similar in appearance to the then new EMACS but had a far simpler command structure."

Great story!

The TECO macro I posted is the VT52 one.

TECO has commands that support line editing—like 0T and T, but they both are required to type a whole line—but it is a character editor; you can delete characters from the middle of one line to the middle of the next, if you know the character positions; line editors can't do that. another example, the buffering window that you are editing within is not line aligned.

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.

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.

It could also be invoked on VAX/VMS under the name “MUNG”, which was said to stand for “Modify Until No Good”. I think that style of invocation did something slightly different than using the TECO command, like creating a new file.

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

Obviously, the TECO programming language was a challenge to understand. Mitigating this is it needed to be extremely compact, as it was used on a 64Kb PDP-11.

That has a texture reminiscent of the J/k family.

I love this use of texture; will steal ;)

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.

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

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.

That's fantastic, well done!

Is the "Controlled Neovim Terminal" supposed to be some bot you are competing with? At first it confused me. Personally I think the first contact with the game would be much more intuitive without it (it can always be introduced later, e.g. if you plan competitions with other humans on randomly generated levels).

There are only two levels now, right? As I equaled both top scores (possibly optimal?)... when more? ;)

> 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

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.

The ancestor of all those full screen terminal editors is the RAND editor, which was on Unix around 1974.[1] Few people outside the DoD research community saw it, because it wasn't free and only worked on some terminals. Functions were triggered by dedicated function keys, not key combos or a command line, and it was customary to use something with 8 to 10 function keys, such as the HP2645A. You could split the screen, edit two files, and do cut and paste. Way ahead of its time.

[1] https://www.rand.org/content/dam/rand/pubs/reports/2008/R217...

[2] https://terminals-wiki.org/wiki/index.php/HP_2645A

I used the rand editor in early 80s & loved its “infinite” quarter plane model. Dave Yost enhanced it quite a bit and called it the Grand editor. But it was hard to maintain as it relied on K&R C. Eventually I gave up and went back to vi.

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.

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

Side note: that ADM-3A bears such a beautiful design. I like how its curves are akin to the screen curvature.

I bought a used one for my use at home while working on a university degree. And as another comment noted, vi would still be usable with a 300 baud (or 1200, I can't quite remember) modem. You could limit the visible "window" into your file to five lines on screen, so it didn't take so long to refresh. Alas, no longer have the ADM3a (but my kids when younger did use it as a play typewriter for a while).

A product of Lear-Siegler so it shares heritage with the Learjet family, through Bill Lear.

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.

I think EDLIN is closer to CP/M's ED.

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.

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

[1] https://en.wikipedia.org/wiki/Berkeley_DB

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.

Reminded me of CygnusED, which apparently has even a working website[1]. I really wish the core idea of ARexx had become popular enough.

1: http://www.cygnused.de/index-en.php

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

CygnusED’s speed made it feel unlike any other editor. Brilliant engineering!

So interesting to see how the ADM-3A keyboard layout itself was such a fundamental influence for ESC and hjkl movement in vi.

And that I suspect originates with ASCII Control-H = backspace (cursor left), Control-J = line feed (cursor down). Control-K and Control-L don't match but weren't so important that they couldn't be repurposed by an early display terminal.

Yep. It's all in the manual.

https://archive.org/details/ADM-3A-User-Reference-Manual-Apr...

(This page, and Figure 1-3 below).

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!

I was slightly surprised that they didn't add a mention of neovim.

It’s mentioned in the “last 20 years” graph near the bottom. The article largely focuses on how Vim came to be, long before Neovim.

while neovim is great and I intend to switch even, some time down the road, it caused a not-really-compatible fork and diverted the efforts, I wish them to be merged however hard it will be.

I am maybe just a year or so down from the switch from vim to neovim, but lua is a game changer. It's like, it's easy to configure stuff yourself now. Better plugins are written because the tools are better, or at least so I'm convinced.

I will make a random comparison to latex vs typst (typesetting software). Both incorporate a programming environment, you can write a program right in your document. The difference is that the tex programming environment is a bit unapproachable and not very similar to other languages you may already know, while typst's equivalent is consistent and more similar to languages you know.

> ... lua is a game changer...

Am I the only one who absolutely hates Lua? Its syntax, the fact that variables are global by default unless you local them, `foo = nil` isn't variable assignment but instead variable unassignment!, etc.

There are far better scripting languages than Lua.

You are absolutely not. In point of fact pretty much everyone hates Lua except the handful of folks integrating it. It has a huge lead in terms of embeddability and performance vs. competitors like Python. So you see it show up in little C applications[1] again and again and again because everything else is just too much of a hassle.

But everyone agrees the programming experience in the language is awful.

[1] My son just got into RC planes, so of course I found myself looking at ExpressLRS radios and pulling EdgeTX from GitHub. It's an otherwise straightforward ESP32 board, and there in the app... yup, Lua everywhere.

> But everyone agrees the programming experience in the language is awful.

Simply not true. The power to weight ratio of Lua is amazing. You can keep the entire language in your head easily, and even without LuaJIT it’s crazy fast. It’s great for creating DSLs. As a configuration language it is excellent- in fact that’s how Lua originally came to exist.

DSLs and configuration languages aren't "programming experience" though. (Also that's oversold, you should be on a lisp if that's the design goal, Lua is a distant second.)

I stand by what I said. Lua sucks for coding. The only people who like it are ones who haven't mastered one of the "real" environments.

well, you could warm up to it by using vimscript first

vim9script is much more approachable while still being native to Vim's internals and idea of text editing. I don't know about using it for things like LSPs though, perhaps an expert could chime in.

It's true that Lua is very rough in many places.

But it's still ten times better than Vimscript.

I've been playing with Rust a lot in the last few weeks, and I have been pretty happy with the Rust plugins available for NeoVim. It gives me most of the features I would want from a "real" IDE, but of course it's still Vim, so all my configs and other plugins still work.

I'm convinced that the reason it's so good is because Lua is simply a better language than VimScript, making it easier to make plugins.

Vim9script is actually a great language.

Well, I missed it because I seem to have departed Vim

Ohhhh I misread, I thought you were saying you were a year away from switching, lol.

If you follow any discussions around development, it seems the chance of this happening is essentially zero. I feel that they will continue to diverge into completely different editors.

What do you predict the pros/cons of Vim vs Neovim will be?

Hard to say, but as it stands, but my view is that that the typical nvim users want Vim as a full-fledged IDE with little effort whereas Vim users still want Vim largely as a text editor. And of course there are already a whole bunch of incompatible differences between them that would only be noticed by the more "power" users I suppose.

And vis editor, that also has herietage from sam.

I actually use vis daily, alongside NeoVim - for opening very large files.

Most editors choke at couple MB, Vis can open 10 Gigabyte text files with zero delay.

vis rocks!

https://github.com/martanne/vis

Does anyone know of a good Vim plugin for navigating Python code blocks? E.g. moving to the start/end of a block, or moving to the next block.

If I remember correctly the script runtime/ftplugin/python.vim remaps [[, [], ]], etc. to work with Python's idea of blocks.

Besides, the plugin michaeljsmith/vim-indent-object defines a new text object ("i"), based on indentation levels.

The history of ed, TECO and other pre live fullscreen programs is also worth reading.

My first text editor has been vi on NCR Unix machines back in 1986 and DEC Ultrix in 1988. I fell so deeply in love that I joyed only when I could get a "copy" of vi.exe from MKS unix-like toolkit for DOS. That file only.

Nice read, indeed. Especially the final sentence.

> Also... Emacs sucks!

I was surprised to see this on pikuma… I guess “ Also... Emacs sucks! ” is ok to end the blog entry. To me it is just hard to use 2-3 figures and it seemed hard for inventory as well. That sucks.

Author here! I remember struggling with the decision of adding that last sentence or not. But at the end I was sure most readers would get that it is obviously a joke. Maybe a bad one but still a joke.

I loved the ending! Glad you kept it in. I’m sure the emacs folks will appreciate the humour in it. And they’re welcome to write their own article on the history of emacs and end it similarly. They’ve probably got a binding for it.

I read it as sincere, gratuitous and unfounded mud-slinging, which made me end this remarkable article on a pretty underwhelming note. We all have different senses of humor, mine would have needed some caption here :'-)

Mapping escape to caps-lock makes much more sense after looking at the ADM-3A keyboard layout. Cool write-up!

See also: "Where Vim Came From" https://twobithistory.org/2018/08/05/where-vim-came-from.htm...

Discussion: https://news.ycombinator.com/item?id=17696023 (420 points | Aug 6, 2018 | 259 comments)

"while other editors, like Emacs, could cost hundreds of dollars."

Huh?

While I suppose that one "could" pay for Emacs, the vast majority of users never have.

Then again, I've only been using Emacs for 45 years, so I'm a newbie. (Yes, I started with the Teco implementation.)

It's a bit dishonest imho to quote out of context. Here's the full quotation:

> Joy also claims that most of vi's popularity came from the fact that it was readily available and bundled with BSD, while other editors, like Emacs, could cost hundreds of dollars.

Joy was referring to the late 1970s early 80s here and in the context of making VI available when he created BSD and published it for free. Unix operating systems were not freely available outside academia back then.

As a slight aside if you want unabashed joy for 18 hours, take Pikuma's Raycasting Engine Programming course. One of the best courses I have taken and I don't do many courses because I have stuff to do. Also it's in C.

Reply on news.ycombinator.com