The problem is that it isn't a good enough Lisp engine to be very good at anything beyond the great text editor, which it has been since the early 1980's.
Avoiding the really hard problems and building a better emacs browser doesn't really help anyone. At some point, people will realize that the concept behind Emacs is great but could be better done in another high performance language. JavaScript in a browser? Clojure?
What? Emacs isn't a big Lisp interpreter. It's a text editor that is extensible with Emacs Lisp. Sure it contains a Lisp interpreter, but saying that Emacs is only a Lisp interpreter implies that the entirety of the text editor is implemented in Lisp, which is clearly not the case.
I use Emacs as a text editor, which means I use it to edit anything that has text. Granted that is a huge part of my computing needs.
I don't want Emacs to be able to do anything. I already have an operating system and a text editor.
Nope, it's mostly a Lisp interpreter. Stallman had to build some of the low-level stuff in C then he built the rest of the editor in Lisp.
"We used the same idea here (in the hybrid technique), that most of the editor would be written in Lisp, but certain parts of it that had to run particularly fast would be written at a lower level"
There's some kind of paradox here. You say it's mostly a lisp interpreter, but then, also, mostly editor functionality written in lisp. I'm not sure you can have it both ways...
It's lisp man, of course you can have it both ways. Code is really data, your program is actually your environment, your editor is actually a giant lisp program with a built-in lisp interpreter. Or is it a lisp interpreter with a built-in editor? I dunno. I'm off to install this release :)
Without Lisp, or something very like it (and javascript is not good enough), I would not use emacs.
I use emacs as a source navigation and exploration tool, even more than for text editing. Its ability to run code customized to the language and projects I'm working on is far more important than its ability to edit text.
I actually don't like a lot of its text editing functionality, and had to work hard to get things like selection, tab indenting, scrolling etc. to work in a way that didn't drive me up the walls. I had to give up on virtual space, one of the things that stopped me learning it 10 years ago. It's also very hard to record keyboard macros without accidentally cancelling (I tend to press C-g reflexively when I type a wrong shortcut); I use multiple cursors these days instead, even though that is much riskier / harder to use when you can't see the whole buffer / all edit locations on screen at once.
A browser, I don't really need that per se - unless it's linked to library documentation. But it's hard to integrate modern docs without at least understanding HTML, if not HTTP. So I can see the need for a browser implementation.
Emacs is in essence, a virtual machine: http://www.emacswiki.org/emacs/ByteCodeEngineering. That's why you are able to do so many things with it. The whole text editor GUI is just a frontend the Lisp interpreter. You can think that Python comes with an interpreter that runs in terminal. Emacs comes with an interpreter and a whole GUI frontend for its interpreter, not merely a terminal interpreter with a prompt. That's why you are able to evaluate any Emacs Lisp code ANYWHERE.
If you only use Emacs as a text editor, that's fine for using a subset of it. Just like a casual user uses Linux without never using its underlying tools in the terminal.
> saying that Emacs is only a Lisp interpreter implies that the entirety of the text editor is implemented in Lisp, which is clearly not the case.
With this argument, I guess Python is also not an interpreter because clearly it is not entirely written in Python.
The actual Lisp interpreter is rather tiny compared to the other stuff. Just do a 'ls -l *.c | sort -gk 5' in the src directory. By far the largest file is xdisp.c, which is the redisplay engine, and only a handful of people in the world dare to touch it. Next comes input handling (keyboard.c), then then dealing with coding systems, terminals, win32-API, image handling, windows, processes, buffers, and much more. AFAICS the first file to actually deal with Lisp is lread.c and comes in at #21.
http://cedet.sourceforge.net
The problem is that it isn't a good enough Lisp engine to be very good at anything beyond the great text editor, which it has been since the early 1980's.
Avoiding the really hard problems and building a better emacs browser doesn't really help anyone. At some point, people will realize that the concept behind Emacs is great but could be better done in another high performance language. JavaScript in a browser? Clojure?