Hacker News Reader

Comment by baby | Hacker News Reader

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

View on HN

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.

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.

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

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.

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

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

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.

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

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.

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.

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

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.

Reply on news.ycombinator.com