A vi-centric family tree of editors (2000) | Hacker News Reader

A vi-centric family tree of editors (2000)

web.mit.edu

229 pointstopranks90 comments

They missed the RAND editor.[1] This was a full-screen editor of the late 1970s, years before "vi". It was originally designed for a specific HP terminal [2], one which had programmable function keys, and there was a little plastic overlay to place around the function keys indicating what they did. Later, there was a custom terminal with built-in keys for the editor functions. Expecting users to remember control sequences was considered unacceptable.

The RAND editor wasn't free. We had a site license for it at an aerospace company, so it was on all the UNIX systems. It was not used widely outside aerospace and DoD. "vi" was an attempt to do roughly the same job without the special hardware.

[1] http://www.rand.org/pubs/notes/N2239-1.html [2] http://terminals-wiki.org/wiki/index.php/HP_2645A

Cool! It makes me sad that history like this will be lost when the first generation of coders turns to dust.

Before an hour ago you were one of the only people in the world to know this little bit of history, and the fact would have probably died with you.

It's not lost. There's the RAND paper mentioned above. The code is on Github.[1] It runs on Linux now.

[1] https://github.com/blakemcbride/Rand-E-Editor

Github is a treasure trove of awesome.

Maybe they felt there was no known or documented relationship between that editor and vi. Then again, they missed Bravo (which ran on the Alto) and Bill Joy has talked about its influence specifically.

Bravo is completely different. It's mouse-oriented, with proportional spacing and multiple fonts. It's the ancestor of Microsoft Word. Charles Simonyi worked on both Bravo and Word.

You can use Bravo as a programmer's editor, because the file format is plain ASCII followed by a control-Z, then formatting information. Alto compilers read the plain text part and stop at control-Z.

Mouse aside, Bravo isn't in here because its command set doesn't feel like an ancestor or a child of any of these other editors.

For example it uses G (for Get) to load files and P (for Put) to save them, instead of r (for read) and w (for write) like the ed family does.

(Whereas Sam for Plan 9 uses the mouse like Bravo does, but applies ed-like commands to the mouse selection.)

This was my post to alt.folklore.computers. Nice to see it reappear after all these years!

Did Elvis miss the cut? https://en.wikipedia.org/wiki/Elvis_(text_editor)

I didn't include it, because the original question was where vi and its predecessors came from, not what offspring did it have itself.

Is the source history of these editors saved in the UNIX history GitHub project[1]? Is there significant code overlap or is your diagram more along the lines of inspired-by relationships?

[1] https://github.com/dspinellis/unix-history-repo

There is not a lot of code overlap in most cases, even between ed and ex. The relationships are generally more about command sets than direct forking of code.

Interesting to note that the author, Eric Fischer, still creates beautiful data visualizations https://www.twitter.com/enf

Thank you!

Anyone knows why emacs is almost never installed by default while vi(m) is? I often wish I had learned vim instead of emacs because of this :/

It's probably best to learn both. I usually switch back and forth. Just spend a week or so forcing yourself to use only vim and you'll never forget it.

Blasphemy! You should only use vim.

(/s kind of... I just love vim too much)

I used to feel similarly, but vim inside emacs is pretty sweet. The emacs package "evil" gives almost perfect vim emulation. Suddenly the entire emacs ecosystem is available to anyone who knows vim. And the ecosystem is massive.

As a vim user who's yet to learn emacs...

wat.

Try spacemacs. It's really good. Most advanced vim stuff works as well as or better than in vim.

Historically, probably because

    $ ls -lh `which emacs`
    -r-xr-xr-x  1 root  wheel   220M Oct 19 02:10 /usr/bin/emacs
    $ ls -lh `which vim`
    -rwxr-xr-x  1 root  wheel   1.7M Oct 19 02:38 /usr/bin/vim

Disk space isn't as much of an issue anymore, but still, it's 100x the size.

