Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Per Starbäck]

Richard wrote:

> Emacs is never going to be as easy to learn as simple
> editors, because ease of learning is not its priority.
> The priority is effective editing for people willing to learn.
> We won't sacrifice that goal for ease of learning.

I find this remark about "simple editors" interesting, not just in
terms of Emacs, but of the
whole GNU system. I have always thought of GNU Emacs as *the* editor
in GNU, that is
the default editor. Do you think a GNU system ideally instead should
have some other
("simple") editor as the default editor? And that using Emacs should
be an active choice for
those who are ready to learn something more powerful? This is news to
me in that case.

I still think Emacs should be *the* editor in GNU, and that it is
perfectly possible to have it
like that without sacrificing the goal of effective editing. New users
that only have used at
most simple text editors don't really need or expect much in my
experience. They type text, move around with scrolling wheel and arrow
keys, and look for anything else in toolbars
and menus. They can certainly do that in Emacs.

(What's the point of them doing this in Emacs instead of in a simple
text editor? Because
some of them will become power users, and then they'll already be in
Emacs when they
start looking for more functionality. It's also a point that they can
be thought of as doing
their stuff in Emacs, because then distribution maintainers are more
likely to steer users
into using Emacs. It's not as if all new users make a choice between a
"simple" and a
"powerful" editor, but most of them will use whatever is the default
one on their system, at
least in the beginning, not knowing about the alternatives, and I
think several GNU/Linux
distributions currently don't install Emacs by default at all.)

> However, when we can make Emacs easier to learn
> at the cost of only _development work_, with no sacrifice in
> the principal goal, why not do it?

I agree. But there is another cost as well, which I think is what we
much more often hear
experienced users object to, namely adjustment costs *for them*.

I like the suggestion of renaming "window" into "pane". It removes one part of
(nowadays) peculiar terminology without big adjustment costs at all
(because of aliases
that would exist).