Hacker News Reader

Comment by gaius | Hacker News Reader

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app

And yet Emacs is fast, hmmm.

View on HN

Emacs doesn't offer a fraction of the graphical flexibility that Atom does. How would you do any of the below?

https://benmccormick.org/2016/01/11/the-most-interesting-ato...

The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs.

It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.

Forgive me for being skeptical. Where is this git-time-machine equivalent?

What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit

The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.

The first question was "How would you do any of the below?" which is easier to answer when it's apparent what problem an extension is solving.

The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part.

I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.

https://github.com/pidu/git-timemachine

Magit

Apologies for the slow response.

I don't know on the actual charts, as I just don't use that sort of thing. Seeing anything git related and I think magit. Pretty much period. That is, I didn't see the chart.

You can do graphics in emacs, though. I typically just use it to show email and inline images for org-mode.

I did actually know Emacs can do images, as per the well-known opening screen[1], but it's very Web 1.0.

[1] https://i.stack.imgur.com/IOd6q.png

Ha, I forgot about the opening screen!

Calling it "web 1.0" seems amusingly critical. That said, taking it back to the question at hand, there doesn't seem to be a technical reason you can't do the images in the time machine thing. Most of my emails in gnus show graphically in a correct way. (Some of the more heavily formatted ones mess up, but usually not terribly so.)

For a better idea of what it can look like, enable LaTeX previewing inline in a buffer. Again, I'm usually in an org-mode buffer. And I confess I probably can't fight off a "web 1.0" argument. I have not gone for more modern UIs for some time. :( I grant it is a preference, but helm and similar UIs are much preferrable to me over what I typically see in the newer apps.

It wasn't a value judgement; it's 1.0 more web than my own editor ;).

Emacs is very slow to start. Especially once you have a few extensions and addons.

Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster.

But many people still run Emacs in a daemon. This preserves your sessions between “running the editor” and prevents ever having to restart.

> Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster.

The changes Atom is looking at regarding user-side snapshots seems conceptually similar.

This really scares me because the emacs unexec operation has had a ton of safety related bugs.

Also, it’s a portability PITA, and it can be a serious impediment to bringing new developers on-board. Emacs is looking (in the long-term, serious project sense) to replace or remove dumping and unexec if it can.

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

> it doesn't really matter because you just run a daemon and connect to it.

I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post.

As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds.

Here's blog post that describes this feature:

https://brainlessdeveloper.com/2017/12/27/making-emacs-work-...

The blog post above actually overstates how difficult it is to start working with Emacs in this way. It's dead easy.

On macOS, I have the following defined in ~/.bashrc:

   alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
   alias e="et"
   alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\""
   alias et="emacsclient -t -a ''"

Explanation of the `-a ''` option per `emacsclient --help`:

   -a EDITOR, --alternate-editor=EDITOR
       Editor to fallback to if the server is not running
       If EDITOR is the empty string, start Emacs in daemon
       mode and try connecting again

These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.

So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.

The old joke was Emacs meant Eight Megs And Constantly Swapping.

Except now you get less functionality in 800M at least https://jinolabs.com/article/12232554/atom-editor-uses-more-...

Emacs' display engine, input handling, etc., are written in C.

So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.

Their problem is not technical, it’s ideological

That would impair the stated goal of "hackability."

Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.

If you read the post, that is mostly the work that they're describing.

> There’s no reason the Atom team couldn’t optimize their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.

I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.

Your point?

Write slow javascript, get slow programs. It's not a crazy concept.

Edit: typo

Emacs is written in Elisp which is a dynamic language just like JavaScript

emacs core is written in C. All of your extensions are mostly in elisp. A few run servers and talk to them though. (Eg ensime)

> Emacs is written in Elisp which is a dynamic language just like JavaScript

All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.

And Electron’s are written in C++, so I’m unsure what your point is.

Yes and no. E.g. Atom does its line layout and rendering in Javascript, which manipulates the DOM, and Electron then renders things using C++ code: http://blog.atom.io/2017/06/22/a-new-approach-to-text-render....

Emacs' display loop is tens of thousands of lines of C that directly calls the native text-rendering API: https://www.facebook.com/notes/daniel-colascione/buttery-smo....

Reply on news.ycombinator.com