That's how I ended up learning vi. In 1993, my 386 didn't have enough disk space for emacs, so I had to learn vi (which is lucky because I probably wouldn't have done it otherwise).

It's still very much this. The footprints of many entire server distros are less than 220MB.

To say nothing of:

        kamloops$ ldd  $(which vi)
        /usr/bin/vi:
                -lcurses.7 => /usr/lib/libcurses.so.7
                -lterminfo.1 => /usr/lib/libterminfo.so.1
                -lc.12 => /usr/lib/libc.so.12
                -lutil.7 => /usr/lib/libutil.so.7
        kamloops$ ls -ld  $(which vi)
        -r-xr-xr-x  3 root  wheel  506072 Nov 26 15:57 /usr/bin/vi
        kamloops$ ldd /usr/pkg/bin/emacs-24.5
        /usr/pkg/bin/emacs-24.5:
                -lossaudio.1 => /usr/lib/libossaudio.so.1
                -lc.12 => /usr/lib/libc.so.12
                -lexecinfo.0 => /usr/lib/libexecinfo.so.0
                -lelf.2 => /usr/lib/libelf.so.2
                -lterminfo.1 => /usr/lib/libterminfo.so.1
                -lpthread.1 => /usr/lib/libpthread.so.1
                -lm.0 => /usr/lib/libm.so.0
                -lz.1 => /usr/lib/libz.so.1
        kamloops$ ls -ld /usr/pkg/bin/emacs-24.5
        -rwxr-xr-t  1 root  wheel  14682824 Jul 27 16:51 /usr/pkg/bin/emacs-24.5
        #
        # count of files installed per package...
        #
        kamloops$ wc -l /usr/pkgsrc/editors/nvi/PLIST
              24 /usr/pkgsrc/editors/nvi/PLIST
        kamloops$ wc -l /usr/pkgsrc/editors/emacs24/PLIST
            3914 /usr/pkgsrc/editors/emacs24/PLIST

I think this is the more relevant requirement, the above build even links to an audio library...

nvi vs. X11 emacs? Isn't that a bit like comparing uemacs to gvim?

This isn't comparing X11 emacs to vi, it's emacs (built w/ a no-x11 switch) on NetBSD compared w/ native nvi. If this were an X11 enabled binary, you'd see links to various X11 libs and GUI toolkits, similar to this xterm:

        /usr/X11R7/bin/xterm:
                -lXft.3 => /usr/X11R7/lib/libXft.so.3
                -lX11.7 => /usr/X11R7/lib/libX11.so.7
                -lxcb.2 => /usr/X11R7/lib/libxcb.so.2
                -lXau.7 => /usr/X11R7/lib/libXau.so.7
                -lc.12 => /usr/lib/libc.so.12
                -lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
                -lfontconfig.2 => /usr/X11R7/lib/libfontconfig.so.2
                -lexpat.2 => /usr/lib/libexpat.so.2
                -lfreetype.18 => /usr/X11R7/lib/libfreetype.so.18
                -lz.1 => /usr/lib/libz.so.1
                -lbz2.1 => /usr/lib/libbz2.so.1
                -lXrandr.3 => /usr/X11R7/lib/libXrandr.so.3
                -lXrender.2 => /usr/X11R7/lib/libXrender.so.2
                -lXext.7 => /usr/X11R7/lib/libXext.so.7
                -lXaw7.10 => /usr/X11R7/lib/libXaw7.so.10
                -lXmu.7 => /usr/X11R7/lib/libXmu.so.7
                -lXt.7 => /usr/X11R7/lib/libXt.so.7
                -lSM.7 => /usr/X11R7/lib/libSM.so.7
                -lICE.7 => /usr/X11R7/lib/libICE.so.7
                -lXpm.5 => /usr/X11R7/lib/libXpm.so.5
                -lXinerama.2 => /usr/X11R7/lib/libXinerama.so.2
                -lcurses.7 => /usr/lib/libcurses.so.7
                -lterminfo.1 => /usr/lib/libterminfo.so.1
                -lutil.7 => /usr/lib/libutil.so.7

Of course, we can do even better these days

    $ ldd /opt/sublime_text/sublime_text | wc -l
    15
    $ ldd /home/tmk/.local/share/umake/ide/visual-studio-code/code | wc -l
    84

And I'm not sure ldd even captures all the libraries these things load.

Things are better still when one stops looking at shared libraries and starts looking at run-time remote procedure call dependencies.

The GNOME editor, a "small and lightweight text editor" according to the blurb and its reviews by some clearly incurious reviewers, requires that a per-user/per-login Desktop Bus broker be running and also (on my machine) that the following Desktop Bus servers be running: at-spi-bus-launcher (which runs another Desktop Bus broker), api-spi2-registryd, dconf-service, gvfsd, gvfsd-udisks2-volume-monitor, gvfsd-afc-volume-monitor, gvfsd-goa-volume-monitor, gvfsd-gphoto2-volume-monitor, and gvfsd-mtp-volume-monitor.

Normally, it behaves like WIN16 programs used to behave: invoking the editor a second time simply sends a D-BUS message to the already running first instance to tell it to open another document and then exits that second invocation. If you want to start up a true second separate instance, one way to do so is use dbus-run-session to start it up with a private Desktop Bus broker of its own. Of course, doing so starts up second instances of all of the aforementioned D-BUS servers as well.

This is not "small and lightweight".

* http://unix.stackexchange.com/a/323700/5132

* http://unix.stackexchange.com/questions/201900/

"eight megs and constantly swapping" seems so quaint :P

with emacs 25 incorporating webkit, we can now say "emacs may also contain safari"

Given that the browser is fast approaching a full OS layer, does that mean you're effectively running an OS within an OS within an OS (or more so if you're running on virtualisation)?

