This really is the biggest argument.  Emacs takes more time to learn
than any other environment I've used.  But, Emacs is the easiest to use
interface I've ever come across, by a very very wide margin.

[Robert Uhl <eadmund42@NOSPAMgmail.com>]

Robert does have a point; however, one needs to take into account that
it is very difficult to judge the quality of an interface if it is one
that is very familiar to you or if the inner workings are obvious to
you.  this is why programmers often make bad UI designers: we are
intimately familiar with the inner workings, and to us it is okay if
the UI is just a thin layer on top of a system we've made.

(I'd say the web is a better showcase for this.  there seems to be no
end to the number of websites that have awkward interaction modes.
nor do people seem particularly shy about adding "just one more" thing
to an already crowded interface -- because they're blind to the wall
of complexity it presents to the occasional user).

editors like Emacs is not something which is designed for the casual
user, so what the casual user thinks is irrelevant.  (also note that
the definition of "casual user" has changed).

-Bjørn

Did I say it was for the "beginner" to decide? No, I said "novice-to-
intermediate".

How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.

Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky. You should be able to see
what the hell you're doing and navigate easily. Applications that not
only eschew normal methods of navigation of the interface, but force
you to fumble your way between the help and the task you're trying to
do, are definitely clunky. An analogy to a genuine emacs experience:
you enter a workshop with some raw materials and tools. Unfortunately
there's no big ceiling lights so you can just flip the switch by the
door and then always be able to see where everything is. Instead
there's little lights here and there by various specific tools and
storage areas, and in one area a map of the place with switches to
control the lights. So first you have to fumble around until you
happen upon the map/light controls. Then you need to (in the dark!)
hit the switch for the map/light control area itself. (Now you've
found the help and gotten it to be the active pane, er "window".) Now
you need to find the tool you want on the map -- OK, that was easy.
Now you turn on its light. Oh, hell -- the light on the map/light
controls has now gone out though! That also included the instructions
on using the specific tool. You can go to and use the one tool, if you
memorized those instructions, but then it's back to the darkness...
(You find the help on doing a particular thing, then can't get back to
the document to do it because of clunky navigation. So you go back to
the help on switching windows, and now you can flip back to the
document. Only you realize you can have the document and help open at
the same time, but the only time the document has focus is when the
help is open to "help on switching windows", which makes this rather
useless! You end up having to memorize the help, because *you can't
have arbitrary parts of the help and your document open side by side
and be working on the document*. All because you can't simply tab or
click to the document. At minimum, you have to *memorize* some arcane
key controls for switching panes ... er, "windows", that are totally
unintuitive and unlike what is normally used.

Oops. The interface design is a nightmare. The most basic requirement,
that it be easy to have the help open side by side with your document
and switch back and forth and navigate inside the help easily, is
broken. If you have to consult the help just to navigate the help or
to switch focus between document and help, then you're trapped, and
that is what happens with emacs.

I don't know why people keep harping about what version. It was
probably something in the low 20s, after an earlier try with one in
the upper teens. The interface never improved over that time -- the
biggest problem consistently being that whenever focus was
successfully transferred to the document window, the help window was
invariably open to the instructions for switching windows, so you
could never be doing something with the document and have the help for
that something available at a glance. Defeating the whole purpose of
having a help system. A separate printed manual would have been
better, if I could have spared the paper and toner, as I could hold
that off to one side of the monitor and flip through it and open it to
anywhere I wanted to, then go back to my document without even having
to think about it. Even though it would be at the price of no full-
text search capability -- not that I could ever get that to work in
emacs anyway. There was no apparent way to do a simple substring
search and click "next match" or "previous match" to navigate among
the hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.

As far as I can tell, it just is not and never was possible to get
started with emacs without a separate, outside-of-emacs cheat sheet,
or to be very productive at all without actually memorizing the damn
thing. Modern user interfaces require a minimum of memorization, most
of which is basic, standard stuff that is the same from one app to the
next, so you already know it all -- your clicks and double clicks,
your alt-tabs and alt-enter-for-properties etc.; application-specific
keyboard shortcuts can be learned as convenient. Infrequently used
commands you can stand to hunt for in menus. When you find you use one
frequently, you can try to learn the keyboard shortcut -- and you can
find it without even consulting the help, simply by finding the
command's menu item. Every time you want to use the command but can't
remember the shortcut you just find it in the menu and activate it
from there, and see the shortcut while you're at it, helping to
eventually memorize it. And the commonest sorts of File and Edit menu
items have near-universal shortcuts, the big variation tending to be
whether Redo is shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.

But you can start using it right away with low productivity, and
increase your productivity with proficiency and learning (optional)
shortcuts, chiefly those to the commands you happen to use a lot.

Not so emacs, or most other unix-heritage tools. Those you can't use
in any nontrivial way without ascending a sheer cliff of memorization
*first*, before doing a single useful thing.

One person elsewhere in this thread even went so far as to suggest
that to avoid having a similar hurdle with every application you just
use emacs for everything. If you like being claustrophobically trapped
in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Also if you like having zero productivity in every single task instead
of just one until you've scaled the El Capitan of user interfaces. On
the other hand, you can avoid having a similar hurdle with ANY
application by simply using standard GUI apps developed with Mac and
Windows users in mind. I hear they even have them for Unix now --
technically including everything written for MacOSX as well as modern
WMs on Linux and probably *BSD.

(Use emacs for everything? That's like suggesting I move all my tools
*into* that dark place with the screwy lighting system, rather than
*out*. Me, I'd rather just avoid that place, or if necessary bring in
a big bank of floodlights and install them, and the sensitive artiste
who originally architected it be damned. Which is what Xah started
this whole mess by suggesting, in effect.)