All of these things *could* be fixed, if it was worth it to someone Numbers represent perceived difficulty of fixing I have listed

them in an earlier post My opinion is that in many cases the baggage in Emacs outweighs the good Hours and hours of customization is required to get it to work the way you want it to.

There are plenty of virtues in Emacs

Lacks a good text editor

I may be wrong on some of these points Feel free to correct me. Flyspell can cause laggy editing if function B changes the value of a variable with setq, function A's variable is modified some extensions depend on this functionality, resulting in one of the worst imaganible programming practices if function A calls function B, function B has access to function A's local variables. It will likely always stay single-threaded

lots of instability: if I resized my window to fast, it would crash this is just my opinion: Emacs crashes Sometimes, when Emacs calls a shell process that never returns, the whole editor freezes c-g (quit) will not save you. you have to find the pid of the offending process and kill it

Emacs-lisp is EXTREMELY stateful, concurrent programming in it would be a nightmare

fortunately 'let' will restore values ido mode is an example - if you want to implement a buffer filter, you add it as a hook that modifies the local variable ido-tmp-buffers or something like that.

lacks several built-in hooks, requiring nasty work-arounds that just don't work all the time variable scoping is just weird no core concept of an "Emacs project" If a lambda gets executed within the context of your function (or somewhere in a deep nested call), it has access to your local variables. Otherwise, it doesn't No closures in emacs Syntax Highlighting You have to use defmacro to generate a lambda that has the value of the variable embedded inside of it many extensions end up implementing their own version of commonplace utilities Core library limited Emacs Baggage No core understanding of packages, namespaces, versions, etc. Emacs-lisp

no "window focused" hook.

worked around this by spawning a process that watches the current window and notifies Emacs every time it changes nasty

it's difficult to tell when the buffer has been changed each extension has their own opinion of how projects should be defined None of them play well with one another

font-locking (like in ruby mode and emacs-lisp mode) break down for apparently unpredictable reasons slow Regular expressions lack several features such as negative/positive look-behind/look-ahead and recursion, making font-locking more difficult.

defmacro is cool, but this is not an elegant workaround because every function is global in Emacs, this ends up getting very noisy very fast

General problems No horizontal scroll bar

ELPA has been created, and is helping in this regard, but it feels a long way out It's painful to depend on other libraries, unless they get accepted into "core Emacs" (which is a slow process) no one wants to fix it because there's no tests around it and because Emacs punishes you for small methods ido.el is probably the worst example of this but it often will break when you restart Emacs because of a load-order dependency. causing you to often have to tweak Emacs more to get it to start-up again punished for creating small methods (encouraging nasty, hairy, long complicated functions)

Painting window is slow, still

on today's modern computers, it should be lightning fast may just be NextStep integration? It's a nice attempt, but it's a big hack, and Emacs crushes one of my 2.6ghz cores to do something as simple as "delete this line" Emacs wasn't designed to support multiple modes in a buffer .  Making everything use autoload is helpful, but requires a lot of work. the editor receives them as Control-command-<clear>, or control-command-265781959   Extending things that are loaded is especially tricky and requires a level of black magic. Seems to lead to more bad programming practices probably just a Emacs-NextStep issue very unpleasant experience auto-indentation breaks in the most inconvienent way

Slowness

MuMaMo mode is SLOW (using html, javascript, and ruby modes simultaneously in one buffer)

No namespaces, no private/public methods
Slow startup time (even when compiling everything) Major selling point of Emacs is it's extensibility.  Extending Emacs adds considerably to the debt in Emacs Key Bindings Default keys are painful Emacs debugger just quits working after a while... you have to restart emacs to get it to work again Some keys, such as Command-control-k, can't be bound

It works while you are developing it

(TextMate avoids this by making every extension isolated from eachother) Probably related to the overly-stateful nature of emacs lisp

No commonly accepted "ergonomic" keybindings for Emacs - everyone who cares ends up rolling their own

Different keybindings for everyone

It's difficult to visually discern between buffer-local variables and global variables if they aren't, the issue only manifests when using a mode concurrently with two buffers It's hard to remember to declare every variable that should be declared as such

No way to globally remap "mouse-2"

Mac's don't have a mouse-2.  Just a mouse-1 and a mouse-3 (Mouse-2 is middle click in emacs) What I would call a window is a frame in emacs  what I would call a frame is a window in Emacs

Maybe mighty mouse has it?

Buffer-local-variables Backwards terminology

Window and Frame

Documentation on Emacs wiki is just a mess some extensions are publicly available as wiki pages Nothing is automatically tested. Therefore, most developers are afraid to improve other people's extensions

"Yank" to paste? Emacs community is generally disorganized Community Emacs lacks automated testing discipline "Kill" to cut? I would think of "kill" as in get rid of this and don't save it anywhere