I don't know, but open up emacs, type M-x term, then emacs -nw, then type M-x term, then repeat.

It's very silly.

In ancient times, emacs didn't have an X-Windows driver. On my current box, emacs-nox is 13 megabytes.

Are these statically linked?

; ls -hl `{which emacs-25.1} -rwxr-xr-x 1 root root 17M Sep 18 04:32 /bin/emacs-25.1 ; ls -hl `{which vim} -rwxr-xr-x 1 root root 2.6M Nov 15 16:06 /bin/vim ;

17M is much more reasonable, but emacs has many supporting files as well. It's been installed on every system I've ever used that wasn't busybox-based, you can package it much smaller.

And to think that "Eight Megs And Counting" was once an exaggeration!

Also, typically the tiny version of vim is installed by default.

I still hear the old joke sometimes:

Emacs user: You should never turn off emacs.

Vim user: because it takes too long to load emacs.

The irony being the points behind both sides of this joke pretty much have no meaning with the current state of technology.

Not really. I'm an Emacs partisan, but my Emacs takes at least 3 seconds to load (often 4 or even a little more), while vim is instant.

It is faster than Google Docs or MS Office, but the lag is noticeable.

Well I certainly don't dig into the depths of what I can make emacs do (and hence load) but I find it opens seemingly instantly for me unless I am doing something like using the window mode on a VM that mimics a video card.

Run as daemon https://www.emacswiki.org/emacs/EmacsAsDaemon

I should not need to run a background daemon for my text editor to load quickly.

True, but it's pretty reasonable for your nested OS to take a while.

