6 ms·

> 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

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

sklogic 11y ago
Eight Megabytes And Constantly Swapping.
- melling 11y ago
  That fits in level 3 cache these days: http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,2041-10.html http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,204...
  - trothamel 11y ago
    Yes, but if you want to do something else with your computer, you'd have to swap it out to proper RAM.
    - JoachimS 11y ago
      You mean like how it normally works? Of course it will be swapped out - into the GBytes of memory you oomputer is equipped with.
- JoachimS 11y ago
  Yes, that was very funny - about 20 years ago. 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.
  - Sanddancer 11y ago
    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.
  - sklogic 11y ago
    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.
- rekado 11y ago
  Yeah, it's a problem on my i386 IBM P70 which I recently upgraded to 8MB.
  - snaky 11y ago
    That's funny the modern Thinkpad flagship mobile workstation model is called P70 exactly.
lottin 11y ago
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.
- jdreaver 11y ago
  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!
  - dominotw 11y ago
    then you have to maintain/monitor that daemon, seems like too much work.
    - cle 11y ago
      If only someone made something that could monitor daemons and make sure they stay running...
      - dominotw 11y ago
        then you have maintain that thing that monitors the daemons.
      - unsignedint 11y ago
        If your system is using systemd, you can create a service file that does that under --user. I manage some user daemons that way.
    - deleted 11y ago
      [deleted]
    - davexunit 11y ago
      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.
wmil 11y ago
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.
rekado 11y ago
> This feels like a very out of date sentiment to me. Yes! It's as if these sentiments were not actually experienced by those who propagate them. It's cultural baggage.

sklogic 11y ago

Eight Megabytes And Constantly Swapping.

melling 11y ago
That fits in level 3 cache these days: http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,2041-10.html http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,204...
- trothamel 11y ago
  Yes, but if you want to do something else with your computer, you'd have to swap it out to proper RAM.
  - JoachimS 11y ago
    You mean like how it normally works? Of course it will be swapped out - into the GBytes of memory you oomputer is equipped with.
JoachimS 11y ago
Yes, that was very funny - about 20 years ago. 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.
- Sanddancer 11y ago
  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.
- sklogic 11y ago
  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.
rekado 11y ago
Yeah, it's a problem on my i386 IBM P70 which I recently upgraded to 8MB.
- snaky 11y ago
  That's funny the modern Thinkpad flagship mobile workstation model is called P70 exactly.

lottin 11y ago

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.

jdreaver 11y ago
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!
- dominotw 11y ago
  then you have to maintain/monitor that daemon, seems like too much work.
  - cle 11y ago
    If only someone made something that could monitor daemons and make sure they stay running...
    - dominotw 11y ago
      then you have maintain that thing that monitors the daemons.
    - unsignedint 11y ago
      If your system is using systemd, you can create a service file that does that under --user. I manage some user daemons that way.
  - deleted 11y ago
    [deleted]
  - davexunit 11y ago
    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.

wmil 11y ago

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.

rekado 11y ago

> This feels like a very out of date sentiment to me. Yes! It's as if these sentiments were not actually experienced by those who propagate them. It's cultural baggage.