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.
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.
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.
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.
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.
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
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.
> 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.
> 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 yet Emacs is fast, hmmm.