Enjoy, then, the need to run a whole bunch of background daemons in order for some "small and lightweight" text editors to run at all. (-:

* https://news.ycombinator.com/item?id=13056252

Vim is not instant. Moreover, it has annoying TTY handling behaviors; it flushes the TTY when starting.

So if I type

   $ vim file

and start entering editing commands, often I do it so fast that some of the characters get cut off, like the leading colon of an ex command or what have you.

There is no good reason for this. It will not happen with any reasonable command line utility.

I reported this to the Vim mailing list not long ago and was basically brushed off.

I love vim but recently started using Emacs with spacemacs and it takes a long time to load. Vim is basically instantaneous and Emacs is like molasses.

Have you reported it to the Neovim devs? It stands a better chance of being included there (IMHO) and from there it's possible that it trickles up (like the async features in Vim 8).

I read https://groups.google.com/d/msg/vim_use/XX6SoxHAzhI/vuyIx71G... and it doesn't look like a brush-off to me.

What's missing is the statement that this is how things work when one is relying upon terminals to respond to special control sequences with strings denoting their capabilities. In theory one could save up and re-process the input characters that arrive before the DECDSR response. In practice, people throw them away.

Did you try it on a non-xterm terminal type, as was suggested?

(emacs-init-time) "0.2 seconds"

Use autoloads everywhere. Put all per-package configuration in lambdas executed on hooks, or eval-after-load. Lazy-load Helm by mapping M-x to helm-M-x etc. - small ad-hoc edits probably don't even need Helm.

I still use emacs --daemon / emacsclient (aliased to 'e'), but I keep my $EDITOR set to emacs. There's no good reason to have a long wait for startup.

emacsclient is even more instant than vi, in my experience.

An old post I wrote (2006) on a way to improve emacs startup times by loading commonly used packages into your core for instant startup time:

http://web.archive.org/web/20060501032837/http://metashell.b...

IIRC, it was the case that for commercial Unixen, the Single Unix Specification v.2 stated that amongst other things, the vi editor always had to be available.

So, vi gets dragged in as part of your vendor's commitment to "standards compliance". Also, for SUS purposes, vi means SysV vi, not vim. A far less domesticated creature.

In a base install of Solaris, Irix, HP-UX or Tru64, it'd be the only editor you get. Vim, emacs, nano, joe etc. would all be in a seperate "freeware tools" or somesuch sideloaded optional install set.

This is how I learned vi. I was a pico (now called nano) user but needed to edit the hosts file when Solaris was released for x86.

More correctly nano is a reimplementation of pico.

This, iirc, done because pico was part of the pine email client. And pine was covered by a iffy license.

Ah, neat, I didn't realize it wasn't just renamed :)

Not only that, but vendors would freeze those tools in time.

I worked for an employer who banned "freeware" tools so you were stuck with ancient, broken software on Solaris and other systems.

Post 9-11, we had to secure all of the things, including moving away from rsh and telnet. SSH was problematic due to the freeware thing -- no worry... we were able to buy "IBM SSH" for $900 per processor value unit. (IBM SSH was an out of date OpenSSH where someone did a find and replace substituting Open with IBM)

"Nobody ever got fired for buying IBM."

This entire thread makes me giggle, usually posts about editors are filled with bad temper, but not this one.

> it'd be the only editor you get.

Slanderous and outrageous lies!

Ed, man! !man ed

Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!

“Ed is the standard text editor.”

But more historical and factual: Ed is actually "mandatory on systems conforming to the Single Unix Specification)" as well.

I learned to program C in a crippled version of ed. Ed rocks!

Ah, ed. I have fond memories of being stuck in an ed command line inside the Unix mode of Z/OS on a mainframe.

  exit
  ?
  quit
  ?
  q
  ?
  bye
  ?
  help
  ?
  ohmygodgetmeouttaheeeeere
  ?

P.S. I'm not a native English speaker. "Fond" means "a vision of hell" right?

Yes. Yes, that's exactly what it means.

"why emacs is almost never installed by default while vi(m) is?"

Memory footprint of emacs is? Vs memory footprint of vi? I've had problem machines where no OS is installed and working in low memory cf: ~ https://slashdot.org/~goon/journal/49959 so steps like ^copying bootblack to disk and hexifying using vi(m) and hexman^ for example, painful in Ed, impossible in emacs, are made bearable in vi.

On Unix, the editors were ed and vi. EMACS originated on ITS and is part of GNU, so it should be installed by default on GNU/Linux but not necessarily on other Unices.

OpenBSD includes both mg(1), the emacs-like editor and nvi the 4.4BSD new vi(1).

http://man.openbsd.org/OpenBSD-current/man1/mg.1

http://man.openbsd.org/OpenBSD-current/man1/vi.1

