$ 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
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 $ ldd /opt/sublime_text/sublime_text | wc -l
15
$ ldd /home/tmk/.local/share/umake/ide/visual-studio-code/code | wc -l
84
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".
/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.7It's very silly.
; 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.
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.
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)
This entire thread makes me giggle, usually posts about editors are filled with bad temper, but not this one.
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.
exit
?
quit
?
q
?
bye
?
help
?
ohmygodgetmeouttaheeeeere
?
This, iirc, done because pico was part of the pine email client. And pine was covered by a iffy license.
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.
It is faster than Google Docs or MS Office, but the lag is noticeable.
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.
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?
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.
http://web.archive.org/web/20060501032837/http://metashell.b...
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.
emacs was a thing developed and ported from other operating systems.
> vi was part of unix that came from at&t.
(/s kind of... I just love vim too much)
wat.
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.
emacs never made it to that status, even as it was contemporary with vi.
"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.