A vi-centric family tree of editors (2000)(web.mit.edu)
web.mit.edu
A vi-centric family tree of editors (2000)
http://web.mit.edu/kolya/misc/txt/editors
12 comments
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.
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
[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.
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.)
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
[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 :/
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
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/PLISTI think this is the more relevant requirement, the above build even links to an audio library...
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
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/
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/
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[deleted]
It's still very much this. The footprints of many entire server distros are less than 220MB.
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).
"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.
It's very silly.
[deleted]
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.
; 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.
In ancient times, emacs didn't have an X-Windows driver. On my current box, emacs-nox is 13 megabytes.
And to think that "Eight Megs And Counting" was once an exaggeration!
Also, typically the tiny version of vim is installed by default.
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.
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.
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)
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.
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.
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.
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
?
Yes. Yes, that's exactly what it means.
I learned to program C in a crippled version of ed. Ed rocks!
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.
[deleted]
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
http://man.openbsd.org/OpenBSD-current/man1/mg.1
http://man.openbsd.org/OpenBSD-current/man1/vi.1
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.
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.
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.
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.
It is faster than Google Docs or MS Office, but the lag is noticeable.
Vim is not instant. Moreover, it has annoying TTY handling behaviors; it flushes the TTY when starting.
So if I type
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.
So if I type
$ vim file
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 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?
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?
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 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.
(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.
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.
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
* https://news.ycombinator.com/item?id=13056252
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...
http://web.archive.org/web/20060501032837/http://metashell.b...
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
https://www.emacswiki.org/emacs/Evil
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.
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.
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.
emacs was a thing developed and ported from other operating systems.
> vi was part of unix that came from at&t.
vim Adventures is the only reason I would use vim over emacs. [0]
[0]: http://vim-adventures.com/
[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.
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)
(/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.
wat.
Try spacemacs. It's really good. Most advanced vim stuff works as well as or better than in vim.
[deleted]
"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.
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.
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.
emacs never made it to that status, even as it was contemporary with vi.
[deleted]
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.
"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.
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
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?
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.
You can use http://asciiflow.com/ to create ascii diagrams in your browser.
Emacs' Artist Mode[0][1] might help.
[0] https://www.emacswiki.org/emacs/ArtistMode
[1] https://www.youtube.com/watch?v=cIuX87Xo8Fc
[0] https://www.emacswiki.org/emacs/ArtistMode
[1] https://www.youtube.com/watch?v=cIuX87Xo8Fc
There is monodraw for Mac OS X: https://monodraw.helftone.com
I made it by hand in vi.
Interesting how John McCarthy, the father of lisp, seems to be at the root of it all.
Well MIT did have (one of?) the first PDP-1, which is why there are a lot MIT names on the family tree.
Ironically, not quite "it all".
Look again; the Emacs lineage is disconnected.
Look again; the Emacs lineage is disconnected.
A recent addition is vis[0], which incorporates sam's structural regular expressions.
[0]https://github.com/martanne/vis
[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.
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!
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
[1]: https://en.wikipedia.org/wiki/Vi
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