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

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

[Drew Adams]

> > This said, the "what you call a window is called a frame"
> > is not nearly as problematic as "what we call window is
> > not what you think", so maybe renaming "window" to "pane"
> > would get us most of the benefit.
> 
> I think you're right there.  If we just get rid of the word
> "window", I think that'll fix most confusions.  

What confusion?  Is there really a problem?  Are you sure?

I've been dealing with newbie Emacs questions and confusion
for as long as most of you, and I don't think I have ever
encountered a user who had difficulting understanding what
we mean, once the terms are presented.

IOW, any contact at all with either the Emacs docs or a quick
Q & A has always answered any user questions I've come across
in this regard.  I have never, ever, encountered any
"confusion" here.  There is sometimes confusion elsewhere
(menu structure, keymaps, font-lock-keywords...), but no
confusion about windows and frames, once the terms are
explained.  No confusion, just initial ignorance, which is
not the same thing and which is easily remedied.

Seriously, have any of you encounted a user who could not
understand what an Emacs window and frame are?  Ever?
Really?

It's a faux probleme.  It says more about you who see it as
a problem than it does about any potential Emacs newbies.

And you ain't gonna get no mileage out of making a big
attempt to clothe Emacs in terminology the Emacs-ignorant
will immediately recognize.  There really is a wolf under
those sheepskins - Emacs is a different beast.  Everything
worth its salt has its own jargon.  Including Emacs.

Gratuitous differences in terminology for identical things
are something else.  But (a) that is rare (the Emacs thingies
are not really the same), and (b) even then it is not
important to toe the line.  Especially if the things are
identical, it is easy to learn new terms for them.

Examples of exceptional things that are identical in Emacs,
or nearly so, are "cut" and "paste" operations.  And as
others have already said, it is enough to point out the
Emacs terminology and the correspondences (when there are
close correspondences and not just faux amis) - which we
already do, AFAIK.

If you think that initiation into the ways and jargon of
Emacs is just too darn hard for today's kiddies, I'd say
you're not only pandering (demagogy), you're selling the
kiddies short.  Have confidence.  You learned Emacs, and
no, you ain't no smarter or tougher than they are.

(Now if we just get rid of Emacs, I think that would take
care of most confusion...)

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:

>
> What confusion?  Is there really a problem?  Are you sure?
>
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
>
> The difficulty is not understanding, but rather remembering. "What a h-ll
did they call that?"

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

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

[Stephen J. Turnbull]

Drew Adams writes:

 > > I think you're right there.  If we just get rid of the word
 > > "window", I think that'll fix most confusions.  
 > 
 > What confusion?  Is there really a problem?  Are you sure?

Agreed.  The important disconnect is between windows and buffers, and
even that isn't so hard for users to figure out.  I think people used
to recent browser interfaces will call buffers "tabs".

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

>
> Agreed.  The important disconnect is between windows and buffers, and
> even that isn't so hard for users to figure out.  I think people used
> to recent browser interfaces will call buffers "tabs".
>

I think that is a good illustration of how confusing different terms can
be... ;-)

"Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
for most new users.

[-- Attachment #2: Type: text/html, Size: 1081 bytes --]

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

[Yuri Khan]

On Tue, Jan 7, 2014 at 6:27 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> "Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
> for most new users.

+1.

The difficulty with Emacs that I had when I was a beginner Emacs user
and still have not completely gotten over, is the relationships
between buffers and windows.

In a typical $another_application, you have at the top level a window
or several windows. Each window may be split into panes, and each pane
may contain several tabs, each tab displaying a document. (In rare
cases, a tab may display a secondary view into a document that is also
displayed by another tab. Opening a secondary view is always a
conscious action on part of the user.) Closing the last view into a
document signals that the user is done with this document — this is
the time to ask any “would you like to save” questions. Otherwise, the
user is free to rearrange tabs between panes and windows. At every
point in time, there is a well-defined spatial position of each
document view — e.g. “the third tab in the upper pane of the window on
my left monitor”.

In Emacs, what you primarily have is a bunch of buffers which exist
without any permanent attachment with the UI. Then, you have frames
that may be split into windows, each window being a view into some
buffer. You cannot meaningfully talk about spatial positions of
buffers — they are essentially “everywhere” or “inside”. Or, if a
buffer is not displayed in any window, it’s “nowhere” and also
“inside”.

The model of Emacs is more flexible, but I find myself struggling with
it because I have to remember that there are hidden buffers and cannot
rely on the spatial model that my mind is accustomed to.

(Curiously, my other always-open application is Firefox that *does*
adhere to the spatial model. I end up opening a single window on each
monitor, and around a dozen tabs in each window. Then I have trouble
locating the tab I need since there are so many of them. So maybe the
problem surfaces when the number of entities exceeds my short-term
memory capacity, regardless of their organization.)

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

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 >> Agreed.  The important disconnect is between windows and buffers,
 >> and even that isn't so hard for users to figure out.  I think
 >> people used to recent browser interfaces will call buffers "tabs".

 > I think that is a good illustration of how confusing different
 > terms can be... ;-)  "Tabs" is a UI thing. Calling buffers "tabs"
 > would be very, very confusing for most new users.

