Sorry, I should have clarified; AFAIK, egg is not faster than magit, but I haven't really played with magit. My comment on speed was aimed at the article complaining about slow IDEs as git interfaces. When I run emacs, "slow" isn't the word that comes to mind, especially when compared to other IDEs (and I'm talking about with all sorts of IDE-type features added on to emacs). Egg is pretty fast, though.
That's not true for me. I'm forced to use older computers and/or virtual machines over overloaded networks. I had to recompile Emacs with -O3 and other optimization switches to get barely decent performance on the latest versions of Emacs. That's why I've switching a lot between Emacs and Vim recently.
Honestly, I think you need to check your distro's emacs setup. Most of the time the crappy slowness comes from all kinds of badly written elisp modules that you really don't need (which is the wrong way to do it anyway). If you just load the pure emacs image, it's VERY zippy.
I'm not so sure; people keep adding stuff to emacs, and performance doesn't really seem to be a priority. To give a couple examples off the top of my head:
- A recent version of emacs changed the default shell history command to show live search results (like bash does), but the emacs implementation was ungodly slow if your bash history was longer than a few dozen items (waaay slower than a real terminal interactive bash search). Moreover, it completely locked up emacs while doing the search (since emacs is single-threaded and synchronous). After the suffering got high enough, I finally tracked down how to revert to the old behavior.
- The latest emacs python mode for some unknown reason would freeze for like 10 seconds when opening certain python files. Rather than track it down, I went back to using the latest python-people python mode (for some reason, the emacs people insist on writing their own python mode, rather than using the one the python people wrote). The python-people python mode doesn't lock up, but narrow-to-defun takes maybe 300ms (not terrible, but clunky feeling; way worse than instant), for some reason.
- Or check out this awesome, high-performance code from the function comint-exec:
;; Feed it the startfile.
(cond (startfile
;;This is guaranteed to wait long enough
;;but has bad results if the comint does not prompt at all
;; (while (= size (buffer-size))
;; (sleep-for 1))
;;I hope 1 second is enough!
(sleep-for 1)
(goto-char (point-max))
(insert-file-contents startfile)
See that sleep-for? That's an awesome built 1-second pause while waiting, for example, for an emacs shell to startup if you have a custom .emacs_bash defined.
There's lots more stuff like this. Emacs is a giant ball of elisp mud that's perpetually half-broken, half-implemented, or slow...but it's still the best thing going, by more flexible and more useful than any other editor out there (AFAIK).
But I'm not convinced it isn't possible to do something as flexible as emacs without all the random breakage and general lack of concern for performance. Think maybe replace elisp with LuaJIT, and take cultural inspiration from the make-it-fast ethos of git and the make-it-correct ethos of sqlite. Something like that.
Oh, and also, unlike every modern day attempt at an editor, it should still support running in a terminal, because terminals are still damn useful.
So yeah, could someone get on that please? Thanks :)
Emacs could gain a lot of performance boosts with some significant changes to its architecture. It would be a lot of work to do and doing so requires a set of skills that are much less available than other software engineering skills unfortunately. I am hoping either that occurs or there exists a viable replacement for Emacs that incorporates the improvements more easily due to starting with a blank slate.
Proprietary programs are a deal breaker for me as far as contributing to them in my free time a great deal due to how frequent they go out of business and lose support. So, a new iteration of Emacs would require a very free license for me to have confidence that my efforts won't be wasted in a short period later.
I am hoping that Light Table is released with a license and degree of openness that provides a similar degree of hackability as the Emacs platform does. If that happens I think I will make a lot of effort to bring it up to speed with features Emacs has but Light Table doesn't at the time.
Chris Granger has made a lot of smart design decisions that really appeal to me about Light Table. His point in one presentation that while Emacs and VIM are fantastic at text related operations, there doesn't exist something comparable that has both great support for text and great support for visualization.
That is a thought that really resonates with me. Having fantastic graphing capabilities and embedding of graphic tools such that the work flow can exploit both graphics manipulations and text operations would be a huge boost in capabilities, something which adding to Emacs would be much harder due to so much legacy code in the platform that will have to be accommodated in the process.
As an example, people have really wanted to move Emacs underlying language from elisp to common lisp for a long time, but it is such a massive undertaking and transitioning the community to using it would be so difficult that (without a team to work on it constantly) no one has succeeded in doing so fully.
Light Table's decision to use any language which can compile to javascript as its backend and use node-webkit as its front end results in a lot of features that are free in the process that are very nice to have for tool building.
And Granger has made a point to customize the compilers for the languages it supports to glean even more information and manipulation of the languages in the process, something which I hope is kept up as its support expands.
I absolutely love its instarepl design that is motivated by his idea of real time debugging. Combining that with Crockford's context or scope based coloring concept would be a massively useful feature set for development and tools to be able to exploit. The scope based coloring isn't something that Light Table has already or something Granger has mentioned adding, but it is something I hope enthusiasts can add assuming the platform is sufficiently extensible.
Granger's earlier idea of breaking down the environment based on functions as the smallest unit of focus instead of a file is another brilliant design concept that will be available in the future (according to another presentation he did).
So, I am very excited about its potential as a replacement for Emacs that takes that idea and makes it even better based on adding modern developments, and Granger seems to really appreciate open source and has a willingness to contribute towards that.
So, I am hoping that somehow the Light Table team is able to both charge for the tool and make it fully extensible as well as remove the potential for abandonment of the platform to result in a volunteer's effort being wasted, such as fully porting SLIME (a very exceptional lisp development environment that emacs has) to Light Table as well as ESS (a statistics development environment which could benefit from more graphics potential being available) that emacs has.
I think Light Table will already be a killer app for REPL centric platforms by the 1.0 release, and languages which have excellent REPL support and debugging is what I mainly use already. Adding the other features I mentioned will make it unquestionably the new state of the art for that context.
