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

[Lennart Borgman]

On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <address@hidden> wrote:

> Date: Sat, 18 Jan 2014 00:13:50 +0100
> From: Per Starbäck <address@hidden>
> Cc: David Kastrup <address@hidden>, "address@hidden" <address@hidden>

>
> 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?

That's not what Richard was saying, not at all.  There could very well
be a "simple" editor that is part of the GNU project (perhaps there is
one already).  No one said the GNU project must have only one editor.

But this is of course not really true:
 

> > Emacs is never going to be as easy to learn as simple
> > editors, because ease of learning is not its priority.

There could be a setup of Emacs that is as easy as any editor to learn. It is the advanced features that will take time to learn.

I guess that we are really discussing is if there is an advantage of such a setup. In the light of that there was a whole new editor (gedit) created I think there could have been a better route. Emacs could probably have provided everything that gedit gives.

I also guess it would have been less work. And there would have been a larger community using and working on Emacs.

This does not mean, I think, that the creating of gedit was a bad thing. There are of course things on the positive side too. Those that created gedit might speak better about that.

I believe the way forward is being open minded about plus and minus. In the history and future. Everybody here has the capacity to be that. That is what lead us to use Emacs, isn't it? ;-)