Agreed.  I'm not suggesting that as Emacs terminology.  I'm saying
that users are going to see buffers as ways to show different content
in the same (GUI) window just like tabs do.

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Tue, Jan 7, 2014 at 3:07 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> Lennart Borgman writes:
>  > On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <
> stephen@xemacs.org> wrote:
>
>  >> Agreed.  The important disconnect is between windows and buffers,
>  >> and even that isn't so hard for users to figure out.  I think
>  >> people used to recent browser interfaces will call buffers "tabs".
>
>  > I think that is a good illustration of how confusing different
>  > terms can be... ;-)  "Tabs" is a UI thing. Calling buffers "tabs"
>  > would be very, very confusing for most new users.
>
> Agreed.  I'm not suggesting that as Emacs terminology.  I'm saying
> that users are going to see buffers as ways to show different content
> in the same (GUI) window just like tabs do.
>
> I see. ;-)
In a way, yes. It is a very useful concept. And one of the few things I
think should be presented to new users. The rest should be so familiar so
they should be able to start without knowing more. (If they are just to
Notepad or something similar.

[-- Attachment #2: Type: text/html, Size: 2079 bytes --]

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

[Joel Mccracken]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Beyond trying to remember, using current terminology is sends the message that Emacs is old, stubborn, and crufty, which is a problem when trying to introduce new users to Emacs.

On Jan 7, 2014, at 5:30 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
> What confusion?  Is there really a problem?  Are you sure?
> 
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
> 
> The difficulty is not understanding, but rather remembering. "What a h-ll did they call that?"
> 


[-- Attachment #2: Type: text/html, Size: 1673 bytes --]

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

[Drew Adams]

> Beyond trying to remember, using current terminology is sends
> the message that Emacs is old, stubborn, and crufty, which is a
> problem when trying to introduce new users to Emacs.

No, it does not.  If Emacs were invented from scratch today, it
would still need its own jargon.  Some of the particulars would
no doubt be different, but Emacs would still stand apart in both
behavior and terminology.

Emacs happens to be old.  And it happens to be different.
Being different does not send a message that Emacs is old, or
stubborn, or crufty.  Being old means that it is, well, old.
But that too does not send a message that it is stubborn or
crufty.

You are sending that message, by proposing that the terminology
be updated etc.  Someone new to Emacs and aware of this kind of
discussion can be forgiven for getting the mistaken impression
that Emacs behavior is just the same as other apps but the
terminology is out-of-date and so makes learning it unnecessarily
difficult.  That's the wrong message entirely - quite misleading.

The right takeaway for a new user is that learning Emacs is
learning something new and different - it is not your momma's
editor.  And it rightfully has its own terminology, which you
had better learn also.

The Greek philosopher Proclus records that when Ptolemy asked
if there wasn't perhaps an easier way to learn Emacs than Emacs,
Euclid replied, "Sire, there is no royal road to Emacs."

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Tue, Jan 7, 2014 at 8:06 PM, Drew Adams <drew.adams@oracle.com> wrote:

>
> The right takeaway for a new user is that learning Emacs is
> learning something new and different - it is not your momma's
> editor.  And it rightfully has its own terminology, which you
> had better learn also.
>
>
Did not someone say it was his momma's editor? ;-)
I think you are taking your points too far. For me the problem is how to
make a good road into Emacs for new users. I want a feeling like "this is
what I am used to and now I am glad I discovered the new possibilities". It
should be both familiar and new at the same time.


> The Greek philosopher Proclus records that when Ptolemy asked
> if there wasn't perhaps an easier way to learn Emacs than Emacs,
> Euclid replied, "Sire, there is no royal road to Emacs."
>

There might be some translation error or misunderstanding there. ;-)

[-- Attachment #2: Type: text/html, Size: 1654 bytes --]

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

[David Kastrup]

Joel Mccracken <mccracken.joel@gmail.com> writes:

> Beyond trying to remember, using current terminology is sends the
> message that Emacs is old, stubborn, and crufty, which is a problem
> when trying to introduce new users to Emacs.

Emacs _is_ one of the old great ones.  You are trying to make Gandalf
more popular by plucking his nose hairs.

-- 
David Kastrup

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Tue, Jan 7, 2014 at 8:37 PM, David Kastrup <dak@gnu.org> wrote:

> Joel Mccracken <mccracken.joel@gmail.com> writes:
>
> > Beyond trying to remember, using current terminology is sends the
> > message that Emacs is old, stubborn, and crufty, which is a problem
> > when trying to introduce new users to Emacs.
>
> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
> more popular by plucking his nose hairs.
>
> The great thing lives in its power, not in the nose hairs. Just pick them.
;-)

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

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

[David Reitter]

On Jan 7, 2014, at 2:06 PM, Drew Adams <drew.adams@oracle.com> wrote:

>> Beyond trying to remember, using current terminology is sends
>> the message that Emacs is old, stubborn, and crufty, which is a
>> problem when trying to introduce new users to Emacs.
> 
> No, it does not.  If Emacs were invented from scratch today, it
> would still need its own jargon.  Some of the particulars would
> no doubt be different, but Emacs would still stand apart in both
> behavior and terminology.

Yes, but the jargon would not conflict with widely used terminology.  Would you really redefine a common word like "window", and invent another one referring to the established meaning of windows?  

Other things are actually different, and different terms are appropriate. "Mark" comes to mind, or "major" and "minor" modes.

You're right in that Emacs is not yet another editor, and you want to send that message.  But, don't people see this soon enough when they actually use it?

The UI experiment that I have been interested in with Aquamacs, is to allow people to gradually transition from a newbie user to a proficient one with high routinized sequences of actions.  This is actually something that other editors and IDEs can't provide to the extent that Emacs does.  Netbeans, Eclipse, Xcode - they're great IDEs and very integrated, and certainly useful for proficient users, but they're nowhere nearly as efficient as Emacs.

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

[Drew Adams]

> > If Emacs were invented from scratch today, it
> > would still need its own jargon.  Some of the particulars would
> > no doubt be different, but Emacs would still stand apart in both
> > behavior and terminology.
> 
> Yes, but the jargon would not conflict with widely used terminology.

Preferably, yes; agreed.  Other things being equal...

> Would you really redefine a common word like "window", and invent
> another one referring to the established meaning of windows?

No, I would not.  This is what I meant by "Some of the particulars
would no doubt be different."

> Other things are actually different, and different terms are
> appropriate. "Mark" comes to mind, or "major" and "minor" modes.

Yes, in general.  (Dunno about "mark", but let's not get into
particulars right now.)

> You're right in that Emacs is not yet another editor, and you want
> to send that message.  But, don't people see this soon enough when
> they actually use it?

Yes.  I am not suggesting that that message is not getting across.
You are mistaken that I feel a need to send that message.  My point
was that Emacs behavior is different, and it necessarily has its
own terminology to some extent.  That is not something to be wished
away or papered over.

> The UI experiment that I have been interested in with Aquamacs, is
> to allow people to gradually transition from a newbie user to a
> proficient one with high routinized sequences of actions.  This is
> actually something that other editors and IDEs can't provide to the
> extent that Emacs does.  Netbeans, Eclipse, Xcode - they're great
> IDEs and very integrated, and certainly useful for proficient users,
> but they're nowhere nearly as efficient as Emacs.

Concrete suggestions about that might well be helpful.  So far,
the discussion has just rehashed previous ones.  What you suggest
is not a bad goal, but the starting point should not be to short-sell
newbie Emacs users (not suggesting your approach does that; I don't
know).  They are as bright as past newbies, no doubt.

Yes, they have more experience with other approaches that could
mislead them - Emacs is not often their first editor/UI.  But that
does not mean they cannot "get" Emacs.  What is true today, as it
always has been, is that some effort to learn is needed.  You
cannot just pick up Emacs expecting it to do what you are used to,
without being disappointed or missing the boat.

One has only to look at the questions on a site such as
StackOverflow, not especially those about Emacs, but generally
(and apparently about PHP in particular), to see that some users
expect instant familiarity with a product without any effort - not
even a cursory look at the doc or a Google search.  The SO site
leaders are continually lamenting the poor quality of (some)
questions and askers.  Some people really do expect a royal road
to learning.  Encouraging them in that does not help them or
anyone else.

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Tue, Jan 7, 2014 at 9:31 PM, Drew Adams <drew.adams@oracle.com> wrote:

>
> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search.  The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers.  Some people really do expect a royal road
> to learning.  Encouraging them in that does not help them or
> anyone else.
>
>
The main road to learning is probably that it is fun. That is how our
brains work. Learning new names for wellknown things is not that fun. It is
just trivial. (Unless you are learning a new language, of course.)

I would expect Emacs new comers to look for the real interesting things in
Emacs. And those who do that are perhaps those that have most to gain from
Emacs. They might just stop because of the boring trivial things.

[-- Attachment #2: Type: text/html, Size: 1658 bytes --]

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Emacs _is_ one of the old great ones.  You are trying to make Gandalf
    more popular by plucking his nose hairs.

It's not a good analogy.  People can like Gandalf as a character
without having to learn lots of incantations.

Learning Emacs is never going to be easy.  But we might be able
to change Emacs so that learning it is a little less hard,
and that would be a substantial improvement.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Bob Bobeck]

I think it's more like Dumbledwarf. He gets killed in the end. Bwahahhahaha.

On 1/7/14, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     Emacs _is_ one of the old great ones.  You are trying to make Gandalf
>     more popular by plucking his nose hairs.
>
> It's not a good analogy.  People can like Gandalf as a character
> without having to learn lots of incantations.
>
> Learning Emacs is never going to be easy.  But we might be able
> to change Emacs so that learning it is a little less hard,
> and that would be a substantial improvement.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>
>
>

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

[Drew Adams]

> users can get the impression that Emacs is not for them because it's weird.
> If they in just the first half hour of using Emacs meet several such things
> they may conclude that working with Emacs will continue to be like this;
> now and then it will turn out that it doesn't work as "expected" and that
> there are new names for everything, etc.  Why not use That Other Editor
> that some other people suggested instead?

Why not, indeed?  Problem solved.

At ease; false alarm.  Circulez ; il n'y a rien a voir.

(And _you_ are not using That Other Editor why?  Did you perhaps spend
more than 1/2 hour learning This Old Editor?)

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

[Per Starbäck]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

2014/1/9 Drew Adams <drew.adams@oracle.com>

> > users can get the impression that Emacs is not for them because it's
> weird.
> > If they in just the first half hour of using Emacs meet several such
> things
> > they may conclude that working with Emacs will continue to be like this;
> > now and then it will turn out that it doesn't work as "expected" and that
> > there are new names for everything, etc.  Why not use That Other Editor
> > that some other people suggested instead?
>
> Why not, indeed?  Problem solved.
>

Then you are talking about another problem than I am. Functionality (and
attitudes) that turn away those people is indeed a problem for Emacs. It is
sometimes direct, but often indirect (they don't even try Emacs because a
distro maintainer thought that it shouldn't be installed by default). We
want those users. Especially the part of them that would have become
developers.

(And _you_ are not using That Other Editor why?  Did you perhaps spend
> more than 1/2 hour learning This Old Editor?)
>

This seems irrelevant to me. What is your point?

[-- Attachment #2: Type: text/html, Size: 1682 bytes --]

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

[Drew Adams]

>>> users can get the impression that Emacs is not for them because it's weird.
>>> If they in just the first half hour of using Emacs meet several such things
>>> they may conclude that working with Emacs will continue to be like this;
>>> now and then it will turn out that it doesn't work as "expected" and that
>>> there are new names for everything, etc.  Why not use That Other Editor
>>> that some other people suggested instead?
>>
>> Why not, indeed?  Problem solved.
>
> Then you are talking about another problem than I am.  Functionality (and
> attitudes) that turn away those people is indeed a problem for Emacs.

Are you sure that turning away "those people" is a problem for Emacs?

>> (And _you_ are not using That Other Editor why?  Did you perhaps
>> spend more than 1/2 hour learning This Old Editor?)
>
> This seems irrelevant to me. What is your point?

Emacs _is_ a better mousetrap.
http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door

To really appreciate it, some people, if not most, need to give it more
than 1/2 hour, before jumping to the conclusion that it is not worth
their spending more time with it.  As Richard put it, "Learning Emacs is
never going to be easy."  Or as I said:

  Learning Emacs is learning something new and different - it is not
  your momma's editor.  And it rightfully has its own terminology.

"Those people" who don't feel they need to bother - well, they will
either get it later, by way of others, or they will not.  Tant pis.

Emacs losing out because Eclipse or whatever offers more code-refactoring
(or whatever) power, out of the box - that's one thing.  Emacs has room
for improvement in lots of areas, no doubt about that.

But Emacs being "weird" because it uses the word "window" differently -
that's another thing.  I have never encountered a newbie taking Emacs
for a test drive who could not understand, when told what an Emacs
window is.  Have you?

But yes, it might take more than 1/2 hour for Emacs to introduce itself
properly to a user.  ("Hello there, I'm GNU Emacs. Who are you?")

This isn't a cocktail party!  But even if it were, there are some people
who, if given the opportunity, would give up in 5 minutes after being
introduced to the likes of <INSERT HERE your favorite respected
luminaries and Great Ones>, even if they spoke the same language.  Some
people are unfortunately "those people".

Other things being equal, of course we want to make things easy to learn.
Of course we do not want to throw up unnecessary obstacles.  Gratuitous
differences in terminology for identical things should be dealt with -
and they generally are.

  But (a) that is rare (the Emacs thingies are not really the same), and
  (b) even then it is not important to toe the line.  Especially if the
  things are identical, it is easy to learn new terms for them.

The Emacs UI and doc have been dealing with this for almost 4 decades
now.  It does take at least a few minutes and a few examples to get the
notion and behavior of an Emacs "buffer".  Weird!  Not what you're used
to.  Give it a little time.  A better mousetrap - you'll see.

That kind of hand-holding encouragement is fine.  But there is no reason
to underestimate potential users.  Some people will give up without
giving Emacs a chance.  So what?  Others will not - just as you did not.
Why suppose that potential Emacs users are less patient or curious or
intelligent than we are?

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

[Per Starbäck]

[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]

2014/1/9 Drew Adams <drew.adams@oracle.com>

> > Then you are talking about another problem than I am.  Functionality (and
> > attitudes) that turn away those people is indeed a problem for Emacs.
>
> Are you sure that turning away "those people" is a problem for Emacs?
>
>
Yes. Any attitude of "it should be hard to learn because the good people
can learn things that are hard to learn" is just contraproductive.


> >> (And _you_ are not using That Other Editor why?  Did you perhaps
> >> spend more than 1/2 hour learning This Old Editor?)
> >
> > This seems irrelevant to me. What is your point?
>
> Emacs _is_ a better mousetrap.
>
> http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door
>
> To really appreciate it, some people, if not most, need to give it more
> than 1/2 hour, before jumping to the conclusion that it is not worth
> their spending more time with it.  As Richard put it, "Learning Emacs is
> never going to be easy."  Or as I said:
>
>   Learning Emacs is learning something new and different - it is not
>   your momma's editor.  And it rightfully has its own terminology.
>

Those are not comparable quotes at all. Richard wants Emacs to be easier to
learn for beginners, and I doubt he would write something like your momma
quote. Emacs is the text editor for a GNU system. It shouldn't need some
other text editor for "your momma" besides it, but have Emacs be the
program used for any user who need plain text editing. That Gnome had to
create a new text editor to be the default editor for Gnome was a *big*
setback for Emacs.

To really appreciate any text editor takes time.


> "Those people" who don't feel they need to bother - well, they will
> either get it later, by way of others, or they will not.  Tant pis.
>

That works only if your goal is this elite Emacs. The "right" users will
find it eventually anyway. Not all people have that idea about Emacs.


> But Emacs being "weird" because it uses the word "window" differently -
> that's another thing.  I have never encountered a newbie taking Emacs
> for a test drive who could not understand, when told what an Emacs
> window is.  Have you?
>
>
That's rehashing. It's not about understanding. It's about what impression
you make.


>
> Other things being equal, of course we want to make things easy to learn.
> Of course we do not want to throw up unnecessary obstacles.  Gratuitous
> differences in terminology for identical things should be dealt with -
> and they generally are.
>

So why do you object when people want to deal with this particular
gratuitous difference in terminology? The proposed window->pane change
doesn't affect other stuff. Yes, an Emacs "buffer" for instance is an Emacs
concept that you have to learn because it's different from what you've used
elsewhere, but that's not part of this at all.


> That kind of hand-holding encouragement is fine.  But there is no reason
> to underestimate potential users.  Some people will give up without
> giving Emacs a chance.  So what?  Others will not - just as you did not.
> Why suppose that potential Emacs users are less patient or curious or
> intelligent than we are?
>

My using Emacs is irrelevant. One reason is that I learned (Teco) Emacs in
the 1980s, when expectations on how to learn programs were very different
from now, and with not really any other text editors to choose from anyway.
Another is that the main reason I'm using (GNU) Emacs now is that it's the
editor of the GNU system. If GNU had gone with something else I would
probably have started using that instead, even though that would have been
a much bigger transition than going from one Emacs to another.

[-- Attachment #2: Type: text/html, Size: 5384 bytes --]

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

[David Kastrup]

Per Starbäck <per@starback.se> writes:

> 2014/1/9 Drew Adams <drew.adams@oracle.com>
>
>> > Then you are talking about another problem than I am.  Functionality (and
>> > attitudes) that turn away those people is indeed a problem for Emacs.
>>
>> Are you sure that turning away "those people" is a problem for Emacs?
>>
> Yes. Any attitude of "it should be hard to learn because the good
> people can learn things that are hard to learn" is just
> contraproductive.

It's more like "it's unavoidable to provide difficulties to learning
because it can do a lot, and when a lot is easily accessible, you'll
have stuff getting in your hair accidentally".

Musicians learn their instruments, craftsmen learn their tools.
Unfretted bowed string instruments remain a favorite even though the
possibilities for producing wrong notes or sounds that cannot in good
conscience even be called "tones" are staggering when compared to, say,
a piano.  Attempts to cut down on variables the player can get wrong,
like the hurdy gurdy, did not really take off.

A programmer will spend most of his life interacting with an editor and
texts.

> Those are not comparable quotes at all. Richard wants Emacs to be
> easier to learn for beginners, and I doubt he would write something
> like your momma quote.

A carving knife with an exploding handle is not going to be popular.
But you won't be able to sell one with a blunt edge "for safety" either.
Within the variables, one wants to make things as simple as possible but
not simpler.

-- 
David Kastrup

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

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> 
> It's more like "it's unavoidable to provide difficulties to learning
> because it can do a lot, and when a lot is easily accessible, you'll
> have stuff getting in your hair accidentally".

Arbitrary roadblocks can be removed, though.

For example, yank is not a superior term to paste, so paste could be
used instead. One unnecessary difference less. And it is only one example,
there are others.

Emacs provides enough material to learn without these arbitrary (legacy)
differences, so these should be eliminated where possible.

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

[David Kastrup]

Tom <adatgyujto@gmail.com> writes:

> David Kastrup <dak <at> gnu.org> writes:
>> 
>> It's more like "it's unavoidable to provide difficulties to learning
>> because it can do a lot, and when a lot is easily accessible, you'll
>> have stuff getting in your hair accidentally".
>
> Arbitrary roadblocks can be removed, though.
>
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less.

You mean, unnecessary similarity.  This has a C-y keyboard binding, and
vi uses y and Y bindings for yanking as well.

> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.

The problem is that they are not "arbitrary" but deeply ingrained into
the choice of keyboard sequences.  And C-x and C-c are pretty much the
most reliably accessible control characters, so they make good sense for
starting multiple keystroke sequences.

What _is_ somewhat annoying in contrast is the positioning of C-b C-n
C-p and C-f.  The hjkl sequences of vi or C-s C-x C-e C-d sequences of
WordStar make more sense.

-- 
David Kastrup

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

[Drew Adams]

> Arbitrary roadblocks can be removed, though.

I said as much:

  Gratuitous differences in terminology for identical things
  are something else.  But (a) that is rare (the Emacs thingies
  are not really the same), and (b) even then it is not
  important to toe the line.  Especially if the things are
  identical, it is easy to learn new terms for them.

IOW, the truly arbitrary differences are rare and not a problem.
Learning Emacs is hard, but not because of them.
 
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less. And it is only one
> example, there are others.
> 
> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.

To repeat (you might want to read the thread):

  Examples of exceptional things that are identical in Emacs,
  or nearly so, are "cut" and "paste" operations.  And as
  others have already said, it is enough to point out the
  Emacs terminology and the correspondences (when there are
  close correspondences and not just faux amis) - which we
  already do, AFAIK.

We already make clear in the menus and doc that "yank" means
something very similar to "paste".

And (to repeat, again) far more importantly: this is NOT a
point of "confusion" for newbies.

Initial ignorance, yes. But the slightest contact with the
Emacs docs or google or a quick Q & A has always been enough to
let newbies know what "yank" means.  I have never seen anyone
become "confused" after they were introduced to the term "yank".

This is simply a non-problem.  But it gets rehashed here every
so often.

NOT because newbies say they are confused and don't get it.
But only because some well meaning soles here get the bright
idea that this must be confusing to new arrivals and that if
this important obstacle were removed then Emacs would have a
brighter future.

This essentially short-sells newbies, and touches on demagogy.
_You_ learned "yank".  Did you stay up at night in turmoil,
trying to grasp its meaning?  No.  Don't you think that other
newbies are just as bright as you were?  Please, think about it.

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

On Jan 7, 2014, at 3:31 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Concrete suggestions about that might well be helpful.

I had some suggestions or questions back in 2005 or thereabouts, when I was less familiar with Emacs,
and I asked questions on this mailing list.  Perhaps now the time is better (although I have less time).

Many things are vastly improved from what they were back then - better default key bindings, ELPA, copy&paste with other apps working out of the box, and so on.  

At this time, my concrete suggestion I would have is to make semantic, CEDET and etags work out-of-the-box for all major programming paradigms, and make them work without noticeable performance penalty.  Standard IDEs like Netbeans, Eclipse or Xcode give me that.  Emacs 24 has come a long way, but it's not quite there yet.  For instance, I can enable Semantic from the menu, but then I'd try C-M-/ for a completion, next to [win ...] in nsterm.m, and that doesn't give me all the members of the class of "win", in the correct capitalization.  In .c files, I get at least some helpful echo area messages, but scrolling gets sluggish.  Netbeans doesn't do that.   And it just-in-time compiles, marks syntax errors automatically right in the source code, and so on, and so forth.

The second suggestion is better project management, integrated with Semantic.  Some ingredients, like Speedbar and Desktop, are there, but they do not provide an integrated experience. 

Other people will have other suggestions...

>  What you suggest
> is not a bad goal, but the starting point should not be to short-sell
> newbie Emacs users (not suggesting your approach does that; I don't
> know).  They are as bright as past newbies, no doubt.

Indeed, that's not what I meant.  It's just that even intelligent people prefer to spend their cognitive resources on the actual tasks they are employed to do, or the tasks they intend to do, rather than to learn the tool.  We're in a world where software has become obvious to use, or at least very discoverable.

> You
> cannot just pick up Emacs expecting it to do what you are used to,
> without being disappointed or missing the boat.

The idea in Aquamacs is that you can do that, and transition to faster routines as you go along.
It's probably true that the proportion of highly proficient users is smaller, but the overall number of users is greater.

> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search.  The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers. 

Yes, programming has become very much a copy&paste (sorry, kill&yank) effort.  For many programming projects, that is sufficient.  You won't get to hack away at Google, Inc., or at Oracle Corp that way, but that's probably OK. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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.

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?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Davis Herring]

>> For example, yank is not a superior term to paste, so paste could be
>> used instead. One unnecessary difference less.
> 
> You mean, unnecessary similarity.  This has a C-y keyboard binding, and
> vi uses y and Y bindings for yanking as well.

Except that "yank" means "copy" in vi, not "paste".  (This is the source
of most confusion I see about the word.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

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

[David Kastrup]

Davis Herring <herring@lanl.gov> writes:

>>> For example, yank is not a superior term to paste, so paste could be
>>> used instead. One unnecessary difference less.
>> 
>> You mean, unnecessary similarity.  This has a C-y keyboard binding, and
>> vi uses y and Y bindings for yanking as well.
>
> Except that "yank" means "copy" in vi, not "paste".

Uh yeah, forgot about that...

> (This is the source of most confusion I see about the word.)

-- 
David Kastrup

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

[Tom]

David Reitter <david.reitter <at> gmail.com> writes:
> 
> At this time, my concrete suggestion I would have is to make semantic, CEDET 
and etags work out-of-the-box for all major programming paradigms, and make 
them work without noticeable performance penalty. 

I'd suggest giving some attention to Eclim too. It can do things which
other tools cannot AFAIK. E.g. offering code fixes and stuff. See here:

http://www.skybert.net/emacs/java/

Of course, it requires Eclipse, but it's not necessarily a disadvantage,
because lots of users use Eclipse today and they try emacs beside that.
So it can even be an advantage, because the user can work in eclipse
as usual and at the same time he can work with the same project in
emacs. It makes very easy to try working in emacs, because the user
does not have to create a new environment for developing with emacs,
emacs simply connects to the running eclipse instance.

And Eclim has lots of low hanging fruits, so it can be improved 
with little effort. It only needs some attention, because the current
maintainer said he wouldn't implement stuff he didn't use:

http://fredrik.appelberg.me/2013/06/10/maintainer-blues.html

So a polished/improved Eclim would be very useful for newbie users
even if it's not part of core Emacs, because it makes easy to
try working in emacs.

Here's a list of what Eclim is capable of, and only a fraction of
this is implemented by the emacs interface, though it's not hard
to implement them (it involves only calling the relevant operations
and presenting the results to the user):


Eclipse Projects

Create, update, and delete Eclipse projects.
Easily manage Eclipse .classpath files (support for maven and ivy).
Quickly and easily manage settings globally or on a project basis.

Java

Automatic source code validation (w/ visual marking of errors and warnings).
Context sensitive code completion.
Code correction suggestions with option to apply a suggestion.
Class constructor generation.
Java Bean getter and setter generation.
Generation of delegate methods.
Java source and java doc searching capabilities.
Generate stub methods from implemented interfaces or super classes.
Generate stub methods for junit testing.
Quickly clean and sort imports and easily import new classes.
Automatic generation of logging initialization code, upon first usage of a 
logger.
Javadoc generation for package, class, field, method, etc.
Java regular expression testing.
Support for Checkstyle.
Validation of log4j xml files.

C/C++

Context sensitive code completion.
Searching.
Source code validation.

Css
Context sensitive code completion.
Source code validation.

Html

Context sensitive code completion.
Automatic validation (w/ visual marking of errors and warnings).

Android

Support for creating android projects

Ant

Ant execution from any file.
Context sensitive code completion when editing build files.
Automatic validation of build files (w/ visual marking of errors and warnings).
Quick access to ant documentation.

Maven

Maven execution from any file.
Maven repository searching and ability to add results to pom file.

JavaScript

File validation using jsl.

Php

Code completion.
Searching.
Source code validation.

Python

Context sensitive code completion.
Find element definition support.
Regular expression testing.
Django functionality.
Validation via python compiler, pyflakes, and pylint.

Ruby

Context sensitive code completion.
Searching.
Source code validation.

Xml / Dtd / Xsd

Automatic validation (w/ visual marking of errors and warnings).
Quickly look up element definition from the current xml file's dtd or xsd.
Context sensitive code completion.

And more...


http://eclim.org/features.html

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).

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

[David Kastrup]

Per Starbäck <per@starback.se> writes:

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

That's like music instruments that are missing notes to make them
"simpler to learn".  It will always come to bite you eventually.

-- 
David Kastrup

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

[Eli Zaretskii]

> Date: Sat, 18 Jan 2014 00:13:50 +0100
> From: Per Starbäck <per@starback.se>
> Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> 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.

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 18 Jan 2014 00:13:50 +0100
> > From: Per Starbäck <per@starback.se>
> > Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <
> emacs-devel@gnu.org>
> >
> > 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? ;-)

[-- Attachment #2: Type: text/html, Size: 4205 bytes --]

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

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > 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.

That's a red herring.  What people are looking for are not editors that
are easy to learn, but editors that can be used without learning
anything at all.

I encounter this situation as an accordion player: the joke in
<URL:http://eu.art.com/products/p24328669009-sa-i7924441/uli-stein-akkordeon-kleiner.htm>,
namely somebody asking for a smaller-size accordion, is not without a
serious background: people imagine that capsizing a piano will make for
a good user interface.  It doesn't.  Back problems are frequent with
accordion players, and particularly women are often slumped in their
chairs in order to accommodate the vertical dimension of their keyboard.
I play a chromatic button accordion which has buttons rather than piano
keys, and I have 62 notes accessible where a piano accordion has at most
45, and even a small piano accordion with 37 keys has a larger height
than my instrument and its key mechanics take from the immediate
airflow/valve/button interaction facilitating good leggiero play and
bellows control.

If you take a look at nations where accordions are "mainstream" music
instruments, like Finland, France, Russia, you'll find a prevalence of
button instruments.  Internationally, it's about evenly split for
accordion soloists, and about 90% piano accordion for accordion
orchestra players (accordion orchestras are collection of accordionists
no other instrumentalists want to play with).  The ratio would be even
higher except for orchestras from those accordion nations where piano
accordions are considered outlandish altogether.

If viewed in the grand overall scheme of things, it begs the question if
we are doing Emacs a favor by giving it the piano keyboard more people
think they know how to work with.

Yes, it makes it easier to employ Emacs as a throwaway editor you
occasionally use and forget again.

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

In countries where the piano accordion is prevalent, accordions are more
often associated with music styles, groups, and shows that "serious"
musicians consider a laughing stock.  That definitely impacts the influx
of new players.  And in particular, new virtuosi.

The future of Emacs depends on people with an attention span and
perseverence sufficient for extending it.  Those are the people who are
most likely to be annoyed at the inconsistency of concepts and
operations of things like the full CUA mode (the one which uses
heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
sense).

We should not try to be too clever about looking simple: we will only
fool those people who don't actually count towards the well-being of
Emacs.  So any changes should be done while keeping the coherence of the
result closely in check.

-- 
David Kastrup

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> > On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > 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.
>
> That's a red herring.  What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.
>

Do you believe you will convince me with this, or? ;-)
Facts are much better if we do not agree. If we agreed this might have been
better, more fun, of course... ;-)


>
>
 > 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.
>
> The future of Emacs depends on people with an attention span and
> perseverence sufficient for extending it.  Those are the people who are
> most likely to be annoyed at the inconsistency of concepts and
> operations of things like the full CUA mode (the one which uses
> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
> sense).
>
> Are you really sure you want to look down upon those that do not agree? ;-)

[-- Attachment #2: Type: text/html, Size: 3286 bytes --]

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

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:
>
>> Lennart Borgman <lennart.borgman@gmail.com> writes:

>> > 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.
>>
>> The future of Emacs depends on people with an attention span and
>> perseverence sufficient for extending it.  Those are the people who are
>> most likely to be annoyed at the inconsistency of concepts and
>> operations of things like the full CUA mode (the one which uses
>> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
>> sense).
>
> Are you really sure you want to look down upon those that do not
> agree? ;-)

It's not a question on looking up or down.  Let me quote from the CUA
mode section in the Emacs manual:

    The command ‘M-x cua-mode’ sets up key bindings that are compatible with
    the Common User Access (CUA) system used in many other applications.

       When CUA mode is enabled, the keys ‘C-x’, ‘C-c’, ‘C-v’, and ‘C-z’
    invoke commands that cut (kill), copy, paste (yank), and undo
    respectively.  The ‘C-x’ and ‘C-c’ keys perform cut and copy only if the
    region is active.  Otherwise, they still act as prefix keys, so that
    standard Emacs commands like ‘C-x C-c’ still work.  Note that this means
    the variable ‘mark-even-if-inactive’ has no effect for ‘C-x’ and ‘C-c’
    (*note Using Region::).

       To enter an Emacs command like ‘C-x C-f’ while the mark is active,
    use one of the following methods: either hold ‘Shift’ together with the
    prefix key, e.g., ‘S-C-x C-f’, or quickly type the prefix key twice,
    e.g., ‘C-x C-x C-f’.

Now this is touted as a feature to make things _simple_ for people.  In
reality, _competent_ use of it requires _lots_ of learning and
surprises.  If I enable CUA mode and type C-h k C-x C-c, I read

    C-x C-c runs the command save-buffers-kill-terminal, which is an
    interactive compiled Lisp function in `files.el'.

    It is bound to C-x C-c, <menu-bar> <file> <exit-emacs>.

    (save-buffers-kill-terminal &optional ARG)

    Offer to save each buffer, then kill the current connection.
    If the current frame has no client, kill Emacs itself.

    With prefix ARG, silently save all file-visiting buffers, then kill.

    If emacsclient was started with a list of filenames to edit, then
    only these files will be asked to be saved.

    [back]

But if there is an active region, C-h k C-x prints

    C-x runs the command cua--prefix-override-handler, which is an
    interactive compiled Lisp function in `cua-base.el'.

    It is bound to C-c, C-x.

    (cua--prefix-override-handler ARG)

    Start timer waiting for prefix key to be followed by another key.
    Repeating prefix key when region is active works as a single prefix key.

    [back]

This kind of mode dependency is what Emacs proponents in the editor wars
tend to describe as a disadvantage of vi.

This kind of "do the expected thing" setup may delay the time until
cursory Emacs users will hit a wall of learning.  But when they do, the
wall is higher.

This puts a larger complexity gap between "simple users" and "power
users or programmers" who actually can work their tool with confidence.

I don't see that making Emacs fit the Gedit task space would have
yielded a result where Gedmacs users would have grown into active
participants of the Emacs universe.

In the long run, we need to make sure that Emacs remains comprehensible
to Emacs users.  That does not preclude changing keybindings and
concepts, but getting multiple concurrent warring keybindings and
concepts sorted by various heuristics is not the way to simplicity.

-- 
David Kastrup

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

[Sivaram Neelakantan]

On Sat, Jan 18 2014,David Kastrup wrote:

[snipped 92 lines]

> In the long run, we need to make sure that Emacs remains comprehensible
> to Emacs users.  That does not preclude changing keybindings and
> concepts, but getting multiple concurrent warring keybindings and
> concepts sorted by various heuristics is not the way to simplicity.

No offence to the CUA/EVIL developers but don't these 2 modes get in
the way of Emacs mastery as David says.  I can understand someone
asking for the vi . (dot command) functionality equivalent in Emacs
but why humour them with modes that are at cross purposes to Emacs
proficiency?  

Here, simplicity begets simple users(with no offence to their
intelligence, just Emacs mastery)

 sivaram
 -- 

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

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

> That's a red herring.  What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.

People are looking for editors that work similar enough to those that
they already know.

For most people, the *promise* of improved efficiency is not credible
enough to invest the required time to learn Emacs.

[snip]

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

[grischka]

David Kastrup wrote:
> If viewed in the grand overall scheme of things, it begs the question if
> we are doing Emacs a favor by giving it the piano keyboard more people
> think they know how to work with.

I don't think the piano keyboard is the problem. It is more the
heap of wires and buttons behind it that may look to you like an
accordion but really is a 1960s Moog vacuum tube synthesizer.

--- grischka

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

[Tom]

Sivaram Neelakantan <nsivaram.net <at> gmail.com> writes:
> 
> No offence to the CUA/EVIL developers but don't these 2 modes get in
> the way of Emacs mastery as David says.  I can understand someone
> asking for the vi . (dot command) functionality equivalent in Emacs
> but why humour them with modes that are at cross purposes to Emacs
> proficiency?  

Emacs mastery is not about using the default keys, it's about 
understanding how you can transform Emacs, so it adapts to you,
not the other way around.

I often read from beginners in forums that they think the
keybindings give emacs its power, though the real power is
the lisp environment which allows you to create your own
personal working environment including completely revamping
them and using vi bindings if you want.

So Emacs proficiency has nothing to do with the keys. They
are only the legacy defaults which can be changed as any other
custom aspects of emacs.

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

[David Kastrup]

grischka <grishka@gmx.de> writes:

> David Kastrup wrote:
>> If viewed in the grand overall scheme of things, it begs the question if
>> we are doing Emacs a favor by giving it the piano keyboard more people
>> think they know how to work with.
>
> I don't think the piano keyboard is the problem. It is more the
> heap of wires and buttons behind it that may look to you like an
> accordion but really is a 1960s Moog vacuum tube synthesizer.

More like the 1950s.  Those things were called "Electronium" and part of
Hohner's master plan to organize the accordionists nobody wanted to play
with into "accordion orchestras".

<URL:https://www.youtube.com/watch?v=eml7J7zi4gA>

The real chutzpah here is claiming "bellows-controlled volume".  Those
things did not actually use the (operative) bellows as much for volume
control but for cooling: the simple LC oscillators tended to have quite
a bit of temperature drift.  There was a hinge-and-spring mechanism
basically turning the whole instrument into one clumsy volume pedal: the
volume was solely determined by how much you pulled the instrument
apart.

<URL:http://www.vintageaudioberlin.de/vabmenue1/vabmenue3.htm>

Of course, this was decades before Emacs.  While the concept has been
dragged through several transistorized and later digital successors, the
popularity has sharply declined and nowadays one sees this thing
mentioned much more often in accordion orchestra scores (its sole
habitat) than one actually sees it in operation.

I digress.  Seriously.

At any rate, at that time Hohner was reasonably successful promoting CUA
("could utilize accordions") for a wide spectrum of music genres.

-- 
David Kastrup

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

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> That's a red herring.  What people are looking for are not editors that
>> are easy to learn, but editors that can be used without learning
>> anything at all.
>
> People are looking for editors that work similar enough to those that
> they already know.
>
> For most people, the *promise* of improved efficiency is not credible
> enough to invest the required time to learn Emacs.

I'm not convinced that this should overly influence our priorities.
It's like trying to make a piano appealing to iPod users.  Both are used
for producing music.

What _should_ be making us think about our priorities is when we lose
the input of heavy Emacs users like RMS, Ben Wing, Nix, to Repetitive
Strain Injury, and it appears like users of other editors are not
affected to a similar degree.

No idea about the actual numbers, though.  If they turned out to be more
than just anecdotal, that would at least provide an incentive for
long-term replanning of the default keybindings to be offered.

To me, that would carry more weight than "everybody else does x".

-- 
David Kastrup

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    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.

We could make an incompatible "simple" interface for Emacs and make it
easy to learn.  It could look just like gedit, perhaps.

It might be better, overall, if gedit were implemented as such an
interface to Emacs.  I am not sure it would have been less work, though.

However, if you change it that much, it won't give people an easy pathway
to using Emacs.  Its commands would be all different.



-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Sun, Jan 19, 2014 at 1:10 PM, Richard Stallman <rms@gnu.org> wrote:

>
> We could make an incompatible "simple" interface for Emacs and make it
> easy to learn.  It could look just like gedit, perhaps.
>
> It might be better, overall, if gedit were implemented as such an
> interface to Emacs.  I am not sure it would have been less work, though.
>

Perhaps it does not matter if it would have been less work in the
beginning. Perhaps the long term outcome matters more.


>
> However, if you change it that much, it won't give people an easy pathway
> to using Emacs.  Its commands would be all different.
>
> I see no reason the commands would be different. Not at the beginners
level.

[-- Attachment #2: Type: text/html, Size: 1436 bytes --]

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

[Phillip Lord]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> > 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.

For what it is worth, I think Emacs could do with some considerable
improvement on the "self-documenting" front. A student of mine recently
asked about tutorials for Emacs. Of course, I said, it's got one
built-in, to which the response was that it was rubbish.

So I went and looked at it for the first time in many years. I think he
has a point. As the warning notice that you get if you change things says:

"The main purpose of the Emacs tutorial is to teach you
the most important standard Emacs commands (key bindings)."

Are key bindings the main thing we want to teach new users?

Worse the first 200 lines are all about how to move the cursor; I mean,
most new users are just going to use the cursor keys, or a mouse. It's
what I do, even after years of using Emacs with a few exceptions
(Ctrl-A, E and M-<,> if you are interested).

It isn't till line 199 that you get something powerful (repeat commands)
rather than painful. Then, we move onto Ctrl-G (line 236) which is what
happens when it breaks. And line 274 get us to Windows. And line 470
before we find out how to open a file.

There are also 4 "If you are on a windowing system" statements: lets be
honest, any new user is going to be on a windowing system. People
starting to use computers today are likely to be unaware that it is
possible to not be on a windowing system.

Other things that seem to be missing, are links to the rest of the
world. Why no links to web pages, or videos? Or indeed, in-line images.

Perhaps, users would be less confused by "windows", "buffers" and so on,
if they hadn't got bored long before the point where these are
explained?

If there is interest in incorporating it, I'd be willing to rewrite it.

Phil

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

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Date: Mon, 20 Jan 2014 12:22:45 +0000
> 
> For what it is worth, I think Emacs could do with some considerable
> improvement on the "self-documenting" front. A student of mine recently
> asked about tutorials for Emacs. Of course, I said, it's got one
> built-in, to which the response was that it was rubbish.
> 
> So I went and looked at it for the first time in many years. I think he
> has a point.

Indeed.  Volunteers are welcome to work on this.

> Worse the first 200 lines are all about how to move the cursor;

But let's be fair: the tutorial starts by saying that arrow keys and
PgUp/PgDn are also supported.

> If there is interest in incorporating it, I'd be willing to rewrite it.

Please do, and thanks in advance.