vi was part of unix that came from at&t. i mean they still shipped ed, but

emacs was a thing developed and ported from other operating systems.

  > vi was part of unix that came from at&t.

And that's why USL settled the BSD lawsuit. https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc....

Not a comment on why, but when I first asked the elusive n00b question "vi or emacs?" to a thick-skin, the response was:

"Emacs is like a beautiful woman, but vi is like your hand; it will always be there."

Related: it's pronounced "VEE EYE" if you're a "JIFF" person. And anything but "six" otherwise.

I like "jiff" but prefer "vye", so whatever.

And as I understand it's called vi because of 'visual' mode of 'ed' line editor.

vim Adventures is the only reason I would use vim over emacs. [0]

[0]: http://vim-adventures.com/

Wow, what a game. First I had impression of Mario, then mine sweeper and finally pacman. But it was none of them but a new category of a game. Can you recommend some more fun learning stuff related with me. You can also share it using /r/vim too.

I think the historical reason for this is that vi (or rather, ex; the "vi" executable was added later) was part of BSD since the original BSD release. From there it got picked up by System V, and then since both BSD and System V had it, it was a shoo-in for the role of the standard POSIX visual editor.

You can learn both. I prefer Emacs as an environment but use Vim keybindings within because they're so ubiquitous and pretty good.

https://www.emacswiki.org/emacs/Evil

vi is part of what's expected on a Unix and made it into the various standards - if you're on even a weird Unix, it's going to have some sort of vi on it.

emacs never made it to that status, even as it was contemporary with vi.

They have different workflows. Emacs can edit remote files.

With vi, you ssh to the remote machine, run vi and do your edits, then log out.

With Emacs, you ssh to your machine wherever it is already running Emacs, and use the remote edit features. You never close Emacs.

I built a platform to keep track of the lineage of things and their variants: http://www.theymadethat.com/things/fi4/vi/show_evolution

It still needs heavy work on usability and there are still some key features missing (like an actual family tree visualization), but progress is steady.

Feel free to leave some feedback

This might be kind of off-topic, but I am interested in how he create this tree diagram, is there any tool could do that? or just handmade?

There is monodraw for Mac OS X: https://monodraw.helftone.com

Emacs' Artist Mode[0][1] might help.

[0] https://www.emacswiki.org/emacs/ArtistMode

[1] https://www.youtube.com/watch?v=cIuX87Xo8Fc

A fun tool once you have handmade diagrams is https://github.com/ivanceras/svgbobrus which converts them to svg.

You can use http://asciiflow.com/ to create ascii diagrams in your browser.

I made it by hand in vi.

Interesting how John McCarthy, the father of lisp, seems to be at the root of it all.

Ironically, not quite "it all".

Look again; the Emacs lineage is disconnected.

Well MIT did have (one of?) the first PDP-1, which is why there are a lot MIT names on the family tree.

A recent addition is vis[0], which incorporates sam's structural regular expressions.

[0]https://github.com/martanne/vis

It's quite strange that the lacking feature of vim was a proper and good extension language where most of the editor itself you could modify, but vis comes along and instead of a powerful language like Lisp has Lua almost tacked on.

An editor with the speed of use of vim combined with a Lisp-like language (elisp with the warts removed) would be great.

Anyone interested in learning Vim might enjoy some practice exercises! https://github.com/steveshogren/10-minute-vim-exercises/blob...

Since some of the authors are from academia, it would be nice to have references to the scientific papers addressing the implementation of these editors.

Awww, I would love to see the rest of this conversation!

There you go https://groups.google.com/forum/#!search/$20emacs$20and$20ot...

I don't actually understand this. Can someone explain???

"vi"[1] is a very influential text editor created in the 1970s (and still used today). This "family tree" show a bunch of other old text editors that directly or indirectly influenced or inspired vi. (For example, George Coulouris's "em" was based on Ken Thompson's "ed". Bill Joy and Chuck Haley's first version of "ex" -- an ancestor of vi -- was based on "em".)

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

Reply on news.ycombinator.com