> Sometimes people who use computers ask me why I would use something as “bloated” as Emacs for text editing. Usually they remark that Emacs is a hold-over from a by-gone era, much too large compared to editors like “vi”, and that they are quite content using a variant of vi or some Notepad-like editor.
This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the "good operating system, bad text editor" joke you'd see on Slashdot or whatever.
But nowadays while Emacs clocks in at a dozen MB, it's still smaller than what I'd consider "light weight" editors like ST3 and Atom, and minuscule compared to the likes of IntelliJ, Eclipse, or XCode.
It's not really large in terms of memory on any remotely modern system.
But it is large in terms of learning curve. Emacs has a ton of concepts and interface quirks that don't transfer to or from other common software. It has it's own keybindings, even it's own way of documenting it's keybindings, that shares no similarity with what the OS considers standard.
So there's a huge amount of pain in switching too or from Emacs.
I guess bloated means compared to 'instant startup'. Vi starts always instantaneously, whereas Emacs can have a noticeable delay, even if it's only a fraction of a second. Hence the perception that is bloated. Of course compared to the others you mention is quite fast.
Emacs has a different usage model. Instead of starting a new Emacs for every file you want to edit, keep one running and edit all your files in it. If you're working on multiple projects, have one Emacs for each project and switch between them.
It isn't actually as bad as all that. I confess that I do this in system admin mode. On my big workstation it takes about five seconds for emacs -nw to start up. And lately, I have begun using 'mg' for such quick tasks Startup time is less than a second. It is probably on the order of VI for size and speed, and uses the emacs keybindings. It is an upgrade of the MicroEMACS editor.
But normally I do open emacs on a per-project basis and keep it open, likely for days. Those do take a little while to start up. And with .emacs.desktop, it is easy to end up with an accumulation of a couple hundred files at startup time.
(Compare the size of a single tab of Chrome to emacs, or even Microsoft Word. Both are swamped by the chrome size. And we think nothing of spinning up a new tab, no problem.)
Not really. GNU Emacs is no operating system. It has no network stack, no framebuffer interface, no file system implementation, etc. It provides interfaces to those. As such it does not initialize hardware and it starts no OS during startup.
GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.
Fine, sure, but I think his point is just: Emacs users don't run Emacs on files; they run Emacs once and then open files with it (or with gnuclient/emacsclient).
Oh, thankfully someone told me that emacs does not have framebuffers and filesystems. It doesn't have wireless drivers too!
My grandparent comment was an analogy, for illustrating how it's not the optimal way to use emacs, as a command line program invoked to operate on one file and then closed and reopened.
The analogy wasn't that great. Booting a machine has nothing to do with typical uses of Emacs. There are many applications which are long running and are working on multiple documents - it's just another mode of working with an application.
One can use GNU Emacs just fine as an editor which starts and quits on a single file. 'emacs -q' starts in a few milliseconds on my Mac. I use single file edits with Emacs on the terminal all the time. Though I usually also have a long running instance of Emacs - but then it is used as a Common Lisp IDE, not just as an editor.
Then one can setup an Emacs editor server.
Or start the Editor and leave it running. This is no different from, say, a CAD program or any typical application on the Mac, where usually a single instance of an application keeps running, editing multiple documents.
The default behaviour is a bare emacs which starts damn near instantly. If you start adding stuff then it takes time to load, but at this point you should know the daemon is an option.
I think that the best default approach would be to start as a normal emacs process but revert to emacsclient behaviour (i.e. just open a new frame) if a running instance of emacs is detected.
This is what web browsers do, for example.
The best way to run emacs IMO is to use "emacs --daemon" to spawn a single daemon process, and then connect to it using emacsclient. Then, startup time is instant!
I use the GNU Shepherd init system as an unprivileged user to manage my emacs daemon, and other things like gpg-agent.
The real benefit of 'emacs --daemon', for me, isn't the faster client startup time, but the unification of the many programs that may spawn $EDITOR. Rather than each one spawning a new Emacs process, these programs spawn a client in the window I already have open where I can access everything else I was working on. On top of that, I use the ItsAllText extension for Firefox to edit text fields inside of that same Emacs instance, too. Very convenient.
The first line of my ~/.emacs is (start-server). /usr/bin/emacs is launched once and runs forever. I spend nearly all my time in emacs, so there is nothing to maintain/monitor. If emacs dies, it is rather obvious.
I start emacs once every few weeks, and that's mainly just to do a reset when I finish a project or get to a safe point and want to get a clean slate. The startup time for Emacs is never an issue for me.
well, that's for terminal mode. With a window manager, most application has similar start up time which I assume is caused by similar xorg routines being run.
However, running Emacs in daemon mode does reduce this to instant. Not sure why this is.
On my current machine (OSX w 16 GByte RAM), Emacs built with Homebrow as native GUI application (HEAD, lots of bells and extras enabled) with 10+ buffers Emacs consumes 127 MBytes.
In comparison, Finder consumes 300+ MByte, Firefox 2+ GBytes and Slack(!) 500+ MBytes. And the Activity Monitor utility supplied by Apple I used to check these numbers uses 130 MBytes.
Yes, Emacs consumes 8 MBytes and more. But Moore's law has really fixed that problem. And in comparison with a lot of other SW, Emacs is not the SW application I would accuse for being bloated, quite the opposite in fact.
Slack uses so much memory because it's carrying around the baggage of its own webkit session. It's little more than a web browser that just connects up with slack, and thus has all of the bloat and ugliness of javascript.
To be honest, I very rarely seen 8mb or more back then, when I ran Emacs on a VAXstation with 64mb of ram. Usually it was much less, but, OTOH, org mode did not exist.
This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the "good operating system, bad text editor" joke you'd see on Slashdot or whatever.
But nowadays while Emacs clocks in at a dozen MB, it's still smaller than what I'd consider "light weight" editors like ST3 and Atom, and minuscule compared to the likes of IntelliJ, Eclipse, or XCode.