Making Emacs more welcoming to newbies has been discussed time and again on the Emacs mailing lists. But the general consensus (one that I happen to agree with) seems to be that "learning Emacs the hard way" is, generally, the right way.
As just one example, I think that emulating the inferior Undo/Redo paradigm (using the Ctrl+Y/Z binding familiar to Windows and MacOS users) hides the full power of the Kill Ring and may mean that some Emacs users will never get to know about it.
I know it's a topic of heated debate and I don't mean to start this debate all over here on HN. I just thought it would be good to point out that newbie-friendliness is continually being considered and reconsidered by Emacs' maintainers, but (for the most part) usually rejected, and I think for good reasons.
See this thread for one example, there are many more if you care to look for them:
I am an emacs user, I love it, but I avoided it for over a year because it made absolutely no attempt to play nicely with new users, emacs doesnt need to be so hard to new users, it does it on purpose
Emacs' ugly, clunky, non-standard 1970s way of doing everything is so closely bound to all the good things about Emacs that you can't have one without the other. People always try (for good reason), but then Emacs doesn't work as well, and the efforts evaporate.
I've also never really understood the benefit of not having "redo". What am I gaining in exchange for the annoyance of having to hit an arrow key before being allowed to "undo the undos" and duplicating a big chunk of my undo history?
Regarding your second issue, I'm happy with the undo system as it is, but if you're not you could try and see if this works better for you: http://www.emacswiki.org/emacs/UndoTree
Also, instead of cursor motion to "break" the undo operation, you can use C-g. I.e. C-g C-_ will redo (undo the last undo) rather than going back further in the undo history.
However, as somebody else mentioned, you should also check out the undo-tree plugin. Some of my friends really like it.
However, there's room for improvement. In particular, there's packages that turn undo history into a tree.
Modern does not equate to better. Most of the complaints listed boil down to "Because it's not Windows". Intuitive is just what you've seen before...
I suppose it's ridiculous to expect and hope people to care about their tools enough to customize it for what they use and want. :-/
I spend probably 30 minutes each month on average dinking with my .emacs to tune it with how I'm using emacs, remove hassles, etc. These days it's extremely intuitive and useful for my work. I maintain similar keybindings between multiple operating systems, customized for my preferred keyboard and hands; a variety of functions have been put together to ensure that what I do gets done very efficiently.
Because emacs was extensible trivially, was programmable, I can spend the time and the learning curve to invest in my primary tool. That's what, in my opinion, emacs is about.
That is a marvelous aphorism.
I am especially interested to see this get off the ground, though, as even the simplified "starter kits" above still require a certain non-trivial level of contextual Emacs-knowledge -- a simple binary with overly-sane keybindings and functional out-of-the-box would be a real contribution. I would have loved to use something like that myself about a year ago.
Also, I don't see the keybinding changes gaining any traction, because they would conflict with too many existing packages. As one of many examples, C-c (proposed for Copy) is already used for lisp compilation.
What would be the value of running in a browser specifically? The files you are editting almost by definition live outside the browser's sandbox. And if they're going to be managed server-side, it seems like there's a perfectly working 40 year old paradigm for managing files on a remote host.
I have 3 invites if anyone wants to email me (my email is on my profile).
The newbie issue is a typical red herring and excuse for the maintainers not to face the fact that emacs has huge design problems for all users, not just newbies. For example, the presence of dozens of redundant crappy packages associated to every function, included by default in the distribution (e.g. a dozen word-wrapping packages) means that one is likely to use a substandard tool and have problems. The fact that all add-ons are treated with equal weight means that the command you are looking for is hidden among thousands of commands, most of which are way outside the scope of what I need. The proliferation of buffers, leading to the proliferation of buffer packages used to search through lists of buffers? You have to be kidding me. The customization system in Emacs is not only a throwback to 1980s UI "design" but completely out of control -- all options, no matter how minute, are treated on equal footing even if most of them should be hidden or in subtrees. Not only this, but the customization options themselves are badly named, using quirky terminology which nobody uses except emacs.
In short, emacs is thoroughly polluted and needs an environmental assessment and large-scale cleaning project. This has nothing to do with newbies, it has to do with oldies whose dusty, dried-up packages need to be swept into the dustbin of history.
I can see relearning C for copy, as it's logical and would reduce the burden of switching between normal Mac/PC applications, but having J mean copy because that key would have been C in QWERTY is just too weird. I think about lots of Emacs bindings mnemonically: C-b, C-f and friends, obviously, or C-c because that's just the "bindings having to do with this mode" key, and you see it a lot when you read documentation -- in my head, it's a letter, not a physical position. I touch-type Dvorak pretty fast, but two-finger type it very slowly, because in my brain the letters are wired to finger movements starting on the home row.
A possible reason for this is that he has an "inverted T" for cursor movement (but on the left hand, like vi, not WASD like I believe PC gamers would be used to). If your set of cursor keys is based on the physical layout of QWERTY, like vi, it doesn't translate all that well to Dvorak (vi manages to be not horrible since J and K stay next to each other, but in this proposal J and K are not on the same axis), but if they are mnemnonic, like Emacs, there's no problem.
If the idea is to fit better with what the vast majority of "normal" people expect computers to work... well, normal people use the arrow keys. Telling them an invented abstraction is better because they don't have to move their hands from home row isn't going to sell them, I think.
(setenv "ERGOEMACS_KEYBOARD_LAYOUT" "dv")
Anyway the default Emacs keyboard bindings are just ridiculous, also ErgoEmacs is not good enough. I've my own keyboard bindings: http://goo.gl/jwwdG and I'm sure they can be much better. But it's just matter of taste.
The worst enemy of Emacs is its own UI and its own programming language for customization: elisp without multithreading support.
I used ergoemacs keybindings for a year or so. They are pretty slick, and definitely more ergonomically efficient than emacs default keybindings. However, many modes are designed around emacs default keybindings, and I eventually decided it was too much work tweaking every mode I used to conform to the ergoemacs setup.
If you stick to emacs core modes which are already customized, it's probably a good choice.
Recently I've started to do this on a small scale in my own .emacs file. Shortcuts I use every few minutes were hidden but too many multi-step keyboard shortcuts. Especially when I really don't need to duplicate the arrow and page-up/down keys with single-step shortcuts.
It's too bad it sounds like there won't be a Linux version.
Additionally, you should use the C-whatever bindings for moving around instead of the arrow keys. Once I learned them, moving around code became much simpler. Not only do you not have to move your hand to the arrow keys, but you also start using some of the more advanced moving commands that let you move by expression or paragraph (the latter is great for code because it takes you to the next blank line, which is usually what delimits parts of the code that are logically together).
You don't "enhance" Emacs, you hack it, extend it, write cool modes...
A better way to help new users with Emacs' daunting learning curve might be to make a game. A fun game would get that stuff into muscle-memory pretty quickly.
Apropos of nothing, "WINE" stands for "WINE is not Emacs".