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.
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.
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?
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.
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 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:
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).
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)?
; 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.
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.
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 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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
"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".)
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