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

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/

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

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.

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.

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.