The problem is that while EMACS does have a reasonably good mail reader (VM, I use it constantly) and a very useful IDE bits and pieces and even a web browser, none of these applications are really great.
I think the reason for this is that it is really hard to write applications for EMACS. I tried it once. I started writing a spread-sheet application. The idea was really cool (I thought). The actual text file would contain a TeX tabular environment with each table cell corresponding to a spreadsheet cell. The metadata about each cell would be stored in a TeX comment after the body of the cell, so ever cell would have it's own line in the file.
Then Emacs would hide the metadata (make it invisible) along with the newlines, and would insert enough white space into each field that it all lined up like a table. In each cell you could toggle between showing the value, the formula, or the formatting information.
I even got some of this working and could do (very) simple calculations. But I wasn't too long before I realised it was all too hard.
When telling emacs what to display, and how to handle different parts of the display, and how to handle different input keystrokes, you have to work at a very low level.
With display, emacs thinks it is just showing a text buffer, with certain characters displayed different ways. They way that data is stored in the buffer and then hidden is very unnatural.
With input, you have to redefine every keystroke. You cannot just say "upwards movement means X", but you have to redefine every key that could cause upwards movement and get it to do the "right" thing.
What is really needed is a propery MVC arrangement - Model, View, Controller.
The "Model" replaces the current buffer. Instead of a list of characters some of which have attributes, the model would be an arbitrarily complex data structure which contains text and other info. Quite possibly it would just be a Lisp list structure with text-strings as one of the sort of objects that can be stored.
The "View" would be an aspect of a window. Just making the view window-dependant rather than buffer dependant would be a great step as that would make it a lot easier to have two different views of the same data.
The "View" information basically supply templates to convert the different sorts of information in the "Model" into display. Providing a useful range of primitives would be a good challenge, but with lots of examples of rendering languages to follow (or not) such as HTML, it should be quite do-able.
Finally the Controller would provide the basic move/ change/ search/ mark/ cut/ paste controls that are already provided very effectively by EMACS, as well as extra controls that are specific to the model in question. Many key bindings would bind to abstrct controls (like "UP", "DELETE") and these could have a different meaning for each different sort of object in the Controller.
Naturally you would need support for read/write routines to convert between the internal model and external data formats, but that is usually the least of the worries.
With this sort of proper abstraction, write application is NewMacs would be a whole lot easier, so there would probably be more of them, and they would be better.
Just as two final examples of features of current emacs applications that I blame on the poor internal model.
1/ VM, the mail readers, is a bit slow on large mail boxes, particualarly when purging changes or loading new mail. Part of the reason is that it has to generate and render the entire message list of every virtual mail box that is current, even if it isn't being displayed. With a better model, only the the part of the message lists that are actually visible in a window at any given time need to be rendered.
2/ flyspell - a rather nice on-the-fly spelling checker, often gets confused about the word you are editing and might highlight half of it, or something odd like that. With a better model to work with, this need never happen.
