RE: Emacs learning curve

RE: Emacs learning curve

[grischka]

 > Obviously, there is no reason to choose words perversely (e.g. use
 > "red" when we mean green).

Or use "scroll-up" where it means scroll down, or use "split-horizontally"
where it splits vertically ;)

 > Analogy (not really the same thing, but it is suggestive):  Remember those
 > experiments where people put on special glasses that flip their vision
 > vertically - everything looks upside down.  In a relatively short time their
 > brains adapt completely, so they actually see everything rightside up.

Sure, but the point is to put the glasses on _before_ one decides for
naming conventions as above.

--- grischka

Re: Emacs learning curve

[Óscar Fuentes]

grischka <grishka@gmx.de> writes:

>> Obviously, there is no reason to choose words perversely (e.g. use
>> "red" when we mean green).
>
> Or use "scroll-up" where it means scroll down, or use "split-horizontally"
> where it splits vertically ;)

Good one. Sometimes Emacs makes me wonder if I suffer from some type of
spatial disability.

The Emacs community has a more serious confussion discriminating what's
good and what's bad among two opposites, though:

A few weeks ago I was required to translate an old, small Visual Basic
application to C#. I was less than thrilled with the job, but anyways
the first thing was to configure Emacs as a C# editor. There is
csharp-mode, which does code formatting. So far, so good. There are two
methods for code completion, one based on CEDET and the other on an
external tool. The CEDET method was a nonstarter, the other worked
so-so. As I'm an absolute beginner on C# and it comes with a vast API,
code completion was too much of a time-saver to be neglected. After 3
hours trying to raise Emacs to the minimum usability level, I gave up
and tried certain popular IDE, out of despair. 15 minutes later my
client's application, on its basic inception, was running on the screen,
mostly thanks to an accurate and fast code completion system that not
only shows the candidates for completion, but also displays some
documentation explaining what every method does. This saves a lot of
time browsing documentation.

The mentioned code completion system on that IDE is a marvel for
beginners but, as it constantly pops on the screen hiding the code
below, maybe it is a pain for experienced hackers who know the API
well. Of course there is a knob for disabling it.

The crux of the matter is that the IDE comes ready to be as helpful as
possible for beginners, and adds options for turning features on and off
as you adquire experience. This is equivalent to saying that the IDE
comes preconfigured for making converts and then it assumes that as
those newcomers adquire experience they will learn how to adapt things
to their taste.

Emacs does just the opposite. See how people on this discussion says "of
course the new Emacs user will read the Tutorial etc." I was able to
write and run a basic application on a language that I barely know,
using a IDE for the first time, in less time that it takes to read the
Emacs tutorial. Translating the 5000 LOC Visual Basic application to C#
required less time than I needed for learning and configuring Emacs for
matching the usability level of my previous editor, ten years ago (and
now it wouldn't require much less work.)

The GNU project, and Emacs specifically, is about producing Free
software for the people. "People" here means all potential audience. In
practice, Emacs today is mostly focused on bringing incremental
improvements for current users, caring little about the demands and
expectations of the rest of world. It is disheartening to see how every
time that someone proposes a tiny change on the default configuration
for lowering the entry barrier, a vociferous group of reactionaries try
to block the initiative, usually winning the fight, just because they
don't want to add a line or two to their .emacs file.

IMAO the Emacs maintainers should ignore the winning and threatening of
those users and focus on making Emacs as attractive as possible to the
new generations of hackers. Having gratuitous oddities, expecting a
sustained effort from the prospective user until he perceives the
virtues of Emacs, being dismissive towards competing tools instead of
learning why they are attracting more users than Emacs... is simply
wrong.

The user who must be happy with Emacs is the user who doesn't know it
yet.

[snip]

Re: Emacs learning curve

[immanuel litzroth]

> Emacs does just the opposite. See how people on this discussion says "of
> course the new Emacs user will read the Tutorial etc." I was able to
> write and run a basic application on a language that I barely know,
> using a IDE for the first time, in less time that it takes to read the
> Emacs tutorial. Translating the 5000 LOC Visual Basic application to C#
> required less time than I needed for learning and configuring Emacs for
> matching the usability level of my previous editor, ten years ago (and
> now it wouldn't require much less work.)

Good, how does this IDE do for Lisp on Linux or Haskell on MacOSX? Can you
give more info about this IDE?
Immanuel

RE: Emacs learning curve

[Drew Adams]

> >> Obviously, there is no reason to choose words perversely
> >> (e.g. use "red" when we mean green).
> >
> > Or use "scroll-up" where it means scroll down, or use 
> > "split-horizontally" where it splits vertically ;)
> 
> Good one.

Actually no, bad one.

I specifically chose red/green and _not_ up/down, because up from one vantage
point is down from another.  _Not_ so for red/green.  It is not perverse to call
something "up" which someone else might naturally think of as down - it depends
on the context.

The question of whether to consider scrolling from the point of view of the view
port / window or the point of view of the paper / data surface / buffer (which
is moving?) is as old as the hills.  And the answer sometimes depends on the
particular application in a logical way (think cockpit); otherwise it is
arbitrary.

Similar considerations apply to splitting horizontally/vertically.  We can all
agree on which is horizontal and which is vertical between _ and |, but what
happens when something is _split_ horizontally?

As soon as you say "split", the ambiguity/choice goes away.  A different verb
choice could have been made.  If the choice were to call it "duplicating" the
window, then it might make sense to call what we call horizontal splitting
"vertical duplicating": you duplicate a window above or below itself.

But with the point of view of splitting (the verb), the answer unambiguosly
agrees with Emacs terminology - you do in fact split the window horizontally.
Take an axe, hold it horizontally, and split the window.  Go ahead.  You get two
windows disposed vertically, one above the other.  It is simply incorrect to say
that "`split-horizontally' splits vertically".  Bad one, I'm afraid.

Looking at the _result_ rather than the action of splitting, you can indeed make
the point that the result is a vertical configuration.  That's what you see,
vertical placement, and that's what you care about, so you could well argue that
`vertical' should be part of the name somehow.

But you could also argue that the window dividing line, which is also a result,
is horizontal.  It's arguably a toss-up, but I would agree that the windows and
their placement are more important than the orientation of the divider.

But wrt the action, if it is viewed as a splitting action (and not, say,
duplicating), there is only one correct answer: the terminology that Emacs uses.
Should Emacs have chosen to think about the action as splitting?  Should Emacs
have emphasized the verb/action and not the resulting positions?  This is
arguable, but it's not terribly interesting either way.

What's the point? (1) The Emacs terminology for up/down vertical/horizontal
(split) is not silly.  (2) Some such things are arbitrary, or you can at least
come up with reasonable arguments for either choice.  (3) The same is not true
for other things, such as red/green.  And that's why I purposefully chose
red/green for my example.

So no, the petty put-down, trying to use `split-horizontally' to point out how
Emacs chooses words perversely, is simply not well thought through.  I'm sure
there are some examples of poor word choice in Emacs terminology, but your
argument based on the example of up/down is specious.

And what might seem "natural" to you wrt what scrolling "up" means is not
necessarily natural to everyone or, especially, to all contexts.

Some graphical design systems have both notions of scrolling (and other
view-port vs paper movements): they let you work either way, thinking either
that you are moving the window over the paper or moving the paper under the
window.

Different contexts can make one or the other point of view (and terminology)
seem more appropriate/natural.  And apps that provide alternative contexts also
employ both terminologies - they speak about both panning the view port left and
panning the paper left, meaning opposite directions.  Users can handle this
degree of complexity. ;-)

None of this is trivial or unimportant - words do matter.  And none of it has
been designed in Emacs without thought, I am sure.  That's not to say that there
is never room for improvement.  It is to say, "a little humility, please"; you
might not be the first person to think about this.  And things might not be as
silly or unnatural as you think.

(Disclaimer: I was not involved in the Emacs choices for scroll "up" or split
"horizontally".)

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >> Obviously, there is no reason to choose words perversely
>> >> (e.g. use "red" when we mean green).
>> >
>> > Or use "scroll-up" where it means scroll down, or use 
>> > "split-horizontally" where it splits vertically ;)
>> 
>> Good one.
>
> Actually no, bad one.

[snip]

> What's the point? (1) The Emacs terminology for up/down
> vertical/horizontal (split) is not silly.  (2) Some such things are
> arbitrary, or you can at least come up with reasonable arguments for
> either choice.  (3) The same is not true for other things, such as
> red/green.  And that's why I purposefully chose red/green for my
> example.

The fact is that the terminology we are discussing will cause confussion
on a relevant group of users. For them, the red/green example applies
fully. This is bad, and the designers shall avoid those cases.

BTW, the red/green issue is more real than you seem to think. Have you
developed a GUI (or any sort of visual interface) that uses colors for
communicating critical info? A color-blind subject could argue that you
are being perverse when using red and green for displaying info, no
matter you refer to them by the "right" names on the manual.

[snip]

Re: Emacs learning curve

[Drew Adams]

> BTW, the red/green issue is more real than you seem to think. Have you
> developed a GUI (or any sort of visual interface) that uses colors for
> communicating critical info? A color-blind subject could argue that
> you are being perverse when using red and green for displaying info,
> no matter you refer to them by the "right" names on the manual.

Sigh.  I was afraid of this.  You are probably not truly missing the point (I
hope), but you are certainly acting as if you were.  Mauvaise foi, it must be.

If I had picked black/white you would be saying that I am not sensitive to race
issues - or that I am too sensitive.  Spare me the lecture that you hope
presents you with an easy out and skirts the issue - too facile.

FWIW, I work with UI accessibility everyday.  I am well aware of the need to
avoid use of color to convey info that is not conveyed any other way.
Everything I produce at work must pass WCAG, FRA508 (US), and other
accessibility guidelines (Oracle's guidelines are a superset).

You have raised a red herring (yes red, not green ;-)).  This is not about
red/green color sensitivity or UI accessibility.  NOT AT ALL.

Think red end of the E-M spectrum vs blue end, if it helps.  The point is that
there are some distinctions that do not have the same degree of relativity as
up/down.  One person's red end of the spectrum is the same end of the spectrum
as another person's red end of the spectrum.  Whether they both see the same
thing (or anything at all) when they look at a given color is another story.

Forget the sophistry and think through the arguments.  Yes, everything is
relative, including relativity of all sorts; quantity does turn into quality;
black can be white; and positive can be negative.  The universe (and
anti-universe) are dialectical at all levels, and all levels emerge and
interpenetrate.  Now back to your regularly scheduled program.

 "There is a fifth dimension, beyond that which is known to man.
  It is a dimension as vast as space and as timeless as infinity.
  It is the middle ground between light and shadow, between science
  and superstition, and it lies between the pit of man's fears and
  the summit of his knowledge. This is the dimension of imagination.
  It is an area which we call The Twilight Zone."   - Rod Serling

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> BTW, the red/green issue is more real than you seem to think. Have you
>> developed a GUI (or any sort of visual interface) that uses colors for
>> communicating critical info? A color-blind subject could argue that
>> you are being perverse when using red and green for displaying info,
>> no matter you refer to them by the "right" names on the manual.
>
> Sigh.  I was afraid of this.  You are probably not truly missing the
> point (I hope), but you are certainly acting as if you were.  Mauvaise
> foi, it must be.

No, I'm not missing the point at all. Whoever chose the terms
split-window-horizontally and split-window-vertically did a suboptimal
job, because they mean different things to different people, and using
ambiguous terms or expressions must be avoided. The fact that this
sub-topic arised is proof of the problematic nature of those terms.

And usage of down/up on Emacs (as for scrolling) contradicts current
stablished practice. Yes, there is a reasoning for doing what Emacs
does, but the issue is that it is contrary to the expectations of almost
anybody who learned to use computers on the last 20 years.

Terms must convey meaning to users, not confuse them.

[snip]

RE: Emacs learning curve

[Drew Adams]

> Whoever chose the terms split-window-horizontally and
> split-window-vertically did a suboptimal job, because they
> mean different things to different people,

Not in English, they don't.  I explained this.

That people might not read English well or think about the names well is
understandable.  That people get confused about this is also understandable.
Lots of people even confuse horizontal with vertical, or left with right,
believe it or not!  That's life.

But in English, if you split something horizontally then the split line runs
horizontally, and the resulting pieces are situated one above the other, stacked
vertically.  Sorry, but this is _not_ a matter of opinion.  It is a matter of
geometry/space/topology.  (Please, no red-herring rejoinders about Klein bottles
or Moebius strips.)

> and using ambiguous terms or expressions must be avoided.

We do agree - no doubt all of us.

The devil is in the details, however.  Blanket statements like that do not help.
Pick a concrete term that you think is ambiguous and discuss it.  Then something
might come of it.

> The fact that this sub-topic arised is proof of the problematic
> nature of those terms.

Nonsense.  It might be proof that some readers/users are not super-proficient in
English.  And I would agree that an Emacs user should not need to be _super_
proficient in English.  But there is nothing incorrect or ambiguous about the
term `split-window-horizontally'.

As I said, scroll up/down is a different matter, because of the relative nature
(point of view).  Call that one an arbitrary choice, if you like.  Consider it a
bad choice, if you like.  It remains unimportant in the grand scale of Emacs
deficiencies.

You might better complain that `C-x 2' and `C-x 3' are not such great bindings
for splitting windows.  Or that they should be reversed, for some reason.  All
of this is inconsequential.

> And usage of down/up on Emacs (as for scrolling) contradicts current
> stablished practice.

Maybe you mean that in the "established practice" when you hit the PageDown key
you move up the page, not down (so the page moves down)?  It doesn't in the
applications that I use outside Emacs, but I'm willing to suspend doubt and take
your word for it.

Or maybe you just mean that the command `scroll-up-command' moves the opposite
way from the established notion of upward movement.  Is that it - the PageDown
key does the right thing in Emacs, but its command is called
`scroll-up-command'?  OK, I agree that we might better have called it
`page-down-command'.

Would it help attract new users if we renamed it `page-down-command'?  Is that
your argument?  For things like scrolling it really _does not matter_ that
Emacs's `up' in the command name might be the down of "established practice".
It really doesn't.

Unless you are programming with Emacs Lisp or you invoke `scroll-up' via `M-x'
you will never come across the command name `scroll-up-command'.

Well, you will see it in the doc, if you look for it, but in that case the
explanation is unambiguous and there should be zero difficulty understanding.
The doc does speak in terms of scrolling upward but it says that the _text_ is
scrolled upward, which it is.  It is the view port that moves downward, _not_
the page.  The window moves down the page.

The doc tries to explain the behavior but also relate it to the command name.
You (someone) would surely complain if the name were `scroll-up-command' but the
doc spoke only in terms of the window moving downward.

You could argue that it is the (keyboard) key name PageDown that is misnamed,
because the page itself (the text) moves up, not down.  Perhaps we should lobby
keyboard manufacturers to change the name to WindowDown or to PageUp?

Do you see that arguing about this is like arguing about how many angels fit on
the head of a pin?  The window moves down or the page moves up - take your pick.
And it doesn't matter a lot what we call the movement command, as long as we are
consistent. 

Arguing that Emacs is perverse and out of step with "established practice" on
the basis of an example such as scrolling orientation is truly making a mountain
out of an extinct mole hill that has since eroded to be 100% flat.

> Yes, there is a reasoning for doing what Emacs
> does, but the issue is that it is contrary to the 
> expectations of almost anybody who learned to use computers
> on the last 20 years.

Nonsense - no, I shouldn't say that.  It depends what you mean.  Be specific.

If you mean that the command name `scroll-up-command' is contrary to user
expectations, then I would indeed say, "Nonsense".  No user has a great
expectation about a command named `scroll-up-command', nor does anyone care.
Most users of most editors - including Emacs - do not invoke scroll commands by
name.

Now suppose that hitting the down arrow (called `down', BTW) moved the cursor up
instead of down.  Provided that the user's mental model for this key is for
cursor movement, that would indeed be perverse.

On the other hand, if the command bound to `down' were called `buffer-up'
instead of `next-line', and if it made sense for Emacs users to have a mental
model of the arrow keys as scrolling the buffer under the cursor instead of
moving the cursor within the buffer, then the arrow direction would not fit the
mental model of upward (buffer) movement.  That would be perverse.

Naming the down arrow `up' would also be downright perverse (but that too would
not have a lot of impact).

Perversion in this regard means doing something that is illogical.  Doing
something that might not correspond to "established practice" is not necessarily
perverse.  It might or might not be perverse.

Would you say that someone who speaks only Catalan is perverse, because Chinese
is the current "established practice" worldwide, or because Spanish is the
"established practice" in Spain?

http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers

Pick a word that you think is "naturally" feminine in Spanish.  See if it is
feminine in French or German.  You might be surprised at the perversion you will
find.  And some other languages can find even the notion of word gender
unnecessary, arbitrary, illogical, or perverse.

Maybe Emacs is a foreign language to "almost anybody who learned to use
computers on the last 20 years".  It still gets its tourists, though, oddly
enough.  And yes, some of those tourists do COMPLAIN LOUDLY that everything is
NOT LIKE IT IS BACK HOME IN KANSAS AND IT SHOULD BE - NOW!  Maybe someday it
will be.  On n'arrete pas le progres.

> Terms must convey meaning to users, not confuse them.

A stitch in time saves nine.  Early to bed and early to rise makes a man
healthy, wealthy, and wise.

Platitudes do not advance the schmilblick, I'm afraid.

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

[snip]

You have several good points wrt the interpretation of "split" and the
internal usage on up/down scrolling.

I think we agree on the desirability of not confusing the user with odd
terms and on not entrenching an Emacs dialect with words that have a well
established meaning outside Emacs. At the same time it is not necessary
to care too much about terms not exposed to the end user.

> Would it help attract new users if we renamed it `page-down-command'?  Is that
> your argument?

No, not at all. Using familiar terms for newcomers will not attract
them. Using a friendly and clear terminology (at least for the
user-visible commands) will not *scare* *away* prospective users.

[snip]

> Perversion in this regard means doing something that is illogical.  Doing
> something that might not correspond to "established practice" is not necessarily
> perverse.  It might or might not be perverse.
>
> Would you say that someone who speaks only Catalan is perverse, because Chinese
> is the current "established practice" worldwide, or because Spanish is the
> "established practice" in Spain?

Suppose you go to Barcelona and ask for some indication to a nearby
pedestrian. You ask in Spanish, because you don't speak Catalan, and you
know that to all practical effects, every Catalan speaks Spanish. But
you get an answer in Catalan. (Actualy, this is a very typical scenario
on real life.) You think "This guy is not interested on
communicating. He must be one of those arrogant Catalans who enjoys
demonstrating his despise of Spain."  Most of the time, the truth is
that as you are assuming he speaks Spanish, he is assuming you
understand Catalan, which is a very reasonable assumption for anyone to
make in Catalonia. But too often the outcome is that you go away
irritated with that person, who probably tried to give you a helpful
response.

Likewise, if someone looks at Emacs and starts seeing familiar terms
used on an odd way, strange terms used for naming usual concepts with
well stablished names, etc. he may end thinking that the Emacs project
lacks the resources for staying with the times, or that its developers
are prone to use an internal dialect for whatever reason. In the best of
cases, he will perceive an extra difficulty while learning Emacs. At the
worst, he'll see the Emacs "dialect" as an hostile sign. The truth is
that the Emacs community welcomes new people and is happy to communicate
with them, but having a dialect that adds nothing to Emacs' experience
doesn't help to transmit a warm impression to the prospective user.

BTW, I'm not saying that switching terms will make Emacs popular
overnight, nor that not doing it will mean the death of Emacs.

[snip]

RE: Emacs learning curve

[Drew Adams]

[interesting stuff snipped]

> he may end thinking that the Emacs project
> lacks the resources for staying with the times

In fact Emacs might well have insufficient (human) resources for staying with
the times.  But thanks to participation by people like you it does have some
such resources.

We've seen no real demonstration in this thread that there is a dwindling
interest in Emacs by users (which was the claim that started the thread), but I
would be willing to guess that there is insufficient new blood in the Emacs
development community.

I have nothing to back up that guess, but that's my guess.  I am not worried
about the future of Emacs (as I said, it will be here long after we are gone),
and I am especially not worried (at all) about insufficient numbers of new
users.  But I do think the circle of developers/contributors remains smaller
than it could be.

Re: Emacs learning curve

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:
> 
> We've seen no real demonstration in this thread that there is a dwindling
> interest in Emacs by users (which was the claim that started the thread), but I
> would be willing to guess that there is insufficient new blood in the Emacs
> development community.
>

That's why Emacs should be made more attractive to newbies and
old timers shouldn't resist UI changes. More new blood means more
testers/developers (some of them would definitely want to help out), 
so it would be healthy for Emacs in general.

BTW, regarding the question if there is a dwindling interest in Emacs
I found a discussion with various opinions on the subject:

Young people using Emacs?
http://stackoverflow.com/questions/518669/young-people-using-emacs

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> Drew Adams <drew.adams <at> oracle.com> writes:
>> 
>> We've seen no real demonstration in this thread that there is a
>> dwindling interest in Emacs by users (which was the claim that
>> started the thread), but I would be willing to guess that there is
>> insufficient new blood in the Emacs development community.
>>
>
> That's why Emacs should be made more attractive to newbies and old
> timers shouldn't resist UI changes. More new blood means more
> testers/developers (some of them would definitely want to help out),
> so it would be healthy for Emacs in general.

New blood is less likely to cope with an incoherent mess than with
consistent old-style stuff.  And that goes particularly for users likely
to become developers.  If they have to cut through layers and layers of
hoops and workarounds intended to forcefully marry code written under
different assumptions with precariously fragile stuff trying to
accommodate new users as an add-on (CUA keybindings come into mind),
they are much more likely to throw up their hands and leave the magic of
developing to the old magicians.

Coherency and clarity is much more important for gaining new developers
than customary keybindings.

-- 
David Kastrup

Re: Emacs learning curve

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> 
> Coherency and clarity is much more important for gaining new developers
> than customary keybindings.
> 


That's why CUA-style editing should be made the consistent default, so Emacs 
works like all other modern application on KDE/Gnome/Windows, etc. and the
current behavior should be provided as a compatibility mode for those who
are accustomed to the old behavior.

Advanced users should have no problem adding a single line to their .emacs
to switch on the compatibility mode e.g. (enable-classic-bindings) and new users
would enjoy the familiar CUA-style bindings out of the box.

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> David Kastrup <dak <at> gnu.org> writes:
>> 
>> Coherency and clarity is much more important for gaining new developers
>> than customary keybindings.
>> 
>
>
> That's why CUA-style editing should be made the consistent default,

It is not consistent.  It is a precarious balance between CUA and the
Emacs bindings with a different philosophy.

> so Emacs works like all other modern application on KDE/Gnome/Windows,

There is no point in dumbing down the Emacs user interface like that.
C-x is there to stay.

> Advanced users should have no problem adding a single line to their
> .emacs to switch on the compatibility mode
> e.g. (enable-classic-bindings) and new users would enjoy the familiar
> CUA-style bindings out of the box.

What about "consistent" did you not understand?

-- 
David Kastrup

Re: Emacs learning curve

[Miles Bader]

Tom <levelhalom@gmail.com> writes:
> That's why CUA-style editing should be made the consistent default, so Emacs 
> works like all other modern application on KDE/Gnome/Windows, etc. and the
> current behavior should be provided as a compatibility mode for those who
> are accustomed to the old behavior.

Isn't going to happen.

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: Emacs learning curve

[Tom]

Miles Bader <miles <at> gnu.org> writes:

> 
> Tom <levelhalom <at> gmail.com> writes:
> > That's why CUA-style editing should be made the consistent default, so Emacs 
> > works like all other modern application on KDE/Gnome/Windows, etc. and the
> > current behavior should be provided as a compatibility mode for those who
> > are accustomed to the old behavior.
> 
> Isn't going to happen.
> 

Obviously not. And that's why Emacs won't be able attractive to
most new users, because more popular IDEs offer features which
people nowadays consider basic (excellent refactoring support,
etc.) and implementing these features requires significant
development and testing resources which Emacs doesn't have.

By keeping Emacs decidely different from other, more popular UIs
you keep most of new users out and consequently competent
contributors as well.

I guess it will be the job of a new generation of Emacs
developers (who are not so attached to doing things the old way)
to take Emacs to the next level, that is making the UI more
conformant to modern standards while retaining the features which
make Emacs so powerful (not the keybindings).

Re: Emacs learning curve

[Eli Zaretskii]

> From: Tom <levelhalom@gmail.com>
> Date: Thu, 15 Jul 2010 08:51:59 +0000 (UTC)
> 
> Miles Bader <miles <at> gnu.org> writes:
> 
> > 
> > Tom <levelhalom <at> gmail.com> writes:
> > > That's why CUA-style editing should be made the consistent default, so Emacs 
> > > works like all other modern application on KDE/Gnome/Windows, etc. and the
> > > current behavior should be provided as a compatibility mode for those who
> > > are accustomed to the old behavior.
> > 
> > Isn't going to happen.
> > 
> 
> Obviously not. And that's why Emacs won't be able attractive to
> most new users, because more popular IDEs offer features which
> people nowadays consider basic (excellent refactoring support,
> etc.) and implementing these features requires significant
> development and testing resources which Emacs doesn't have.

How on earth are those two related??  CUA Mode already exists and need
just be enabled; the IDE features need at best a lot of work, if not
implementation from ground up.  Enabling CUA by default modifies the
most basic keybindings; adding IDE features changes nothing until the
user actually activates the IDE.  Etc., etc.

> I guess it will be the job of a new generation of Emacs
> developers

Where are they?  All I see is the same old arguments about "to CUA or
not to CUA", and laments about missing refactoring support.  Will
someone please put their money where their mouth is, and DO something?

Re: Emacs learning curve

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> How on earth are those two related??  CUA Mode already exists and need
> just be enabled; the IDE features need at best a lot of work, if not
> implementation from ground up.  Enabling CUA by default modifies the
> most basic keybindings; adding IDE features changes nothing until the
> user actually activates the IDE.  Etc., etc.
> 

The logic goes:

1. we don't have a killer application out of the box with zero
configuration like refactoring support, etc. It needs lots of work.

2. we have a UI which is very different from the ones in popular 
  systems (e.g. keybindings)

3. since we don't have a killer feature which is instantly appealing
to newcomers and we have a different ui, they usually say, in my
experience: Why should I bother with it?  Why should I learn new
keys for copy/paste if there is not killer feature?

4. by making the UI more similar (by default, without any necessary
configuration) to other popular systems, we lower the barrier of entry. 
Casual users can try emacs with no upfront effort and some of them
will be interested to learn more about it if they like what they see
and experience. First impression matters.

5. If more casual users try emacs the more chance there is they become
regular user and maybe even contributors.

6. By taking the conservative estimate that 1 percent of new users
become emacs hackers who contribute something worthwhile (code,
documentation, testing, etc.) then if we can attract 1000 more new
users we can get 10 good contributors. If we can attract 10000,
we get a 100.


That's why I think making emacs more appealing to new users is important.
More users means more hackers (that 1 percent, that is) and more hackers 
means more development resources which leads to a better emacs.

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> How on earth are those two related??  CUA Mode already exists and need
>> just be enabled; the IDE features need at best a lot of work, if not
>> implementation from ground up.  Enabling CUA by default modifies the
>> most basic keybindings; adding IDE features changes nothing until the
>> user actually activates the IDE.  Etc., etc.
>
> The logic goes:
>
> 1. we don't have a killer application out of the box with zero
> configuration like refactoring support, etc. It needs lots of work.
>
> 2. we have a UI which is very different from the ones in popular 
>   systems (e.g. keybindings)
>
> 3. since we don't have a killer feature which is instantly appealing
> to newcomers and we have a different ui, they usually say, in my
> experience: Why should I bother with it?  Why should I learn new
> keys for copy/paste if there is not killer feature?

Why should they switch their editor at all if there "is not killer
feature", never mind the keybindings?

Why would they become contributors when being able to program/contribute
is not attractive (not killer feature) for them?  Why would people
bothered by keybindings switch to an editor where they need to
contribute code before it becomes tolerable for them?

> 6. By taking the conservative estimate that 1 percent of new users
> become emacs hackers who contribute something worthwhile (code,
> documentation, testing, etc.) then if we can attract 1000 more new
> users we can get 10 good contributors. If we can attract 10000, we get
> a 100.

People who can't be bothered to think about keybindings can't likely be
bothered to think about programming.

So the kind of new users you are trying to attract would likely have a
worse contributor ratio than that.  They will have a non-zero whine
factor, however.  You'll be more than busy enough catering for their
superficial complaints and feature remapping requests ever to get around
to implementing a killer feature.

> That's why I think making emacs more appealing to new users is
> important.  More users means more hackers (that 1 percent, that is)
> and more hackers means more development resources which leads to a
> better emacs.

I have my doubts.

-- 
David Kastrup

Re: Emacs learning curve

[Tom]

David Kastrup <dak <at> gnu.org> writes:

> Why should they switch their editor at all if there "is not killer
> feature", never mind the keybindings?
> 

Maybe they use Eclipse which is a bloated monster, and while they do Java 
development in it, they want a more efficient editor for their simpler editing
needs. Why couldn't Emacs be this editor if it is easy to use casually?
(Not having to learn new things to use it.) And if we can get them to use it
they may even get to like it and want to learn more about it.


> Why would they become contributors when being able to program/contribute
> is not attractive (not killer feature) for them?  Why would people
> bothered by keybindings switch to an editor where they need to
> contribute code before it becomes tolerable for them?

Most of the new users won't be contributors. They
will be simple users who use Emacs for simple tasks. But some percent of 
them would become contributors who would like to help out if they grow to 
like Emacs.


> So the kind of new users you are trying to attract would likely have a
> worse contributor ratio than that.  They will have a non-zero whine
> factor, however.  You'll be more than busy enough catering for their
> superficial complaints and feature remapping requests ever to get around
> to implementing a killer feature.
> 

You forget one thing: users of popular tools often runs forums and stuff
to help out others. So even if not all new users would contribute code
they would write blogs, answer questions, etc. so they could even take
such load off the core developers and they could concentrate on important
issues more.

More users means more whiners, but more helping hands too who would help
in the janitorial work.

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> Why should they switch their editor at all if there "is not killer
>> feature", never mind the keybindings?
>> 
>
> Maybe they use Eclipse which is a bloated monster, and while they do
> Java development in it, they want a more efficient editor for their
> simpler editing needs. Why couldn't Emacs be this editor if it is easy
> to use casually?

Uh, because it fits the "bloated monster" moniker at least as well?

-- 
David Kastrup

Re: Emacs learning curve

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> >
> > Maybe they use Eclipse which is a bloated monster, and while they do
> > Java development in it, they want a more efficient editor for their
> > simpler editing needs. Why couldn't Emacs be this editor if it is easy
> > to use casually?
> 
> Uh, because it fits the "bloated monster" moniker at least as well?
> 


According to my limited experience with Eclipse Emacs is a slim dancer 
compared to it.

Re: Emacs learning curve

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

[snip]

> People who can't be bothered to think about keybindings can't likely be
> bothered to think about programming.

This is so wrong.

Have you ever re-trained your muscle memory for something you do 500
times a day while being concentrated on a higher level task? That every
time it goes wrong your concentration suffers and hence is irritating as
hell? Can you think of the level of motivation required for suffering
that pain for days, maybe weeks, until you are accustomed to the new
keybindings?

Emacs' idiosyncratic keybindings are, without doubt, the higher entry
barrier nowadays. Maybe it wasn't so 15 years ago, when people assumed
that every application had different keybindings for the same trivial
chores, but those times are long gone. The least thing Emacs can do is
to advertise with big letters on the welcome screen something like:

IF YOU ARE NEW TO EMACS, CLICK HERE IF YOU WANT TO USE KEYBINDINGS WICH
CONFORMS ARE MORE FAMILIAR TO YOU.

and figure out how to display the correct keybindings on the
documentation when the user has cua-mode activated.

[snip]

Re: Emacs learning curve

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
> [snip]
>
>> People who can't be bothered to think about keybindings can't likely be
>> bothered to think about programming.
>
> This is so wrong.
>
> Have you ever re-trained your muscle memory for something you do 500
> times a day while being concentrated on a higher level task?

I used vi before Emacs.  I switched to the chromatic button accordion
from playing piano accordion and am playing more than 500 notes per day.

> That every time it goes wrong your concentration suffers and hence is
> irritating as hell? Can you think of the level of motivation required
> for suffering that pain for days, maybe weeks, until you are
> accustomed to the new keybindings?

Accordion literature is standardized on the 41-key piano accordion.  My
CBA, in contrast, has 62 notes.  The additional notes are mostly of
interest when
a) playing music written for other instruments (like the piano or trios),
b) improvising.
c) playing music composed yourself.

So that's the level of "programmer".  Yes.

> Emacs' idiosyncratic keybindings are, without doubt, the higher entry
> barrier nowadays. Maybe it wasn't so 15 years ago, when people assumed
> that every application had different keybindings for the same trivial
> chores, but those times are long gone. The least thing Emacs can do is
> to advertise with big letters on the welcome screen something like:
>
> IF YOU ARE NEW TO EMACS, CLICK HERE IF YOU WANT TO USE KEYBINDINGS WICH
> CONFORMS ARE MORE FAMILIAR TO YOU.
>
> and figure out how to display the correct keybindings on the
> documentation when the user has cua-mode activated.

They interfere with Emacs' normal keybindings.  How are newcomers going
to figure out how to deal with partly working keybindings, depending on
how long they happen to press their keys?

-- 
David Kastrup

Re: Emacs learning curve

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 17:05:54 +0200
> 
> Emacs' idiosyncratic keybindings are, without doubt, the higher entry
> barrier nowadays.

Apart of CUA, what other keybindings out there are accepted widely
enough to make them not idiosyncratic?

Let me give you an example.  The keybinding I tend to use most in
Emacs is M-/.  Do we have anything similar in other applications?

More generally, what to do with hundreds if not thousands of
keybindings in Emacs for which there's simply no equivalent
functionality elsewhere?  Those keybindings will always be
``idiosyncratic'', because they cannot be learned anywhere.  CUA is
what? 15 keybindings?

And what if the equivalent functionality has an entirely different
look-and-feel?  A case in point is completion: would you say that we
should redesign the completion UI to be more like the Windows
Explorer's one, whereby typing a character drops down a mouse-
clickable list of possible completions?  How do you sell this to
Emacs users who have the current completion keys wired into their
fingers and brains?

From personal experience, it is not a disaster to use two different
sets of keybindings.  Yes, sometimes you will err and curse.  But it
won't let you abandon a tool that is otherwise useful.  Making Emacs
extremely useful is therefore the single most important way of making
it more popular among those who it targets.

Re: Emacs learning curve

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Let me give you an example.  The keybinding I tend to use most in
 > Emacs is M-/.  Do we have anything similar in other applications?

AFAIK, "no and yes".  No, I can't recall another application which has
this functionality on a key.  But many applications (including Firefox
and Open Office, where it drives me to distraction) will provide
dynamic autocompletion (as you yourself mentioned) with a popup menu
which you can access with TAB (in Open Office and MS Office IIRC) or
DOWN (Firefox in general, and the Google search widget, which does a
substantially better job IMO).  It is not obvious to me that providing
that feature in addition to M-/ style completion would be a bad idea.

 > From personal experience, it is not a disaster to use two different
 > sets of keybindings.  Yes, sometimes you will err and curse.  But it
 > won't let you abandon a tool that is otherwise useful.  Making Emacs
 > extremely useful is therefore the single most important way of making
 > it more popular among those who it targets.

I have to agree with that, however.  Autocompletion is at best a nice
feature for many newbies.  It won't help attract the kind of new-user-
cum-future-developer that Emacs needs.

Re: Emacs learning curve

[Uday S Reddy]

On 7/15/2010 4:39 PM, Eli Zaretskii wrote:

>  From personal experience, it is not a disaster to use two different
> sets of keybindings.  Yes, sometimes you will err and curse.  But it
> won't let you abandon a tool that is otherwise useful.  Making Emacs
> extremely useful is therefore the single most important way of making
> it more popular among those who it targets.

In my humble opinion, the critics are right here.

I don't switch to new applications if their key bindings conflict with my Emacs 
neurons.  When I tried Eclipse, I quickly found the option to set Emacs key 
bindings and turned them on.  I was extremely irritated wherever it didn't 
match Emacs.

Just as Eclipse is kind to Emacs-users, I think Emacs should be kind to 
Eclipse-users too, and Windows-users and KDE-users and what have you. 
Obstinacy doesn't do us any good.

Cheers,
Uday

Re: Emacs learning curve

[Miles Bader]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> Just as Eclipse is kind to Emacs-users, I think Emacs should be kind to
> Eclipse-users too, and Windows-users and KDE-users and what have
> you. Obstinacy doesn't do us any good.

Yeah, but Emacs _is_ kind to those users, to the extent that it's
practical and reasonable.  E.g., cua-mode, the addition of shift-select
(on by default), etc.

The problem with Tom's "proposal" is that he seems to want Emacs to make
a complete wholesale change to a different (and inferior, but that's not
really the issue) set of bindings, and that's _not_ practical or
reasonable.

-Miles

-- 
Congratulation, n. The civility of envy.

Re: Emacs learning curve

[Tassilo Horn]

On Friday 16 July 2010 11:15:37 Uday S Reddy wrote:

> I don't switch to new applications if their key bindings conflict with
> my Emacs neurons.  When I tried Eclipse, I quickly found the option to
> set Emacs key bindings and turned them on.

That's what I do, too, but it doesn't help much.  I frequently find
myself hitting `C-y M-y' in Eclipse to paste text that I have cut before
the last cut.  But then I have to face the fact that cut&paste is not
kill&yank...

Remapping keys doesn't help much if the underlying concepts aren't the
same.

Bye,
Tassilo

Re: Emacs learning curve

[Eli Zaretskii]

> From: Tom <levelhalom@gmail.com>
> Date: Thu, 15 Jul 2010 09:27:59 +0000 (UTC)
> 
> The logic goes:
> 
> 1. we don't have a killer application out of the box with zero
> configuration like refactoring support, etc. It needs lots of work.
> 
> 2. we have a UI which is very different from the ones in popular 
>   systems (e.g. keybindings)
> 
> 3. since we don't have a killer feature which is instantly appealing
> to newcomers and we have a different ui, they usually say, in my
> experience: Why should I bother with it?  Why should I learn new
> keys for copy/paste if there is not killer feature?
> 
> 4. by making the UI more similar (by default, without any necessary
> configuration) to other popular systems, we lower the barrier of entry. 
> Casual users can try emacs with no upfront effort and some of them
> will be interested to learn more about it if they like what they see
> and experience. First impression matters.
> 
> 5. If more casual users try emacs the more chance there is they become
> regular user and maybe even contributors.
> 
> 6. By taking the conservative estimate that 1 percent of new users
> become emacs hackers who contribute something worthwhile (code,
> documentation, testing, etc.) then if we can attract 1000 more new
> users we can get 10 good contributors. If we can attract 10000,
> we get a 100.
> 
> 
> That's why I think making emacs more appealing to new users is important.
> More users means more hackers (that 1 percent, that is) and more hackers 
> means more development resources which leads to a better emacs.

Well, Notepad has all the familiar UI you are talking about, but
somehow it doesn't attract "more hackers".  I guess your logic lacks
something important.

Re: Emacs learning curve

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Well, Notepad has all the familiar UI you are talking about, but
> somehow it doesn't attract "more hackers".  I guess your logic lacks
> something important.
> 

Have you seen the image of the learning curve of editors?

http://bc.tech.coop/blog/060302.html


Notepad has a limited feature set which obviously doesn't inspire its 
users.

On the other hand Emacs has much more depth than that. The goal is to make 
emacs easier to use for the newcomer, so he stays for a while and has a 
chance to discover emacs is a beautiful swan in the disguise of an ugly
duckling. :)

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> Well, Notepad has all the familiar UI you are talking about, but
>> somehow it doesn't attract "more hackers".  I guess your logic lacks
>> something important.
>> 
>
> Have you seen the image of the learning curve of editors?
>
> http://bc.tech.coop/blog/060302.html
>
>
> Notepad has a limited feature set which obviously doesn't inspire its 
> users.
>
> On the other hand Emacs has much more depth than that. The goal is to make 
> emacs easier to use for the newcomer, so he stays for a while and has a 
> chance to discover emacs is a beautiful swan in the disguise of an ugly
> duckling. :)

So why disguise is as an ugly duckling in the first place?

-- 
David Kastrup

Re: Emacs learning curve

[Eli Zaretskii]

> From: Tom <levelhalom@gmail.com>
> Date: Thu, 15 Jul 2010 10:14:17 +0000 (UTC)
> 
> Have you seen the image of the learning curve of editors?
> 
> http://bc.tech.coop/blog/060302.html

If you base your views on such "evidence", then good luck!

> The goal is to make emacs easier to use for the newcomer, so he
> stays for a while and has a chance to discover emacs is a beautiful
> swan in the disguise of an ugly duckling. :)

No, the goal is to attract more programmers to using Emacs as their
primary programming tool.  You seem to think that enabling CUA will
somehow make a significant step towards that goal, because it will
cause them "to stay for a while".  I think that staying for another 5
minutes will gain nothing, because C-x and C-v are not useful enough
for writing code.

Programmers need features that help them do their job.  If we want to
bring more of them on board, there's no way around providing those
features.  No amount of arguing about CUA and this or that keybinding
will be ever able to do anything significant in the direction we all
want to go.  It's high time to stop talking and start doing.  It's
high time to stop being afraid of "insufficient resources" and "too
large jobs", and start coding.  If you want encouragement, just count
how many KLOCs we add to Emacs each month.

Re: Emacs learning curve

[Alfred M. Szmidt]

Can we please stop with the extravagant claim that new users are not
attracted to emacs because of some idiosyncratic bindings?  It is true
that there are features thatemacs lacks, or are suboptimal, that some
popular editors have, but the bindings don't scare anyone.  Repating
that claim won't make it true.

One should strive for what is sensible and logical, not what is
currently modern and popular.  The reason people are attached to "the
old way" is because it makes sense, and it has proven itself over 30
years.

Re: Emacs learning curve

[Óscar Fuentes]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Can we please stop with the extravagant claim that new users are not
> attracted to emacs because of some idiosyncratic bindings?

That claim is extravagant indeed. The users are not attracted by the
idiosyncratic keybindings, they are *repelled* by them.

> It is true that there are features thatemacs lacks, or are suboptimal,
> that some popular editors have, but the bindings don't scare anyone.
> Repating that claim won't make it true.

You talk as if we were making up something. My own personal experience
as an Emacs novice (long time ago) as well as while trying to introduce
others to Emacs, plus lots of testimonials on the Internet, had
convinced me that the keybindings are the most serious entry barrier,
except for the cases where the new user lacks a long experience with
editors that follows CUA.

> One should strive for what is sensible and logical, not what is
> currently modern and popular.  The reason people are attached to "the
> old way" is because it makes sense, and it has proven itself over 30
> years.

If there is something in Emacs that is not sensible nor logical, that's
the keybindings. Not only they are different from the current
established ones, they often seem planned with the clear intention
of causing RSI :-)

Re: Emacs learning curve

[Tassilo Horn]

On Friday 16 July 2010 19:12:18 Óscar Fuentes wrote:

> If there is something in Emacs that is not sensible nor logical,
> that's the keybindings. Not only they are different from the current
> established ones, they often seem planned with the clear intention of
> causing RSI :-)

This heavily depends on your keyboard layout.  IMO, the worst decision a
developer of an editor can make is to base the keybindings on one
specific layout.  For example, vi's hjkl-movement bindings are totally
awkward on my German Dvorak Type II keyboard.  In contrast, emacs C-n,
C-f, C-b and C-p have mnemonics which are clear and independent from the
layout.

Similarly, C-k, C-y and M-y have clear mnemonics derived from the
concepts of killing and yanking.

Bye,
Tassilo

Re: Emacs learning curve

[Óscar Fuentes]

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Friday 16 July 2010 19:12:18 Óscar Fuentes wrote:
>
>> If there is something in Emacs that is not sensible nor logical,
>> that's the keybindings. Not only they are different from the current
>> established ones, they often seem planned with the clear intention of
>> causing RSI :-)
>
> This heavily depends on your keyboard layout.

Yes, I'm using a very expensive keyboard just because it has a great
ergonomics for working with Emacs.

[snip]

> Similarly, C-k, C-y and M-y have clear mnemonics derived from the
> concepts of killing and yanking.

Worrying about mnemonics for operations you do hundreds of times per day
is a waste.

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-16 19:38 (+0200), Óscar Fuentes wrote:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>> Similarly, C-k, C-y and M-y have clear mnemonics derived from the
>> concepts of killing and yanking.
>
> Worrying about mnemonics for operations you do hundreds of times per
> day is a waste.

Exactly. Vi editor has very ergonomic movement and editing keys (and
elegant operator+movement concept). Whether one's power editor of choice
is Emacs or Vim the point is always ergonomics and muscle memory, not
mnemonics-logical in simple f=forward, b=backward level.

Re: Emacs learning curve

[Tassilo Horn]

On Friday 16 July 2010 20:11:45 Teemu Likonen wrote:

> Exactly. Vi editor has very ergonomic movement and editing keys (and
> elegant operator+movement concept).

Try using VI on one of those layouts, and then tell me if it's
convenient:

  http://itproductivitytools.com/images/dvorak.jpg
  http://neo-layout.org/grafik/druckvorlage/neo-druckvorlage.png

Bye,
Tassilo

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-16 20:23 (+0200), Tassilo Horn wrote:

> Try using VI on one of those layouts, and then tell me if it's
> convenient:
>
>   http://itproductivitytools.com/images/dvorak.jpg
>   http://neo-layout.org/grafik/druckvorlage/neo-druckvorlage.png

I know that Vi’s movement keys (hjkl) were designed for QWERTY keyboard.
But Emacs’s default C-f, C-b, C-n and C-p are also spread all over the
place in those keyboards. Emacs’s mnemonics (fbnp) won’t make them
ergonomic and nice for new (power) users to adopt.

In order to make editing keys ergonomic and elegant, Dvorak people need
to rebind some keys anyway and that’s in both Vi and Emacs. The
difference is that the default Vi keys are very much optimal for QWERTY
keyboard, and QWERTY is what most people use. Emacs movement and editing
keys are not ergonomically optimal for _any_ well-known keyboard layout.

You know, the arrow keys are in reversed T position:

      ↑    
    ← ↓ →

People learn to use them very easily because of their mutual positions
and because they are friendly for muscle memory, not because there are
(mnemonic) arrows painted on them.

Powerful text editor should depend on ergonomics and muscle memory and
make rebinding keys easy (for different keyboard layouts like Dvorak).
While Emacs is otherwise very powerful text editor it has these serious
flaws:

  - The default movement keys are not ergonomic.
    
  - While rebinding movement keys is technically easy, in practice it is
    very difficult because many/some major modes will reuse the f-b-n-p
    mnemonic practice anyway. User would need tons of custom hooks for
    different major modes to change bindings like C-c C-fbnp to
    something more ergonomic.

The established (mnemonic) practice leaves me to conclude that
tolerating the suboptimal default keys is still lesser pain. The
situation is suboptimal but will probably never change.

Re: Emacs learning curve

[Miles Bader]

Teemu Likonen <tlikonen@iki.fi> writes:
>   - The default movement keys are not ergonomic.

Bullshit.

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Emacs learning curve

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Teemu Likonen <tlikonen@iki.fi> writes:
>>   - The default movement keys are not ergonomic.
>
> Bullshit.

My first computer had its cursor keys to the left and right of the space
bar, in a natural ordering.
<URL:http://www.nascomhomepage.com/pics/NASKBD.JPG>
That was ergonomic.

The keys were contactless (inductive IIRC).  Indestructable, good
response and feeling.  Probably did not add more than $150 to the total
price of the computer.

Things went downhill from there.

-- 
David Kastrup

Re: Emacs learning curve

[Sean Sieger]

    Powerful text editor should depend on ergonomics and muscle memory and
    make rebinding keys easy (for different keyboard layouts like Dvorak).
    While Emacs is otherwise very powerful text editor it has these serious
    flaws:

      - The default movement keys are not ergonomic.

      - While rebinding movement keys is technically easy, in practice it is
        very difficult because many/some major modes will reuse the f-b-n-p
        mnemonic practice anyway. User would need tons of custom hooks for
        different major modes to change bindings like C-c C-fbnp to
        something more ergonomic.

    The established (mnemonic) practice leaves me to conclude that
    tolerating the suboptimal default keys is still lesser pain. The
    situation is suboptimal but will probably never change.

Context has considerable bearing here.  The greater the touch typing
skill, the lesser the difficulty.  No?

You guys, I work with a 100-mph television talent, while on the air,
before the world (one can't see him do this for framing), this man types
... I'm tellin' ya 100-mph.  With an index finger and a scrunched up
hand.  I asked him, how fast, he said 100-wpm.  I want believe him, but
I take it with a grain of salt.  The point is could he ever capitalize
on key combinations, editing power like we know of Vi or Emacs?  No
way.  Right?  I also asked him about touch typing and he said his body
refuses.  Got me?  The context is our own context.  Our limitations are
our own limitations, in the center there are cool-daddy tools like GNU
Emacs.

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-16 19:07 (-0400), Sean Sieger wrote:

>> Powerful text editor should depend on ergonomics and muscle memory
>> and make rebinding keys easy (for different keyboard layouts like
>> Dvorak). While Emacs is otherwise very powerful text editor it has
>> these serious flaws:
>>
>>   - The default movement keys are not ergonomic.
>>
>>   - While rebinding movement keys is technically easy, in practice it
>>     is very difficult because many/some major modes will reuse the
>>     f-b-n-p mnemonic practice anyway. User would need tons of custom
>>     hooks for different major modes to change bindings like C-c
>>     C-fbnp to something more ergonomic.
>>
>> The established (mnemonic) practice leaves me to conclude that
>> tolerating the suboptimal default keys is still lesser pain. The
>> situation is suboptimal but will probably never change.
>
> Context has considerable bearing here.  The greater the touch typing
> skill, the lesser the difficulty.  No?

I'm not sure what you mean by context here but maybe you are right that
touch typing reduces the difficulty. I have been touch typing since
1992. I used Vim for five years and then switched to Emacs for its great
extensions and extensibility. Of course I have learned Emacs keys and be
efficient with them but I already had a great motivation to learn Emacs
for its other features. I never learned to _like_ Emacs movement keys
and feel that they are just tolerable or manageable compared to Vim.

   (I believe that there would be noticeable new interest towards Emacs
    if it, for example, announced that its version 25.1 has added a mode
    that switches to ergonomic key bindings.)

Anyway, I'm not trying to change anybody's mind about the default key
bindings. I have just been hoping that user could practically design her
own global bindings but even that's not quite possible because the
f-b-n-p mnemonics and other default keys are so deeply hard-coded
everywhere. There's not enough abstraction on that front.

I filed a bug report (with a patch) about lessening the hard-coding of
keys [1]. I also wrote a message here [2] telling that function
substitute-key-definition has problems and suggested using define-key
function with its [remap ...] feature instead. So far neither have got
any comments or actions. That's quite fine. I don't believe any more
that there is much hope for making custom global bindings practically
easier. A lot of custom hooks for redesigning major modes would be
needed anyway.

So, I'll just tolerate the default keys (I already have them deeply in
my muscle memory) and accept that improving Emacs means just extending
the environment and adding more major modes. And that's quite fine too.
No frustration nor hard feelings toward anybody. I just had a personal
hope. :-)

--------------------
 1. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6632
 2. http://thread.gmane.org/gmane.emacs.devel/127329

Re: Emacs learning curve

[Tassilo Horn]

On Saturday 17 July 2010 08:02:34 Teemu Likonen wrote:

Hi!

> I filed a bug report (with a patch) about lessening the hard-coding of
> keys [1]. I also wrote a message here [2] telling that function
> substitute-key-definition has problems and suggested using define-key
> function with its [remap ...] feature instead.

That's a valid point.  I just grepped the emacs/lisp dir for C-f and
there are quite a few modes that bind C-f instead of remapping
`forward-char', e.g. hexl, vcursor, artist, ada, calendar, hanja-util,
and some more.

I guess with addon packages the situation is even worse.  I would be
good to have some checkdoc-like command which would make authors of
elisp packages aware of such problems.

Bye,
Tassilo

Re: Emacs learning curve

[David Kastrup]

Teemu Likonen <tlikonen@iki.fi> writes:

> I'm not sure what you mean by context here but maybe you are right that
> touch typing reduces the difficulty. I have been touch typing since
> 1992. I used Vim for five years and then switched to Emacs for its great
> extensions and extensibility. Of course I have learned Emacs keys and be
> efficient with them but I already had a great motivation to learn Emacs
> for its other features. I never learned to _like_ Emacs movement keys
> and feel that they are just tolerable or manageable compared to Vim.
>
>    (I believe that there would be noticeable new interest towards Emacs
>     if it, for example, announced that its version 25.1 has added a mode
>     that switches to ergonomic key bindings.)

Get off it.  You already got crisp-mode, viper-mode, vi-mode, vip-mode,
wordstar-mode, tpu-edt-on, edt-emulation-on.

None of those have made much of an impact, even though viper-mode is
supposed to have non-zero users.

-- 
David Kastrup

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-17 09:21 (+0200), David Kastrup wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>>    (I believe that there would be noticeable new interest towards Emacs
>>     if it, for example, announced that its version 25.1 has added a mode
>>     that switches to ergonomic key bindings.)
>
> Get off it.

I hope you noticed that I really just wanted to create new global key
bindings for _myself_. But even that's not practically possible in the
Emacs environment as a whole. With the established practice the current
default bindings are consistent even though they are ergonomically
suboptimal.

Re: Emacs learning curve

[Juri Linkov]

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

> I used Vim for five years and then switched to Emacs
> for its great extensions and extensibility.

BTW, there is a famous Latin proverb "NON VI SED ARTE"
that translates as "Not with force but with skill"
or "Not by strength but by guile".  Some organizations
use it as their motto, and even cast in concrete, e.g.


[-- Attachment #2: non_vi_sed_arte.jpg --]
[-- Type: image/jpeg, Size: 29614 bytes --]

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]


Replacing one word in this phrase with almost a synonym
makes more sense :-)

"NON VI SED EMACS"

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emacs learning curve

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> I used Vim for five years and then switched to Emacs
>> for its great extensions and extensibility.
>
> BTW, there is a famous Latin proverb "NON VI SED ARTE"
> that translates as "Not with force but with skill"
> or "Not by strength but by guile".  Some organizations
> use it as their motto, and even cast in concrete, e.g.
>
>
>
>
> Replacing one word in this phrase with almost a synonym
> makes more sense :-)
>
> "NON VI SED EMACS"

I don't see how this would make more sense since "EMACS" could not
possibly be ablative case in any Latin declension.

-- 
David Kastrup

Re: Emacs learning curve

[John Yates]

On Sat, Jul 17, 2010 at 8:27 AM, David Kastrup <dak@gnu.org> wrote:
>
> I don't see how this would make more sense since "EMACS" could not
> possibly be ablative case in any Latin declension.

Took the words right out of my mouth.  Especially in a thread deeply
into issues of consistency.

/john

Re: Emacs learning curve

[Juri Linkov]

>> Replacing one word in this phrase with almost a synonym
>> makes more sense :-)
>>
>> "NON VI SED EMACS"
>
> I don't see how this would make more sense since "EMACS" could not
> possibly be ablative case in any Latin declension.

Sense is not the same as syntax.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emacs learning curve

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> "NON VI SED EMACS"

What do you have against sed?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs learning curve

[Juri Linkov]

>> "NON VI SED EMACS"
>
> What do you have against sed?

Sed is somewhere between Vi and Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emacs learning curve

[Andy Wingo]

On Sat 17 Jul 2010 14:15, Juri Linkov <juri@jurta.org> writes:

>> I used Vim for five years and then switched to Emacs
>> for its great extensions and extensibility.
>
> BTW, there is a famous Latin proverb "NON VI SED ARTE"
> that translates as "Not with force but with skill"
> or "Not by strength but by guile".

Your enthusiasm for Guile in Emacs is heartening, but we are still some
18 months from a viable branch.

:)
-- 
http://wingolog.org/

Re: Emacs learning curve

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Sat 17 Jul 2010 14:15, Juri Linkov <juri@jurta.org> writes:
>
>>> I used Vim for five years and then switched to Emacs
>>> for its great extensions and extensibility.
>>
>> BTW, there is a famous Latin proverb "NON VI SED ARTE"
>> that translates as "Not with force but with skill"
>> or "Not by strength but by guile".
>
> Your enthusiasm for Guile in Emacs is heartening, but we are still some
> 18 months from a viable branch.

Who cares about viable?  Emacsable is what we need.

-- 
David Kastrup

Re: Emacs learning curve

[Uday S Reddy]

On 7/17/2010 7:02 AM, Teemu Likonen wrote:

> Anyway, I'm not trying to change anybody's mind about the default key
> bindings. I have just been hoping that user could practically design her
> own global bindings but even that's not quite possible because the
> f-b-n-p mnemonics and other default keys are so deeply hard-coded
> everywhere. There's not enough abstraction on that front.

I think you are right.  I was thinking the same thing this morning.

In a supposedly configurable editor, it is pretty hard to change key bindings. 
  This seems like a deep flaw in the architecture of Emacs.  Perhaps this is 
what the emacs developers should focus on: make the key bindings configurable. 
  Then there would be no need to go through debates like this any more.

Cheers,
Uday

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-17 15:28 (+0100), Uday S. Reddy wrote:

> On 7/17/2010 7:02 AM, Teemu Likonen wrote:
>> Anyway, I'm not trying to change anybody's mind about the default key
>> bindings. I have just been hoping that user could practically design
>> her own global bindings but even that's not quite possible because
>> the f-b-n-p mnemonics and other default keys are so deeply hard-coded
>> everywhere. There's not enough abstraction on that front.
>
> I think you are right. I was thinking the same thing this morning.
>
> In a supposedly configurable editor, it is pretty hard to change key
> bindings. This seems like a deep flaw in the architecture of Emacs.
> Perhaps this is what the emacs developers should focus on: make the
> key bindings configurable. Then there would be no need to go through
> debates like this any more.

And to not sound too much like "Emacs developers should do this" I can
do some of the work myself.

In my opinion the cleanest way to create and experiment with different
global key bindings is to create global minor modes. Such modes are
clearly separate units from other parts of emacs and can be published in
places like the Emacs wiki. Currently the global minor mode approach
doesn't work very well because

  - modes use function substitute-key-definition which refer to the
    global-map directly. Key bindings in global minor modes won't be
    substituted.

  - modes overwrite global keys by hard-coding keys to commands.

If those both are changed to _command_ remapping, such as

    (define-key MAP [remap next-line] 'modes-custom-next-line)

then the minor mode approach would work and we would be quite far
already.

But do we agree that using substitute-key-definition with reference to
global-map is bad and should be replaced with command remapping (see
above)?

Re: Emacs learning curve

[Stephen J. Turnbull]

Teemu Likonen writes:
 > * 2010-07-17 15:28 (+0100), Uday S. Reddy wrote:

 > > In a supposedly configurable editor, it is pretty hard to change key
 > > bindings.

It's trivial to change key bindings.  M-x local-set-key RET
<keys-to-define> <command-name> RET and Bob's your uncle.  Or maybe
you want a swap-keys command that would have the UI M-x swap-keys RET
<keys1> <keys2>.  I don't have that function on the top of my head,
but I'm pretty sure it requires at most three lines to express.

What's hard to do is to do this in a way that maintains any
consistency.  That is the difference between Emacs and your average
editor designed for the below-average user: Emacs has a lot more
commands and real users with any amount of experience (often as little
as two or three months!) use enough of those bindings that they feel
pain upon remapping.  Of course many of the Emacs bindings are pretty
arbitrary (eg, P-N-U-D for previous-next-up-down would do just as well
as B-F-P-N for backward-forward-previous-next).  However, you need to
fix all of the related bindings for the different movement units.

 > places like the Emacs wiki. Currently the global minor mode approach
 > doesn't work very well because
 > 
 >   - modes use function substitute-key-definition which refer to the
 >     global-map directly. Key bindings in global minor modes won't be
 >     substituted.
 > 
 >   - modes overwrite global keys by hard-coding keys to commands.
 > 
 > If those both are changed to _command_ remapping, such as
 > 
 >     (define-key MAP [remap next-line] 'modes-custom-next-line)
 > 
 > then the minor mode approach would work and we would be quite far
 > already.
 > 
 > But do we agree that using substitute-key-definition with reference to
 > global-map is bad and should be replaced with command remapping (see
 > above)?

No.  I think you'll find that it's not used as frequently as you
think.  Many commands that *should* do slightly different things in
different modes already *do* do those things in the different modes,
by virtue of hooks in the commands.  If you rebind the command to a
different key, all the mode-dependent behavior goes with it.  I just
don't think this is the root of the problem.  And even if it is, I
think the right way to handle it is to make the command itself
configurable.

The problem is when modes bind completely different functions to the
keys.  If you decide to rearrange the mappings of core commands, users
of such mode will lose.  The mode programmer often has a rationale for
the key bindings chosen, such as mnemonic initials.

Re: Emacs learning curve

[Teemu Likonen]

* 2010-07-18 22:00 (+0900), Stephen J. Turnbull wrote:

> Teemu Likonen writes:
>> But do we agree that using substitute-key-definition with reference
>> to global-map is bad and should be replaced with command remapping
>> (see above)?
>
> No. I think you'll find that it's not used as frequently as you think.

I already did "M-x rgrep" on emacs.git/lisp directory before posting
anything about the function.

> Many commands that *should* do slightly different things in different
> modes already *do* do those things in the different modes, by virtue
> of hooks in the commands. If you rebind the command to a different
> key, all the mode-dependent behavior goes with it. I just don't think
> this is the root of the problem. And even if it is, I think the right
> way to handle it is to make the command itself configurable.
>
> The problem is when modes bind completely different functions to the
> keys. If you decide to rearrange the mappings of core commands, users
> of such mode will lose.

But

    (define-key MAP [remap next-line] 'new-next-line)

is great, though.

I dreamed that Emacs had such abstraction that user could redefine
global keyboard bindings and it would be nice and usable throughout the
system. In particular I was interested in only one user: me. But never
mind, it was naïve and I no longer have that dream. I realized that,
even though redefining individual keys is simple, some of the default
bindings still exist conceptually everywhere in different major modes.
I'm not that motivated to redesign modes too because that's what it
takes to maintain consistency. Heavy keyboard customization just isn't
practically possible.

So, I'll just continue to use the default keys with the knowledge that,
although they are not the most ergonomic and fast for text editing, at
least they are quite consistent throughout the Emacs system, even the
GNU system.

Now let's move on. What's the next purely academic discussion we should
have here on emacs-devel? :-)

Re: Emacs learning curve

[Stephen J. Turnbull]

Teemu Likonen writes:
 > * 2010-07-18 22:00 (+0900), Stephen J. Turnbull wrote:
 > 
 > > Teemu Likonen writes:
 > >> But do we agree that using substitute-key-definition with reference
 > >> to global-map is bad and should be replaced with command remapping
 > >> (see above)?
 > >
 > > No. I think you'll find that it's not used as frequently as you think.
 > 
 > I already did "M-x rgrep" on emacs.git/lisp directory before posting
 > anything about the function.

Of course you did.  I assumed that a grep would bring up dozens.

The point is, in these things, absolute counts don't matter.  If the
count is more than a dozen, the work will be script-driven.  What
matters is what fraction of variant keybindings are done with s-k-d,
compared to those done in other ways.  Ie, what fraction of "the
problem" can be solved by deciding "s-k-d is evil".

 > > The problem is when modes bind completely different functions to the
 > > keys. If you decide to rearrange the mappings of core commands, users
 > > of such mode will lose.
 > 
 > But
 > 
 >     (define-key MAP [remap next-line] 'new-next-line)
 > 
 > is great, though.

But what does it mean?  Have you got an implementation?  Remember, the
second argument to define-key is a key sequence.  I have no problem
with overloading the definition to allow "remappable commands" there,
but I have no clue as to what semantics you are proposing because
keymaps currently have no notion of "remappable commands as keys".
The semantics I have considered are of no help.  I just ended up with
more indirection, not more functionality.  Maybe you can do better,
though -- and that would be a substantial contribution.

Re: Emacs learning curve

[Kim F. Storm]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > But
>  > 
>  >     (define-key MAP [remap next-line] 'new-next-line)
>  > 
>  > is great, though.
>
> But what does it mean?  Have you got an implementation?  

Sure - I already implemented it years ago!

Please look for "command remapping" in the documentation.

>                                                          Remember, the
> second argument to define-key is a key sequence.  

It's a bug in the doc string for define-key that it doesn't mention the
[remap CMD] form for the key arg.

I would appreciate if somebody could fix that.

-- 
Kim F. Storm  http://www.cua.dk

Re: Emacs learning curve

[Tassilo Horn]

On Friday 16 July 2010 22:10:20 Teemu Likonen wrote:

Hi!

> Powerful text editor should depend on ergonomics and muscle memory and
> make rebinding keys easy (for different keyboard layouts like Dvorak).

I think this muscle memory statement is much overstated.  It's the main
argument why VI is better than emacs.  While I think it is true, that
the basic editing/searching/navigation commands should be easily
accessible (and I think they are in emacs), these ergonomics should
never take precedence over consistency and the ease to remember them
(which mnemonics facilitate).

I use quite a few emacs modes on only a weekly or monthly basis.  If the
keys of these modes wouldn't be based on mnemonics but ergonomic
positions on a QUERTY keyboard, I'd have a hard time using them and `C-h
w' would be the most frequently used command.  A power-user of these
modes has the possibility to rebind the important commands to shorted
keys, so she can get them as ergonomic (for her layout) as she feels the
need to.  Defaults are a different story.

And, no matter what I do in emacs, being it programming, writing texts,
reading/writing news, or doing spreadsheet calculations, I spend far
more time thinking than issuing editing commands.  And from the editing
command fraction, 99% are self-insert-command which I chose my keyboard
layout for and thus they are ergonomic (for me).  Even if the "real"
editing command bindings would be changed so that I can type them 10
times faster, that wouldn't buy me more than a some tenth of a percent
of time I would need to write that program/text/spreadsheet with the
current bindings.  Most probably, it would rather take me longer, cause
the missing mnemonics made me forget some keys and I'd have to look them
up again.

Bye,
Tassilo

Re: Emacs learning curve

[Lennart Borgman]

2010/7/17 Tassilo Horn <tassilo@member.fsf.org>:
> On Friday 16 July 2010 22:10:20 Teemu Likonen wrote:
>
> Hi!
>
>> Powerful text editor should depend on ergonomics and muscle memory and
>> make rebinding keys easy (for different keyboard layouts like Dvorak).
>
> I think this muscle memory statement is much overstated.


It would be interesting if anyone has some psychological research to
support this.

I do not believe that is is overstated (but I do not have time to look
it now). Rather I think that for simple and often used commands (like
CUA) it is very important.

I also suspect that natural language skills might be involved. That
would perhaps mean that for some people (maybe mostly those lucky
enough growing up with two languages or more) changing between Emacs
key bindings and other key bindings might be easy, but for others
difficult.

But to be sure unbiased observations must be made, of course.

Re: Emacs learning curve

[Tassilo Horn]

On Thursday 22 July 2010 14:15:51 Lennart Borgman wrote:

> > I think this muscle memory statement is much overstated.
> 
> It would be interesting if anyone has some psychological research to
> support this.

No, but at least it's true for me.  There's some mode that records key /
command frequencies.  Use it for a while and see how tiny the command
fraction is compared to `self-insert-command'.  Then add some time for
thinking before writing to the calculation, and you'll see that the time
needed for typing command key bindings is totally out of relevance.

> I do not believe that is is overstated (but I do not have time to look
> it now). Rather I think that for simple and often used commands (like
> CUA) it is very important.

Yeah, the most frequently used commands should be quick and easy.  And
that's true for the normal emacs bindings for those commands.

But most modern editors waste short bindings also for commands that you
need nearly never, like C-p for printing, C-s for saving, ...

I think that has a purely technical reason: keychords consisting of
multiple keys pressed one after the other were/are seldomly supported.
Some years later, these short but wasteful bindings are standard, and
now people try to conquer the last bastillion of good bindings...

Bye,
Tassilo

Re: Emacs learning curve

[Ivan Andrus]

Oops, I had meant to send the original to the list.

On Jul 23, 2010, at 8:57 AM, Tassilo Horn wrote:

> On Thursday 22 July 2010 22:33:16 Ivan Andrus wrote:
> 
>>> No, but at least it's true for me.  There's some mode that records
>>> key / command frequencies.  Use it for a while and see how tiny the
>>> command fraction is compared to `self-insert-command'.  Then add
>>> some time for thinking before writing to the calculation, and you'll
>>> see that the time needed for typing command key bindings is totally
>>> out of relevance.
> 
> I have to admit that this suggestion was made out of a gut-feeling.  So
> now, I got and enabled command-frequency.el, too.  Currently, here're
> the results of my first 5 minutes (only reading mail/news and replying
> to you):
> 
>    241   45.99%  self-insert-command
>    116   22.14%  gnus-summary-scroll-up
>     36    6.87%  next-line
>     22    4.20%  delete-backward-char
>     20    3.82%  kill-line
>     16    3.05%  gnus-summary-catchup-and-exit
>     16    3.05%  gnus-topic-select-group
>     11    2.10%  previous-line
>      6    1.15%  minibuffer-complete
> ...
> 
>> I must say that I was shocked myself when I looked at it.  I thought
>> self-insert-command would be 50-60% for me, but apparently I do even
>> less typing than I thought (though my usage recently has been a bit
>> that way):
>> 
>>   7651   21.06%  self-insert-command
>>   4475   12.31%  next-line
>>   2756    7.58%  previous-line
>>   1124    3.09%  org-self-insert-command
>> ...
>> 
>> I wonder what others see.
> 
> I think it could be a benefit to revamp this package so that it sends
> statistics to some server.  In addition, it should record how a command
> was executed (M-x, or with <key>) and in which minor/major mode.  That
> would allow spotting frequently used commands with non-ergonomic
> bindings.

I completely agree.

> At least the tops of our statistics are all accessible with one key
> (with or without modifier).

Indeed.  And I think that's the most important thing.  Of course we might use them more _because_ they have simple key bindings.

-Ivan

Re: Emacs learning curve

[Tassilo Horn]

On Friday 16 July 2010 19:38:46 Óscar Fuentes wrote:

> > This heavily depends on your keyboard layout.
> 
> Yes, I'm using a very expensive keyboard just because it has a great
> ergonomics for working with Emacs.

The price and quality of the keyboard doesn't make a big difference
compared to the choice of layout, e.g. QUERTY, Dvorak or Neo.  And I
think it's a bad idea to choose keybindings so that they are convenient
or logical for one single layout.  That's the reason for avoiding hjkl
movement.  Mnemonics are platform/layout independent.

> > Similarly, C-k, C-y and M-y have clear mnemonics derived from the
> > concepts of killing and yanking.
> 
> Worrying about mnemonics for operations you do hundreds of times per
> day is a waste.

Not really, but bindings for frequently used commands should be short.
And C-w, M-w, C-y, M-y are as short as the CUA bindings.  And because
they have clear mnemonics, they should be easily perceptible by newbies,
too, once they have learned the concepts behind killing and yanking.

With CUA (which I have currently switched on for testing) the bindings
have no mnemonics anymore, and they are still not what I would expect
from a "normal" editor.  For example, C-a normally selects the complete
contents of a buffer, but in emacs even with CUA it moves point to the
beginning of a line.  Since that's a much more important operation than
selecting all contents, I guess that's ok.  But nevertheless, it doesn't
match a non-emacs user's expectation.

And there are many other bindings in common editors which are short but
rarely used, like C-s for saving (goodbye isearch), C-p for printing
(goodbye movement), and many more.  If we would try to match newbies
expectations, we would sacrifice so many short bindings that emacs
wouldn't be as effective as it is right now.

The standard keybindings in today's editors are the ones they are now
mostly because nearly none of them support keychords.

Bye,
Tassilo

Re: Emacs learning curve

[Óscar Fuentes]

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Friday 16 July 2010 19:38:46 Óscar Fuentes wrote:
>
>> > This heavily depends on your keyboard layout.
>> 
>> Yes, I'm using a very expensive keyboard just because it has a great
>> ergonomics for working with Emacs.
>
> The price and quality of the keyboard doesn't make a big difference
> compared to the choice of layout, e.g. QUERTY, Dvorak or Neo.

Of course, if you rearrange the keys on the keyboard any bindings can be
awkward. But if you see that that justifies leaving ergonomics aside and
hence focusing on what is left (mnemonics) IMHO you are wrong. The
keyboard I use has an English layout, although I have to write in
Spanish (which has accented chars, special characters, etc) If your
native keyboard layout hurts when used with Emacs, change the
keyboard. It is a health issue.

(What I appreciate most of my keyboard is that Ctrl and Alt can be
pressed with the thumbs)

>> Worrying about mnemonics for operations you do hundreds of times per
>> day is a waste.
>
> Not really, but bindings for frequently used commands should be short.
> And C-w, M-w, C-y, M-y are as short as the CUA bindings.  And because
> they have clear mnemonics, they should be easily perceptible by newbies,
> too, once they have learned the concepts behind killing and yanking.

Again, mnemonics is a petty issue. Muscle memory is the ruling factor.

[snip]

Re: Emacs learning curve

[David Kastrup]

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

> Tassilo Horn <tassilo@member.fsf.org> writes:

>> Not really, but bindings for frequently used commands should be short.
>> And C-w, M-w, C-y, M-y are as short as the CUA bindings.  And because
>> they have clear mnemonics, they should be easily perceptible by newbies,
>> too, once they have learned the concepts behind killing and yanking.
>
> Again, mnemonics is a petty issue. Muscle memory is the ruling factor.

For vi.  Editing with Emacs is slower and involves more brain.  The
possibilities of Emacs fold out too large for muscle memory.

-- 
David Kastrup

Re: Emacs learning curve

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>> Again, mnemonics is a petty issue. Muscle memory is the ruling factor.
>
> For vi.  Editing with Emacs is slower and involves more brain.

I don't know for you, but for me C-w C-d C-k C-n and others are driven
by my reptilian brain. On this aspect I see no difference with vi

> The possibilities of Emacs fold out too large for muscle memory.

Sure, that's because discoverability is one of the things that Emacs
shall improve.

Re: Emacs learning curve

[Jan Djärv]

2010-07-16 19:27, Tassilo Horn skrev:

> This heavily depends on your keyboard layout.  IMO, the worst decision a
> developer of an editor can make is to base the keybindings on one
> specific layout.  For example, vi's hjkl-movement bindings are totally
> awkward on my German Dvorak Type II keyboard.  In contrast, emacs C-n,
> C-f, C-b and C-p have mnemonics which are clear and independent from the
> layout.
>
> Similarly, C-k, C-y and M-y have clear mnemonics derived from the
> concepts of killing and yanking.
>

CUA is terrible in this regard.  C-x, C-c and C-v are all next to each other. 
  I often do C-c when C-v was inteded...

	Jan D.

Re: Emacs learning curve

[Alfred M. Szmidt]

   > Can we please stop with the extravagant claim that new users are
   > not attracted to emacs because of some idiosyncratic bindings?

   That claim is extravagant indeed. The users are not attracted by
   the idiosyncratic keybindings, they are *repelled* by them.

Again, simply not true, please stop.  _Your_ experience might dictate
things that are different frommine, but claiming that users are
"repelled' is simply not true since new users use emacs.

   > One should strive for what is sensible and logical, not what is
   > currently modern and popular.  The reason people are attached to
   > "the old way" is because it makes sense, and it has proven itself
   > over 30 years.

   If there is something in Emacs that is not sensible nor logical, that's
   the keybindings. Not only they are different from the current
   established ones, they often seem planned with the clear intention
   of causing RSI :-)

They make sense in the context of emacs; they are menomics for
functions.  That is sensible and logical, none of your claims are
strong since you disregard those facts.

Re: Emacs learning curve

[Óscar Fuentes]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > Can we please stop with the extravagant claim that new users are
>    > not attracted to emacs because of some idiosyncratic bindings?
>
>    That claim is extravagant indeed. The users are not attracted by
>    the idiosyncratic keybindings, they are *repelled* by them.
>
> Again, simply not true, please stop.  _Your_ experience might dictate
> things that are different frommine, but claiming that users are
> "repelled' is simply not true since new users use emacs.

So as far as some new users come from time to time, there is no need to
question Emacs' design. Curious logic. We'll better leave the discussion
here.

[snip]

Re: Emacs learning curve

[Alfred M. Szmidt]

   "Alfred M. Szmidt" <ams@gnu.org> writes:

   >    > Can we please stop with the extravagant claim that new users are
   >    > not attracted to emacs because of some idiosyncratic bindings?
   >
   >    That claim is extravagant indeed. The users are not attracted by
   >    the idiosyncratic keybindings, they are *repelled* by them.
   >
   > Again, simply not true, please stop.  _Your_ experience might dictate
   > things that are different frommine, but claiming that users are
   > "repelled' is simply not true since new users use emacs.

   So as far as some new users come from time to time, there is no need to
   question Emacs' design. Curious logic. We'll better leave the discussion
   here.

If the argument is that users are "repelled" from emacs because of the
current bindings, and it is shown that this is simply not true, then
yes, one should kill the discussion on that specific point.  

People are making absurd claims, and refuse to listen and it is
getting tiresome.

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 7:52 PM, Alfred M. Szmidt <ams@gnu.org> wrote:
>   > Can we please stop with the extravagant claim that new users are
>   > not attracted to emacs because of some idiosyncratic bindings?
>
>   That claim is extravagant indeed. The users are not attracted by
>   the idiosyncratic keybindings, they are *repelled* by them.
>
> Again, simply not true, please stop.  _Your_ experience might dictate
> things that are different frommine, but claiming that users are
> "repelled' is simply not true since new users use emacs.


Of course "repelled" and "attracted" should be thought of as forces.

So the claim that users are "repelled" by the keybindings can (and
probably IMO are) true even if new users use emacs.

Re: Emacs learning curve

[Stefan Monnier]

> By keeping Emacs decidely different from other, more popular UIs
> you keep most of new users out and consequently competent
> contributors as well.

While this may very well be true, I think this is unavoidable.
Changing the UI of Emacs is very difficult, because this UI has been
with us for 25 years and is embedded in pretty much every package out
there (bundled and not bundled), so changing it without making Emacs
even more of an inconsistent mess than it already is (and hence without
alienating all its current users) is nigh on impossible.

I would welcome attempts to do it, of course.  But I won't hold
my breath.  BTW, while as a user you may notice those UI problems quite
easily, as a developer you'd notice plenty of comparable problems in
Elisp's design, and for very similar reasons they can't get fixed.

IOW fixing Emacs requires rewriting it from scratch, throwing away
backward compatibility.


        Stefan

Re: Emacs learning curve

[Uday S Reddy]

On 7/14/2010 11:31 AM, Tom wrote:

> That's why CUA-style editing should be made the consistent default, so Emacs
> works like all other modern application on KDE/Gnome/Windows, etc. and the
> current behavior should be provided as a compatibility mode for those who
> are accustomed to the old behavior.

Instead of asking for the defaults to be changed, why can't you, or anybody 
else that is interested, create configuration files, called KDE-Emacs or 
Windows-Emacs or whatever, which fit into such environments?  The Mac-uses seem 
to be doing it with Aquamacs etc.

(We had a big row about line-move-visual, not because it was a question of 
defaults, but because the default setting changed the meaning of next-line, 
which broke or potentially broke various applications running on Emacs. 
Stefan's defence that the Emacs 23 compiler flagged the problem was completely 
satisfactory.)

Emacs is configurable, free software, which can be tweaked by everybody.  There 
is no need to react to it as if it were some proprietary, commercial software 
where you are dependent on the gods to do everything.

Cheers,
Uday

Re: Emacs learning curve

[Ivan Kanis]

Tom <levelhalom@gmail.com> wrote:

> Advanced users should have no problem adding a single line to their
> .emacs to switch on the compatibility mode
> e.g. (enable-classic-bindings) and new users would enjoy the familiar
> CUA-style bindings out of the box.

I side with Tom, I wouldn't mind adding one line to my .emacs in favor
of easing new users experience.

My 2cents,
-- 
Ivan Kanis
http://kanis.fr

We make a living by what we get, we make a life by what we give.
    -- Winston Churchill 

Re: Emacs learning curve

[Miles Bader]

Ivan Kanis <expire-by-2010-07-21@kanis.fr> writes:
> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
> of easing new users experience.

It isn't that simple.  You can't just move some bindings around without
affecting other bindings, and there are _lots of bindings_ in Emacs,
which are not all defined in one place, or even in one code-base.

If Emacs were a simple minimal-functionality editor like notepad with
all its bindings defined in a single list, maybe you could easily offer
alternative binding sets -- but it isn't.

You can see the problem in the existing cua-mode:  even though it only
tries to offer a very few CUA bindings, it has to resort to awful dodgy
hacks to do so, to avoid (or at least try to avoid) stepping on other
bindings.

-Miles

-- 
Omochiroi!

Re: Emacs learning curve

[Ivan Kanis]

Miles Bader <miles@gnu.org> wrote:

> Ivan Kanis <expire-by-2010-07-21@kanis.fr> writes:
>> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>> of easing new users experience.
>
> It isn't that simple.  You can't just move some bindings around without
> affecting other bindings, and there are _lots of bindings_ in Emacs,
> which are not all defined in one place, or even in one code-base.

I didn't say it was simple.

> You can see the problem in the existing cua-mode:  even though it only
> tries to offer a very few CUA bindings, it has to resort to awful dodgy
> hacks to do so, to avoid (or at least try to avoid) stepping on other
> bindings.

I took a look at CUA mode and it think it is dealing with the problem
elegantly. It supports C-x and C-c only if there is a transient mark.
C-z, C-v do what the user expects.

I think turning on CUA mode by default would help first time users. If
there's a one line of lisp to turn it off and have the old behavior I
don't mind. I don't think veteran emacs user would mind either.

I agree Tom with the concern that new users are turned off with weird
key binding.

An so that's my bit to the bike shed.

> Omochiroi!

BTW if it's Japanese it's spelled omoshiroi.

Take care,
-- 
Ivan Kanis
http://kanis.fr

It's not what we have in our life, but who we have in our life,
that counts.
    -- J.M. Laurence

Re: Emacs learning curve

[Chong Yidong]

Ivan Kanis <expire-by-2010-07-22@kanis.fr> writes:

> I think turning on CUA mode by default would help first time users. If
> there's a one line of lisp to turn it off and have the old behavior I
> don't mind. I don't think veteran emacs user would mind either.

No, having CUA mode on by default is off the table.

This proposal has been discussed before, and there are many problems
with it.  For instance, by default, C-c LETTER is reserved for user
customizations; CUA prevents such key bindings when the region is
active.

Let's not revisit this discussion.  It is not difficult to turn on CUA
mode, for those who want it; it's even in the Options menu.

Re: Emacs learning curve

[Lennart Borgman]

On Sat, Jul 17, 2010 at 7:51 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Ivan Kanis <expire-by-2010-07-22@kanis.fr> writes:
>
>> I think turning on CUA mode by default would help first time users. If
>> there's a one line of lisp to turn it off and have the old behavior I
>> don't mind. I don't think veteran emacs user would mind either.
>
> No, having CUA mode on by default is off the table.
>
> This proposal has been discussed before, and there are many problems
> with it.  For instance, by default, C-c LETTER is reserved for user
> customizations; CUA prevents such key bindings when the region is
> active.

Is not this a reason for making CUA mode default? As long as it is not
the default it will be a second class citizen and obstacles like this
will remains. And those makes it quite a bit harder for new users.

> Let's not revisit this discussion.  It is not difficult to turn on CUA
> mode, for those who want it; it's even in the Options menu.

That is not the problem.

Re: Emacs learning curve

[Tassilo Horn]

On Thursday 22 July 2010 13:36:42 Lennart Borgman wrote:

> > No, having CUA mode on by default is off the table.
> >
> > This proposal has been discussed before, and there are many problems
> > with it.  For instance, by default, C-c LETTER is reserved for user
> > customizations; CUA prevents such key bindings when the region is
> > active.
> 
> Is not this a reason for making CUA mode default? As long as it is not
> the default it will be a second class citizen and obstacles like this
> will remains. And those makes it quite a bit harder for new users.

So you mean making CUA the default would force us to change the binding
reserved for users.  I guess user's would be very happy to revamp their
key bindings.

And we would need to define new guidelines for modes.  These
recommendations are also in conflict with CUA:

,----[ (info "(elisp)Major Mode Conventions") ]
|    * The key sequences bound in a major mode keymap should usually
|      start with `C-c', followed by a control character, a digit, or `{',
|      `}', `<', `>', `:' or `;'.  The other punctuation characters are
|      reserved for minor modes, and ordinary letters are reserved for
|      users.
`----

,----[ (info "(elisp)Keymaps and Minor Modes") ]
|    The key sequences bound in a minor mode should consist of `C-c'
| followed by one of `.,/?`'"[]\|~!#$%^&*()-_+='.  (The other punctuation
| characters are reserved for major modes.)
`----

But since old emacs users and users happy with the emacs way would like
to stick to the default bindings, we would have to somehow invend
conventions that fit for both Emacs and CUAmacs.  I'm pretty sure that's
near to impossible if you want to preserve a rest of mnemonics and
consistency.

Bye,
Tassilo

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 2:14 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> On Thursday 22 July 2010 13:36:42 Lennart Borgman wrote:
>
>> > No, having CUA mode on by default is off the table.
>> >
>> > This proposal has been discussed before, and there are many problems
>> > with it.  For instance, by default, C-c LETTER is reserved for user
>> > customizations; CUA prevents such key bindings when the region is
>> > active.
>>
>> Is not this a reason for making CUA mode default? As long as it is not
>> the default it will be a second class citizen and obstacles like this
>> will remains. And those makes it quite a bit harder for new users.
>
> So you mean making CUA the default would force us to change the binding
> reserved for users.  I guess user's would be very happy to revamp their
> key bindings.
>
> And we would need to define new guidelines for modes.  These
> recommendations are also in conflict with CUA:
>
> ,----[ (info "(elisp)Major Mode Conventions") ]
> |    * The key sequences bound in a major mode keymap should usually
> |      start with `C-c', followed by a control character, a digit, or `{',
> |      `}', `<', `>', `:' or `;'.  The other punctuation characters are
> |      reserved for minor modes, and ordinary letters are reserved for
> |      users.
> `----
>
> ,----[ (info "(elisp)Keymaps and Minor Modes") ]
> |    The key sequences bound in a minor mode should consist of `C-c'
> | followed by one of `.,/?`'"[]\|~!#$%^&*()-_+='.  (The other punctuation
> | characters are reserved for major modes.)
> `----
>
> But since old emacs users and users happy with the emacs way would like
> to stick to the default bindings, we would have to somehow invend
> conventions that fit for both Emacs and CUAmacs.  I'm pretty sure that's
> near to impossible if you want to preserve a rest of mnemonics and
> consistency.


Aren't your description rather accurate also without making CUA mode
default? (Except for swapping new and old users?)

This is what I mean with that CUA mode currently is a second citizen.

Re: Emacs learning curve

[Tassilo Horn]

On Thursday 22 July 2010 14:18:40 Lennart Borgman wrote:

> > And we would need to define new guidelines for modes.  These
> > recommendations are also in conflict with CUA:
> >
> > ,----[ (info "(elisp)Major Mode Conventions") ]
> > |    * The key sequences bound in a major mode keymap should usually
> > |      start with `C-c', followed by a control character, a digit, or `{',
> > |      `}', `<', `>', `:' or `;'.  The other punctuation characters are
> > |      reserved for minor modes, and ordinary letters are reserved for
> > |      users.
> > `----
> >
> > ,----[ (info "(elisp)Keymaps and Minor Modes") ]
> > |    The key sequences bound in a minor mode should consist of `C-c'
> > | followed by one of `.,/?`'"[]\|~!#$%^&*()-_+='.  (The other punctuation
> > | characters are reserved for major modes.)
> > `----
> >
> > But since old emacs users and users happy with the emacs way would
> > like to stick to the default bindings, we would have to somehow
> > invend conventions that fit for both Emacs and CUAmacs.  I'm pretty
> > sure that's near to impossible if you want to preserve a rest of
> > mnemonics and consistency.
> 
> Aren't your description rather accurate also without making CUA mode
> default?

No.  New users don't have configs they need to change, and existing
modes already stick to these (non-CUA-friendly) conventions.

> (Except for swapping new and old users?)

I wanted to say, that making CUA default would involve replacing binding
conventions and changing gazillions of bindings accordingly.

> This is what I mean with that CUA mode currently is a second citizen.

Well, that's true.  But IMO it's impossible to have two first class
keybinding schemes.

Bye,
Tassilo

Re: Emacs learning curve

[Ivan Kanis]

Tassilo Horn <tassilo@member.fsf.org> wrote:

> And we would need to define new guidelines for modes.  These
> recommendations are also in conflict with CUA:

... snip stuff about C-c ..

> But since old emacs users and users happy with the emacs way would like
> to stick to the default bindings, we would have to somehow invend
> conventions that fit for both Emacs and CUAmacs.  I'm pretty sure that's
> near to impossible if you want to preserve a rest of mnemonics and
> consistency.

C-c is addressed in CUA mode, it only does copy if transient mode is
on. You can still get C-c in transient by pressing C-c twice. It's
technically possible for emacs to have sane key binding, it's just
political not do so.

On a somewhat related note emacs added long line visual motion. It was
turned on by default possibly creating confusion for veteran users. The
same old user can quickly find that setting line-move-visual to nil gets
her the old behavior.

Why can't we do that for CUA mode? I think that politics get in the way.

Have a nice day,
-- 
Ivan Kanis
http://kanis.fr

Seriousness is the only refuge of the shallow.
    -- Oscar Wilde 

Re: Emacs learning curve

[David Kastrup]

Ivan Kanis <expire-by-2010-07-27@kanis.fr> writes:

> Tassilo Horn <tassilo@member.fsf.org> wrote:
>
>> And we would need to define new guidelines for modes.  These
>> recommendations are also in conflict with CUA:
>
> ... snip stuff about C-c ..
>
>> But since old emacs users and users happy with the emacs way would like
>> to stick to the default bindings, we would have to somehow invend
>> conventions that fit for both Emacs and CUAmacs.  I'm pretty sure that's
>> near to impossible if you want to preserve a rest of mnemonics and
>> consistency.
>
> C-c is addressed in CUA mode, it only does copy if transient mode is
> on. You can still get C-c in transient by pressing C-c twice.

Within a fifth of a second.

> It's technically possible for emacs to have sane key binding, it's
> just political not do so.

I refuse to call that sort of timing-based key sequence difference
"sane".  For example, it makes bug reports containing key lossage
useless since the key lossage fails to mention the delays between key
presses.

> On a somewhat related note emacs added long line visual motion. It was
> turned on by default possibly creating confusion for veteran
> users. The same old user can quickly find that setting
> line-move-visual to nil gets her the old behavior.
>
> Why can't we do that for CUA mode? I think that politics get in the
> way.

The result is not sane and not consistent.  If you call it "politics"
not to present insane and inconsistent behavior to new users, you may be
right.  And any politician being serious about this sort of politics can
count on my vote.

We discussed this.  We voted on it.  Again and again.  And again and
again.  And you'll still find the vocal minority ignore reality and
claim that they are suffering from unreasonable hardships by not getting
their whim against the majority, against common sense, against
consistency, against the arguments they keep discarding, and without
cleaning up their act first.

-- 
David Kastrup

Re: Emacs learning curve

[Wojciech Meyer]

Yes. Cua mode is not a solution. The solution would be a minor mode
that preserves CUA keys but disables *completely* emacs ones. The mode
should be easy to toggle and there need to be evident feedback when it
is on, a screen nagging about advanced features avaiable when you
switch the mode on. One will have chance to learn new bindigs
gradually. Wojciech

On 7/22/10, David Kastrup <dak@gnu.org> wrote:
> Ivan Kanis <expire-by-2010-07-27@kanis.fr> writes:
>
>> Tassilo Horn <tassilo@member.fsf.org> wrote:
>>
>>> And we would need to define new guidelines for modes.  These
>>> recommendations are also in conflict with CUA:
>>
>> ... snip stuff about C-c ..
>>
>>> But since old emacs users and users happy with the emacs way would like
>>> to stick to the default bindings, we would have to somehow invend
>>> conventions that fit for both Emacs and CUAmacs.  I'm pretty sure that's
>>> near to impossible if you want to preserve a rest of mnemonics and
>>> consistency.
>>
>> C-c is addressed in CUA mode, it only does copy if transient mode is
>> on. You can still get C-c in transient by pressing C-c twice.
>
> Within a fifth of a second.
>
>> It's technically possible for emacs to have sane key binding, it's
>> just political not do so.
>
> I refuse to call that sort of timing-based key sequence difference
> "sane".  For example, it makes bug reports containing key lossage
> useless since the key lossage fails to mention the delays between key
> presses.
>
>> On a somewhat related note emacs added long line visual motion. It was
>> turned on by default possibly creating confusion for veteran
>> users. The same old user can quickly find that setting
>> line-move-visual to nil gets her the old behavior.
>>
>> Why can't we do that for CUA mode? I think that politics get in the
>> way.
>
> The result is not sane and not consistent.  If you call it "politics"
> not to present insane and inconsistent behavior to new users, you may be
> right.  And any politician being serious about this sort of politics can
> count on my vote.
>
> We discussed this.  We voted on it.  Again and again.  And again and
> again.  And you'll still find the vocal minority ignore reality and
> claim that they are suffering from unreasonable hardships by not getting
> their whim against the majority, against common sense, against
> consistency, against the arguments they keep discarding, and without
> cleaning up their act first.
>
> --
> David Kastrup
>
>
>

-- 
Sent from my mobile device

Re: Emacs learning curve

[Stephen Eilert]

On Thu, Jul 22, 2010 at 4:56 PM, Wojciech Meyer
<wojciech.meyer@googlemail.com> wrote:
> Yes. Cua mode is not a solution. The solution would be a minor mode
> that preserves CUA keys but disables *completely* emacs ones. The mode
> should be easy to toggle and there need to be evident feedback when it
> is on, a screen nagging about advanced features avaiable when you
> switch the mode on. One will have chance to learn new bindigs
> gradually. Wojciech

I'd argue the other way. CUA is not the problem.

There are a few things worth noticing:

1-Emacs discoverability
  It is quite good, once you know how and what to look for.
describe-key, describe-mode, describe-function and apropos are
invaluable. Only beginners won't know how to do such things unless
explicitely told

2- Learning curve
  Pointless. I've been using it for years and I'm still learning. It
would be best to ask: 'what is the minimum skillset to be moderately
productive in everyday text editing?' I can't really answer that, yet.
But I suspect you need very few commands for that.

3- Appearance
  Greatly improved by default on gnome ever since XFT was included. An
ugly editor will put off many people. People tend to equate shiny =
good, even technically informed ones. That's unfortunate, but
unavoidable.
  I'd say Emacs is doing fine. Color-theme should be included by
default and easily accessible IMHO. The only odd thing is really the
modeline but, while it can be intimidating, it is also intriguing.

4- Defaults
  Here's where CUA comes in. Users expect the usual copy and paste
behavior (including the ability to copy and paste among application)
and *will* get completely confused by Emacs' kill-ring. The kill-ring
is nice, but it is not straightforward to explain without visual
feedback.
  Ditto for undo: I myself was confused by it for quite a while.
  My toolbars and menubars are turned off, but I'd say that they need
some cleaning up. After all, menus are where most users will 'hunt'
for features.


--Stephen

Sent from my Emacs

Re: Emacs learning curve

[David Kastrup]

Stephen Eilert <spedrosa@gmail.com> writes:

> 4- Defaults
>   Here's where CUA comes in. Users expect the usual copy and paste
> behavior (including the ability to copy and paste among application)
> and *will* get completely confused by Emacs' kill-ring. The kill-ring
> is nice, but it is not straightforward to explain without visual
> feedback.

If people supposedly get confused by the behavior of yank and kill as
opposed to copy&paste, I doubt that we'd be doing them a great service
by calling them "copy&paste" and putting them on copy&paste keybindings.

-- 
David Kastrup

Re: Emacs learning curve

[Fren Zeee]

On Thu, Jul 22, 2010 at 11:08 PM, David Kastrup <dak@gnu.org> wrote:
> Stephen Eilert <spedrosa@gmail.com> writes:
>
>> 4- Defaults
>>   Here's where CUA comes in. Users expect the usual copy and paste
>> behavior (including the ability to copy and paste among application)
>> and *will* get completely confused by Emacs' kill-ring. The kill-ring
>> is nice, but it is not straightforward to explain without visual
>> feedback.
>
> If people supposedly get confused by the behavior of yank and kill as
> opposed to copy&paste, I doubt that we'd be doing them a great service
> by calling them "copy&paste" and putting them on copy&paste keybindings.
>
A method must be devised that allows aliases type system so that those
who are using the older system dont have a problem and those who want
the microsoft type C-C and C-V can go there.

Basically, its like two nearest keys, V has no mnemonic relation to Paste.

Franz

Re: Emacs learning curve

[Dirk-Jan C. Binnema]

>>>>> On Thu, 22 Jul 2010 18:58:10 -0300, Stephen Eilert ("SE") wrote:

  SE> On Thu, Jul 22, 2010 at 4:56 PM, Wojciech Meyer
  SE> <wojciech.meyer@googlemail.com> wrote:
  >> Yes. Cua mode is not a solution. The solution would be a minor mode
  >> that preserves CUA keys but disables *completely* emacs ones. The mode
  >> should be easy to toggle and there need to be evident feedback when it
  >> is on, a screen nagging about advanced features avaiable when you
  >> switch the mode on. One will have chance to learn new bindigs
  >> gradually. Wojciech

  SE> I'd argue the other way. CUA is not the problem.

  SE> There are a few things worth noticing:

  SE> 1-Emacs discoverability
  SE>   It is quite good, once you know how and what to look for.
  SE> describe-key, describe-mode, describe-function and apropos are
  SE> invaluable. Only beginners won't know how to do such things unless
  SE> explicitely told

Well put - one of the issues with a lot of the documentation is that it
reflects the way emacs works, rather than how to solve a certain task.

Another way many users discover tasks is through the menus -- and the menus
could be rationalized a bit, without (hopefully) alienating too many long-time
users, as they (I assume) do not use the menus much anyhow (or would have
complained that the *menu* actually uses cut/copy/paste for
kill/kill-ring-save/yank)

There's a lot of improvements possible there -- which has been discussed
elsewhere. E.g., only one calculator (probably the simple one) would suffice
in 'Options'. And why are there games under 'Tools', etc. etc.


  SE> 2- Learning curve
  SE>   Pointless. I've been using it for years and I'm still learning. It
  SE> would be best to ask: 'what is the minimum skillset to be moderately
  SE> productive in everyday text editing?' I can't really answer that, yet.
  SE> But I suspect you need very few commands for that.

Well, there's learning curve to be up to Notepad-level (which already brings
some obstacles that should probably not really scare the target audience), to
getting up to, say, Eclipse/IDE level - having tagging set up,
auto-completion, maybe some snippets system, SCM -- that's quite a bit harder
with emacs than it is with other editors.

Of course, emacs brings infinitely more (which I am using it), but it wouldn't
hurt to make what many would call 'basics' easier -- i.e.., can a new emacs
user have such features working in a few hours, and if not, how could we make
that easier.

  SE> 3- Appearance
  SE>   Greatly improved by default on gnome ever since XFT was included. An
  SE> ugly editor will put off many people. People tend to equate shiny =
  SE> good, even technically informed ones. That's unfortunate, but
  SE> unavoidable.

True. There are some issues still -- it'd be nice to have toolkit-combo boxes
for auto-completion, toolkit-tabs, a bit shinier mode-line etc.; but IMHO
those are less important. They'll get there, eventually.

  SE>   I'd say Emacs is doing fine. Color-theme should be included by
  SE> default and easily accessible IMHO. The only odd thing is really the
  SE> modeline but, while it can be intimidating, it is also intriguing.

I have some doubts about the implementation of 'color-themes', but something
like that would be nice. Note that color-themes don't seem to be a very
important feature for other editors.
  
  SE> 4- Defaults
  SE>   Here's where CUA comes in. Users expect the usual copy and paste
  SE> behavior (including the ability to copy and paste among application)
  SE> and *will* get completely confused by Emacs' kill-ring. The kill-ring
  SE> is nice, but it is not straightforward to explain without visual
  SE> feedback.
  SE>   Ditto for undo: I myself was confused by it for quite a while.
  SE>   My toolbars and menubars are turned off, but I'd say that they need
  SE> some cleaning up. After all, menus are where most users will 'hunt'
  SE> for features.

Yes -- I am not sure defaults are *so* important; the emacs target group
should be able to add one line (mimic-other-editors-mode 1) to their .emacs,
because if that's too hard, probably emacs is not really the right editor for
this person. And we could even put it in some kind of first-use wizard
thing. The details of what should be in this mode are bit harder to determine
though...

Also, I think there are more vi/vim-users than emacs users -- and vi/vim has a
/much/ weirder mode of operation than emacs -- 'being like the others' is
maybe not be the most important thing of all.

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: Emacs learning curve

[Alfred M. Szmidt]

   > It's technically possible for emacs to have sane key binding, it's
   > just political not do so.

   I refuse to call that sort of timing-based key sequence difference
   "sane".  For example, it makes bug reports containing key lossage
   useless since the key lossage fails to mention the delays between key
   presses.

Makes using the minibuffer to look at what you pressed useless too...

Re: Emacs learning curve

[David Kastrup]

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

> On Sat, Jul 17, 2010 at 7:51 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>> Ivan Kanis <expire-by-2010-07-22@kanis.fr> writes:
>>
>>> I think turning on CUA mode by default would help first time users. If
>>> there's a one line of lisp to turn it off and have the old behavior I
>>> don't mind. I don't think veteran emacs user would mind either.
>>
>> No, having CUA mode on by default is off the table.
>>
>> This proposal has been discussed before, and there are many problems
>> with it.  For instance, by default, C-c LETTER is reserved for user
>> customizations; CUA prevents such key bindings when the region is
>> active.
>
> Is not this a reason for making CUA mode default?

No.

> As long as it is not the default it will be a second class citizen

It will remain a second class citizen, period, because its operation
interferes with the normal Emacs operation and its most important
keybindings.

> and obstacles like this will remains. And those makes it quite a bit
> harder for new users.

Yes, getting coherent behavior from Emacs is much harder with CUA mode
enabled.  It is not a good default setting for new users.

>> Let's not revisit this discussion.  It is not difficult to turn on
>> CUA mode, for those who want it; it's even in the Options menu.
>
> That is not the problem.

The problem is that some people can't take "no" for an answer and will
pretend they have not been given ample hearing when the results of a
rational discussion were not to their liking.

The Emacs developing list is being bogged down increasingly by repeated
whinings that pretend an issue has not already been exhaustively
covered.  That is annoying enough when new people jump into the list
without educating themselves about the status quo.  When, however, the
same people keep doing it, with the implied threat that they'll keep
this up indefinitely, keeping the rest of the list from doing useful
work until their bidding is done, it is not funny.

-- 
David Kastrup

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 2:24 PM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Sat, Jul 17, 2010 at 7:51 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>>> Ivan Kanis <expire-by-2010-07-22@kanis.fr> writes:
>>>
>>>> I think turning on CUA mode by default would help first time users. If
>>>> there's a one line of lisp to turn it off and have the old behavior I
>>>> don't mind. I don't think veteran emacs user would mind either.
>>>
>>> No, having CUA mode on by default is off the table.
>>>
>>> This proposal has been discussed before, and there are many problems
>>> with it.  For instance, by default, C-c LETTER is reserved for user
>>> customizations; CUA prevents such key bindings when the region is
>>> active.
>>
>> Is not this a reason for making CUA mode default?
>
> No.
>
>> As long as it is not the default it will be a second class citizen
>
> It will remain a second class citizen, period, because its operation
> interferes with the normal Emacs operation and its most important
> keybindings.
>
>> and obstacles like this will remains. And those makes it quite a bit
>> harder for new users.
>
> Yes, getting coherent behavior from Emacs is much harder with CUA mode
> enabled.  It is not a good default setting for new users.
>
>>> Let's not revisit this discussion.  It is not difficult to turn on
>>> CUA mode, for those who want it; it's even in the Options menu.
>>
>> That is not the problem.
>
> The problem is that some people can't take "no" for an answer and will
> pretend they have not been given ample hearing when the results of a
> rational discussion were not to their liking.

Bullshit. I have heard this many times. It does not make the arguments better.

Just realize this is a difficult situation instead with no easy solution.

> The Emacs developing list is being bogged down increasingly by repeated
> whinings that pretend an issue has not already been exhaustively
> covered.  That is annoying enough when new people jump into the list
> without educating themselves about the status quo.  When, however, the
> same people keep doing it, with the implied threat that they'll keep
> this up indefinitely, keeping the rest of the list from doing useful
> work until their bidding is done, it is not funny.

I am getting tired of this and will probably like many others have
done before give up. I got some private mails about this when starting
to be more active in Emacs development.

Re: Emacs learning curve

[Davis Herring]

> Is not this a reason for making CUA mode default? As long as it is not
> the default it will be a second class citizen and obstacles like this
> will remains. And those makes it quite a bit harder for new users.

If it is in fact the case that "As long as [a keymap] is not the default
... obstacles like this will remain[]", then it would still be true (but
about the current global map) if CUA were the default, and so obstacles
would still remain.  (You were making a point very much like this in a
more recent message.)  So how can your argument favor either as the
default?

Of course, I think I know the answer.  You think that it is not the keymap
conflicts, but the lack of CUA itself, that makes it "quite a bit harder
for new users".  So then the obstacles (keymap conflicts) are bad, but
only because they interfere with the obvious, necessary adoption of
CUA-as-default.  But look at the resulting logic:

1. Keymap conflicts make it hard/problematic to change the default.
2. If CUA became the default, the keymap conflicts would have been
addressed.  (Because they had to be!)
3. It would then no longer be problematic to change the default.
4. Therefore, we should adopt CUA, because it's not problematic to do so.

Step 3 never happens, because the benefit it provides occurs too late. 
"If the problem were already solved, it would be easy, so let's do it!"

My sincerest apologies if I misunderstand your thinking.  But if I
understand it correctly, please don't construct a circular argument and
then hide it by connecting keymap conflicts (which we're all unhappy
about) directly to "quite a bit harder for new users", which is not a
point everyone agrees on.

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 learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 4:20 PM, Davis Herring <herring@lanl.gov> wrote:
>> Is not this a reason for making CUA mode default? As long as it is not
>> the default it will be a second class citizen and obstacles like this
>> will remains. And those makes it quite a bit harder for new users.
>
> If it is in fact the case that "As long as [a keymap] is not the default
> ... obstacles like this will remain[]", then it would still be true (but
> about the current global map) if CUA were the default, and so obstacles
> would still remain.  (You were making a point very much like this in a
> more recent message.)  So how can your argument favor either as the
> default?


Thanks. This post was a bit fun ;-)

This was nearly the essence of my argument, but not quite. The current
default bindings have so to say been worked through. CUA mode bindings
have not been worked through. I will not say much more now. I think
you can explore this argument more yourself.


> Of course, I think I know the answer.  You think that it is not the keymap
> conflicts, but the lack of CUA itself, that makes it "quite a bit harder
> for new users".


No, that is not what I mean. You are oversimplificating here. There
are currently keymap conflicts when you are using CUA mode and that is
an obstacle too for new users that are used to CUA bindings (and would
prefer to use them).


> So then the obstacles (keymap conflicts) are bad, but
> only because they interfere with the obvious, necessary adoption of
> CUA-as-default.


This is your own conclusion, not following from the essence of my arguments.


> But look at the resulting logic:
>
> 1. Keymap conflicts make it hard/problematic to change the default.


Isn't it more the clash between Emacs traditional bindings and CUA
bindings? CUA does not in itself give rise to keymap conflicts. The
corresponding bindings in trad Emacs are also single key bindings.


> 2. If CUA became the default, the keymap conflicts would have been
> addressed.  (Because they had to be!)


Yes. And I have no doubt that the problem for old Emacs users would be
solved too.


> 3. It would then no longer be problematic to change the default.


There would be a framework for it.


> 4. Therefore, we should adopt CUA, because it's not problematic to do so.


I never said so... ;-)


> Step 3 never happens, because the benefit it provides occurs too late.


For old users, yes. But the benefits could be more users and
developers and that would probably benefit old users too. There are
many things we are not able to do because of lack of developers.


> "If the problem were already solved, it would be easy, so let's do it!"


:-)  This is one of the cornerstones in positive psychology. It works.


> My sincerest apologies if I misunderstand your thinking.  But if I
> understand it correctly, please don't construct a circular argument and
> then hide it by connecting keymap conflicts (which we're all unhappy
> about) directly to "quite a bit harder for new users", which is not a
> point everyone agrees on.


No problem. I hope I did not misunderstand you too much.

Re: Emacs learning curve

[Alfred M. Szmidt]

   Let's not revisit this discussion.  It is not difficult to turn on CUA
   mode, for those who want it; it's even in the Options menu.

Maybe it could be added to the splash screen, or the tutorial?  That
could be a good way compromise.

A more modest proposal (Was: Emacs learning curve)

[Daniel Colascione]

On 7/17/10 10:51 AM, Chong Yidong wrote:

> No, having CUA mode on by default is off the table.

Agreed, but there are a few less disruptive ideas that are still worth
considering:

1) cua-selection-mode, or its moral equivalent

cua-selection-mode doesn't play games C-c and C-x or interfere with any
normal Emacs keybinding, but it does give users bindings for
control-insert, shift-insert, and shift-delete.

These keystrokes perform "copy", "paste", and "cut", respectively, and
the same keystrokes do similar things in other CUA applications --- it's
be easy to tell users, "unlike most programs, Emacs does not use C-c,
C-x, and C-v for copy and paste: Emacs was old when these bindings were
new, and they're used for something very different in Emacs. But Emacs
*does* support using Control-Insert, Shift-Delete, and Shift-Insert for
copy, cut, and paste. So do most other programs; learn to use these keys
instead."

2) More descriptive minibuffer messages for key chords

Right now, pressing C-c by itself simply displays "C-c -"; C-x is
similar. Novice users would benefit if this message read something like
"C-c - <waiting for command - C-h for help>" instead so that they notice
faster that C-c and C-x are very different in Emacs.

3) Natural binding for C-z

Bind C-z by default to this function:

(defun undo-or-suspend-emacs ()
  "Undo if we're in a windowing system, or suspend emacs if we're in a TTY"
  (interactive)
  (setq this-command (if window-system 'undo 'suspend-emacs))
  (call-interactively this-command))


Adopting this binding will ensure Emacs has the most natural and common
behavior on C-z for a given environment. Besides, not much of value is
lost: why bother with C-z in a windowing system when the system probably
provides its own idiomatic way of minimizing a window?

Re: A more modest proposal

[David Kastrup]

Daniel Colascione <daniel@censorshipresearch.org> writes:

> On 7/17/10 10:51 AM, Chong Yidong wrote:
>
>> No, having CUA mode on by default is off the table.
>
> Agreed, but there are a few less disruptive ideas that are still worth
> considering:

Wasn't this supposed to be an unmoderate mailing list?

Oh wait, I did not notice your mail address.

Anyway, I believe that most of your proposals were on the table at one
time, and they were canned for the time being because they would have
involved separating the whole of CUA mode into functionally cleaner
separated parts.

And none of people totally for the whole of CUA mode or totally against
the whole of it it could be interested in doing that work.

-- 
David Kastrup

Re: A more modest proposal (Was: Emacs learning curve)

[Jan Djärv]

Daniel Colascione skrev 2010-07-23 08.18:

> 3) Natural binding for C-z
>
> Bind C-z by default to this function:
>
> (defun undo-or-suspend-emacs ()
>    "Undo if we're in a windowing system, or suspend emacs if we're in a TTY"
>    (interactive)
>    (setq this-command (if window-system 'undo 'suspend-emacs))
>    (call-interactively this-command))
>
>
> Adopting this binding will ensure Emacs has the most natural and common
> behavior on C-z for a given environment. Besides, not much of value is
> lost: why bother with C-z in a windowing system when the system probably
> provides its own idiomatic way of minimizing a window?

There may not be a keyboard command for minimizing the window.  C-z is so much 
faster than reaching for the mouse when you are typing.

	Jan D.

Re: A more modest proposal (Was: Emacs learning curve)

[Daniel Colascione]

On 7/23/10 12:20 AM, Jan Djärv wrote:
> There may not be a keyboard command for minimizing the window.

And for some bizarre shells, you may have to send SIGSTOP to an
application to suspend it; but most environments are reasonable;
likewise for windowing systems.

>  C-z is
> so much faster than reaching for the mouse when you are typing.

But minimizing Emacs means you've *stopped* typing. :-)

Re: A more modest proposal

[Thien-Thi Nguyen]

() Daniel Colascione <daniel@censorshipresearch.org>
() Fri, 23 Jul 2010 00:23:35 -0700

   But minimizing Emacs means you've *stopped* typing. :-)

the keyboard, untouched, has a habit of lingering
despite past depressions of my dagnabit fingering.
  one stroke: i be parting,
  no joke, soon restarting,
ratlessly cycling!  emacs ready?  well, bring 'er in!

thi

Re: A more modest proposal (Was: Emacs learning curve)

[Jan Djärv]

Daniel Colascione skrev 2010-07-23 09.23:
> On 7/23/10 12:20 AM, Jan Djärv wrote:
>> There may not be a keyboard command for minimizing the window.
>
> And for some bizarre shells, you may have to send SIGSTOP to an
> application to suspend it; but most environments are reasonable;
> likewise for windowing systems.
>
>>   C-z is
>> so much faster than reaching for the mouse when you are typing.
>
> But minimizing Emacs means you've *stopped* typing. :-)

... and moved on to another frame or application to continue typing there.

	Jan D.

Re: A more modest proposal

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
>> But minimizing Emacs means you've *stopped* typing. :-)
>
> ... and moved on to another frame or application to continue typing there.

Though if you're a keyboard-type, this sort of function is so handy in
_all_ contexts, it seems silly to have it work only in Emacs.... Don't
you define a WM-wide binding to do that?

[e.g. I define C-M-q to do that in the WM.]

-Miles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: A more modest proposal

[Jan Djärv]

Miles Bader skrev 2010-07-23 11.29:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>>> But minimizing Emacs means you've *stopped* typing. :-)
>>
>> ... and moved on to another frame or application to continue typing there.
>
> Though if you're a keyboard-type, this sort of function is so handy in
> _all_ contexts, it seems silly to have it work only in Emacs.... Don't
> you define a WM-wide binding to do that?
>
> [e.g. I define C-M-q to do that in the WM.]
>

To be honest, I seldom iconify windows, I use expose on OSX, or equivalent 
with Compiz, or I just cycle through them until I find the one I want.

I didn't know of C-x C-z, that is of course sufficient.  No need to have two 
bindings for what is really a seldom used command.

	Jan D.

RE: A more modest proposal (Was: Emacs learning curve)

[Drew Adams]

> >> There may not be a keyboard command for minimizing the window.
> >> C-z is so much faster than reaching for the mouse when you are typing.
> >
> > But minimizing Emacs means you've *stopped* typing. :-)
> 
> and moved on to another frame or application to continue typing there.

[FWIW (off topic), I iconify frames to small, thumbnail frames.
For me, C-z is a toggle: iconify/map.  And when a frame is thus
iconified it does not lose its focus.]

Re: A more modest proposal (Was: Emacs learning curve)

[Alfred M. Szmidt]

   1) cua-selection-mode, or its moral equivalent

   cua-selection-mode doesn't play games C-c and C-x or interfere with
   any normal Emacs keybinding, but it does give users bindings for
   control-insert, shift-insert, and shift-delete.

   These keystrokes perform "copy", "paste", and "cut", respectively,
   and the same keystrokes do similar things in other CUA applications
   --- it's be easy to tell users, "unlike most programs, Emacs does
   not use C-c, C-x, and C-v for copy and paste: Emacs was old when
   these bindings were new, and they're used for something very
   different in Emacs. But Emacs *does* support using Control-Insert,
   Shift-Delete, and Shift-Insert for copy, cut, and paste. So do most
   other programs; learn to use these keys instead."

I think this is a good idea; if it doesn't interfere with other
things.

   3) Natural binding for C-z

   Bind C-z by default to this function:

   (defun undo-or-suspend-emacs ()
     "Undo if we're in a windowing system, or suspend emacs if we're in a TTY"
     (interactive)
     (setq this-command (if window-system 'undo 'suspend-emacs))
     (call-interactively this-command))

   Adopting this binding will ensure Emacs has the most natural and
   common behavior on C-z for a given environment. Besides, not much
   of value is lost: why bother with C-z in a windowing system when
   the system probably provides its own idiomatic way of minimizing a
   window?

Having the same keybinding behave completely differently depending if
you use a windowing system or the console is a bad idea.  What about
having C-z C-z do suspend-frame, and C-z z ... do undo?  Not that I
see a need for yet another undo keybinding.

Re: A more modest proposal

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
> Having the same keybinding behave completely differently depending if
> you use a windowing system or the console is a bad idea.  What about
> having C-z C-z do suspend-frame, and C-z z ... do undo?  Not that I
> see a need for yet another undo keybinding.

There's already a better binding for suspend-frame:  "C-x C-z"

So I'd say, just change the meaning of C-z universally to undo, and let
people use C-x C-z for suspend.

-Miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: A more modest proposal

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> "Alfred M. Szmidt" <ams@gnu.org> writes:
>> Having the same keybinding behave completely differently depending if
>> you use a windowing system or the console is a bad idea.  What about
>> having C-z C-z do suspend-frame, and C-z z ... do undo?  Not that I
>> see a need for yet another undo keybinding.
>
> There's already a better binding for suspend-frame:  "C-x C-z"
>
> So I'd say, just change the meaning of C-z universally to undo, and let
> people use C-x C-z for suspend.

Arguably if Emacs is started from a tty where C-z is set to susp, the
user expectation might be that C-z suspends Emacs.

Arguably similar expectations would hold for C-s, C-v, C-q, C-u, so I am
not sure that this argument should prevail, even though C-z has a
slightly different quality, being slightly useful as a working panic
exit for the completely new user.

I don't agree with Alfred that minimization on a window system is
suitably similar to warrant the C-z keybinding as well on a window
system.

All in all, I don't think maintaining C-z in its current meaning is
worth the trouble, particularly on window systems.

-- 
David Kastrup

Re: A more modest proposal

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Arguably similar expectations would hold for C-s, C-v, C-q, C-u, so I am
> not sure that this argument should prevail, even though C-z has a
> slightly different quality, being slightly useful as a working panic
> exit for the completely new user.

Not to mention "C-c"...!

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: A more modest proposal

[Alfred M. Szmidt]

   >> Having the same keybinding behave completely differently
   >> depending if you use a windowing system or the console is a bad
   >> idea.  What about having C-z C-z do suspend-frame, and C-z z
   >> ... do undo?  Not that I see a need for yet another undo
   >> keybinding.
   >
   > There's already a better binding for suspend-frame: "C-x C-z"
   >
   > So I'd say, just change the meaning of C-z universally to undo,
   > and let people use C-x C-z for suspend.

That is a good idea; didn't know about that binding.

   I don't agree with Alfred that minimization on a window system is
   suitably similar to warrant the C-z keybinding as well on a window
   system.

   All in all, I don't think maintaining C-z in its current meaning is
   worth the trouble, particularly on window systems.

I don't have strong feelings about C-z, C-x C-z for suspend-frame is
good, remapping C-z completely to undo is good.  As long as C-z
doesn't behave completely differently on console vs. windowing systems
(eg. undo vs. suspend-frame), I atleast have no qualms about remapping
it.

Re: A more modest proposal

[Stefan Monnier]

> 1) cua-selection-mode, or its moral equivalent
> cua-selection-mode doesn't play games C-c and C-x or interfere with any
> normal Emacs keybinding, but it does give users bindings for
> control-insert, shift-insert, and shift-delete.

  in Emacs-20.7
  C-h c <C-insert> says it runs kill-ring-save
  C-h c <S-insert> says it runs yank
  C-h c <S-delete> says it runs kill-region

and this hasn't changed since, so I think we've had those standard
bindings for a while now.

> Adopting this binding will ensure Emacs has the most natural and common
> behavior on C-z for a given environment. Besides, not much of value is
> lost: why bother with C-z in a windowing system when the system probably
> provides its own idiomatic way of minimizing a window?

I don't really care about the behavior of C-z in a GUI frame, so if
someone wants to change it, feel free.  I would agree with Deniz that
the current behavior of iconifying the frame can be confusing, so maybe
it should prompt instead and then remember the answer in the .emacs.


        Stefan

Re: A more modest proposal

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Fri, 23 Jul 2010 16:02:05 +0200
> Cc: Chong Yidong <cyd@stupidchicken.com>,
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> I would agree with Deniz that the current behavior of iconifying the
> frame can be confusing, so maybe it should prompt instead and then
> remember the answer in the .emacs.

Just make it a disabled command, and you have all this for free.

Re: A more modest proposal

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Just make it a disabled command, and you have all this for free.

Except that it should not be disabled in a tty frame.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A more modest proposal (Was: Emacs learning curve)

[Stephen Eilert]

On Fri, Jul 23, 2010 at 3:18 AM, Daniel Colascione
<daniel@censorshipresearch.org> wrote:
> On 7/17/10 10:51 AM, Chong Yidong wrote:
>
>> No, having CUA mode on by default is off the table.
>
> Agreed, but there are a few less disruptive ideas that are still worth
> considering:
>
> 1) cua-selection-mode, or its moral equivalent
>
> cua-selection-mode doesn't play games C-c and C-x or interfere with any
> normal Emacs keybinding, but it does give users bindings for
> control-insert, shift-insert, and shift-delete.
>
> These keystrokes perform "copy", "paste", and "cut", respectively, and
> the same keystrokes do similar things in other CUA applications --- it's
> be easy to tell users, "unlike most programs, Emacs does not use C-c,
> C-x, and C-v for copy and paste: Emacs was old when these bindings were
> new, and they're used for something very different in Emacs. But Emacs
> *does* support using Control-Insert, Shift-Delete, and Shift-Insert for
> copy, cut, and paste. So do most other programs; learn to use these keys
> instead."
>
> 2) More descriptive minibuffer messages for key chords
>
> Right now, pressing C-c by itself simply displays "C-c -"; C-x is
> similar. Novice users would benefit if this message read something like
> "C-c - <waiting for command - C-h for help>" instead so that they notice
> faster that C-c and C-x are very different in Emacs.
>
> 3) Natural binding for C-z
>
> Bind C-z by default to this function:
>
> (defun undo-or-suspend-emacs ()
>  "Undo if we're in a windowing system, or suspend emacs if we're in a TTY"
>  (interactive)
>  (setq this-command (if window-system 'undo 'suspend-emacs))
>  (call-interactively this-command))
>
>
> Adopting this binding will ensure Emacs has the most natural and common
> behavior on C-z for a given environment. Besides, not much of value is
> lost: why bother with C-z in a windowing system when the system probably
> provides its own idiomatic way of minimizing a window?
>

Indeed; how often one suspends/minimizes Emacs?

This does seem to be a waste of a major keystroke.


--Stephen

Sent from my Emacs

Re: A more modest proposal

[Chong Yidong]

Daniel Colascione <daniel@censorshipresearch.org> writes:

> easy to tell users, "unlike most programs, Emacs does not use C-c,
> C-x, and C-v for copy and paste: Emacs was old when these bindings
> were new, and they're used for something very different in Emacs. But
> Emacs *does* support using Control-Insert, Shift-Delete, and
> Shift-Insert for copy, cut, and paste. So do most other programs;
> learn to use these keys instead."

This sounds vaguely plausible, but I don't think Control-Insert,
Shift-Delete, and Shift-Insert are very well known at all, nor that
people are going to be enthusiastic about switching to these slower
keybindings.

> Right now, pressing C-c by itself simply displays "C-c -"; C-x is
> similar. Novice users would benefit if this message read something
> like "C-c - <waiting for command - C-h for help>" instead so that they
> notice faster that C-c and C-x are very different in Emacs.

Patch welcome.

> (defun undo-or-suspend-emacs ()
>   "Undo if we're in a windowing system, or suspend emacs if we're in a TTY"
>   (interactive)
>   (setq this-command (if window-system 'undo 'suspend-emacs))
>   (call-interactively this-command))

This has the disadvantage that if users learn to rely on C-z to undo,
they will be confused when they try to run Emacs in a terminal and find
that the "undo key" suspends Emacs.

Re: Emacs learning curve

[Miles Bader]

Ivan Kanis <expire-by-2010-07-22@kanis.fr> writes:
>> Omochiroi!
>
> BTW if it's Japanese it's spelled omoshiroi.

Yes, but in this case the misspelling is why I have it as a signature...
(it's from the manga "Chi's Sweet Home", where the titular kitten
mispronounces everything...)

-Miles

-- 
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.

Omi[cs]iroi! (was: Emacs learning curve)

[Drew Adams]

> >> Omochiroi!
> >
> > BTW if it's Japanese it's spelled omoshiroi.
> 
> Yes, but in this case the misspelling is why I have it as a 
> signature... (it's from the manga "Chi's Sweet Home", where
> the titular kitten mispronounces everything...)

Whew!  I'm glad we got that cleared up.
(Finally some closure here. ;-) )

I was afraid we might be dealing with the tip of a French-Japanese vs
English-Japanese spelling iceberg.  Reassured.

Nevertheless, a few questions are begged.

What kind of keyboard does the kitten use?
What about tail-recursion optimization?
And does s?he prefer the Common Access Transitional standard?

RE: Omi[cs]iroi! (was: Emacs learning curve)

[Drew Adams]

Damn tail got in the way again - damn this Qwerty Control key!
I meant to type "Omo[cs]iroi", of course, not "Omi[cs]iroi".
 

Re: Omi[cs]iroi! (was: Emacs learning curve)

[Deniz Dogan]

2010/7/17 Drew Adams <drew.adams@oracle.com>:
>
> Damn tail got in the way again - damn this Qwerty Control key!
> I meant to type "Omo[cs]iroi", of course, not "Omi[cs]iroi".
>

This is all very important and everyone should read it!

-- 
Deniz Dogan

RE: Omi[cs]iroi! (was: Emacs learning curve)

[Drew Adams]

> This is all very important and everyone should read it!

Eureka!  You have found it!

Re: Omi[cs]iroi! (was: Emacs learning curve)

[Juanma Barranquero]

On Sat, Jul 17, 2010 at 22:30, Drew Adams <drew.adams@oracle.com> wrote:


> And does s?he prefer the Common Access Transitional standard?

(Definitely a "she", so s/s\?/s/ )

    Juanma

Re: Emacs learning curve

[Dirk-Jan C. Binnema]

>>>>> On Fri, 16 Jul 2010 21:05:17 +0200, Ivan Kanis ("IK") wrote:

  IK> Tom <levelhalom@gmail.com> wrote:
  >> Advanced users should have no problem adding a single line to their
  >> .emacs to switch on the compatibility mode
  >> e.g. (enable-classic-bindings) and new users would enjoy the familiar
  >> CUA-style bindings out of the box.

  IK> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
  IK> of easing new users experience.

In fact, making it an easy-settable *non*-default would be a good step
already, i.e., bundling various 'non-classical-emacs' ways in some easy way
for new users.

After all, even new users could be told that they need to add, say,

(newfangled-mode t)
 
in their .emacs; that makes it explicit (which is good when people ask other
users for help); and if adding one line to .emacs is too much, that user
probably won't find much in using emacs anyway.

Now all we need to do is agree on what 'newfangled-mode' should contain...

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: Emacs learning curve

[Stefan Monnier]

> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
> of easing new users experience.

We might even all agree with it, if/when we see that mythical one-line
and the effect it has.  Until that happens, noone can say for sure.


        Stefan

Re: Emacs learning curve

[Sebastian Rose]

>> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>> of easing new users experience.

Add just another line to our .emacs just to Make emacs behave like Emacs?

I do not agree.


  Sebastian

Re: Emacs learning curve

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>> of easing new users experience.
>
> We might even all agree with it, if/when we see that mythical one-line
> and the effect it has.  Until that happens, noone can say for sure.

Customization themes make the appearance of being in limbo.

-- 
David Kastrup

Re: Emacs learning curve

[Alfred M. Szmidt]

   > Advanced users should have no problem adding a single line to their
   > .emacs to switch on the compatibility mode
   > e.g. (enable-classic-bindings) and new users would enjoy the familiar
   > CUA-style bindings out of the box.

   I side with Tom, I wouldn't mind adding one line to my .emacs in favor
   of easing new users experience.

There is absolutley no proof that CUA would 'ease' a new users
experience; there is proof that it would make make the experience
harder for all who are accustomed to emacs though.

Re: Emacs learning curve

[David Kastrup]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > Advanced users should have no problem adding a single line to their
>    > .emacs to switch on the compatibility mode
>    > e.g. (enable-classic-bindings) and new users would enjoy the familiar
>    > CUA-style bindings out of the box.
>
>    I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>    of easing new users experience.
>
> There is absolutley no proof that CUA would 'ease' a new users
> experience; there is proof that it would make make the experience
> harder for all who are accustomed to emacs though.

I don't see that adding mode-, selection- and keypress-timing dependent
behavior in order to arrive at something that magically works half the
time like Notepad, half the time like Emacs, does much to make an
editing application more accessible to a new user.

-- 
David Kastrup

Re: Emacs learning curve

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>>    > Advanced users should have no problem adding a single line to their
>>    > .emacs to switch on the compatibility mode
>>    > e.g. (enable-classic-bindings) and new users would enjoy the familiar
>>    > CUA-style bindings out of the box.
>>
>>    I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>>    of easing new users experience.
>>
>> There is absolutley no proof that CUA would 'ease' a new users
>> experience; there is proof that it would make make the experience
>> harder for all who are accustomed to emacs though.
>
> I don't see that adding mode-, selection- and keypress-timing dependent
> behavior in order to arrive at something that magically works half the
> time like Notepad, half the time like Emacs, does much to make an
> editing application more accessible to a new user.

To illustrate: do we really want to consider the following a suitable
user experience for new users?  Once they type more than 5 keys per
second, CUA behavior will get replaced by native Emacs behavior?  That
sort of cleverness is not predictable to a new user.

cua-prefix-override-inhibit-delay is a variable defined in `cua-base.el'.
Its value is 0.2

Documentation:
*If non-nil, time in seconds to delay before overriding prefix key.
If there is additional input within this time, the prefix key is
used as a normal prefix key.  So typing a key sequence quickly will
inhibit overriding the prefix key.
As a special case, if the prefix keys repeated within this time, the
first prefix key is discarded, so typing a prefix key twice in quick
succession will also inhibit overriding the prefix key.
If the value is nil, use a shifted prefix key to inhibit the override.

You can customize this variable.

[back]

Try marking an active region in CUA mode, then jump to the other side of
the region using a properly timed C-x C-x C-x.

This is supposed to be an editor, not an arcade game.  And no, I don't
think that this sort of user interface problem can be solved by
discussing the dexterity to be expected from a new user.

-- 
David Kastrup

Re: Emacs learning curve

[Wojciech Meyer]

So what the vim users say? Out of curisoity. Sent from mobile...

On 7/22/10, David Kastrup <dak@gnu.org> wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> "Alfred M. Szmidt" <ams@gnu.org> writes:
>>
>>>    > Advanced users should have no problem adding a single line to their
>>>    > .emacs to switch on the compatibility mode
>>>    > e.g. (enable-classic-bindings) and new users would enjoy the
>>> familiar
>>>    > CUA-style bindings out of the box.
>>>
>>>    I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>>>    of easing new users experience.
>>>
>>> There is absolutley no proof that CUA would 'ease' a new users
>>> experience; there is proof that it would make make the experience
>>> harder for all who are accustomed to emacs though.
>>
>> I don't see that adding mode-, selection- and keypress-timing dependent
>> behavior in order to arrive at something that magically works half the
>> time like Notepad, half the time like Emacs, does much to make an
>> editing application more accessible to a new user.
>
> To illustrate: do we really want to consider the following a suitable
> user experience for new users?  Once they type more than 5 keys per
> second, CUA behavior will get replaced by native Emacs behavior?  That
> sort of cleverness is not predictable to a new user.
>
> cua-prefix-override-inhibit-delay is a variable defined in `cua-base.el'.
> Its value is 0.2
>
> Documentation:
> *If non-nil, time in seconds to delay before overriding prefix key.
> If there is additional input within this time, the prefix key is
> used as a normal prefix key.  So typing a key sequence quickly will
> inhibit overriding the prefix key.
> As a special case, if the prefix keys repeated within this time, the
> first prefix key is discarded, so typing a prefix key twice in quick
> succession will also inhibit overriding the prefix key.
> If the value is nil, use a shifted prefix key to inhibit the override.
>
> You can customize this variable.
>
> [back]
>
> Try marking an active region in CUA mode, then jump to the other side of
> the region using a properly timed C-x C-x C-x.
>
> This is supposed to be an editor, not an arcade game.  And no, I don't
> think that this sort of user interface problem can be solved by
> discussing the dexterity to be expected from a new user.
>
> --
> David Kastrup
>
>
>

-- 
Sent from my mobile device

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 9:27 PM, Wojciech Meyer
<wojciech.meyer@googlemail.com> wrote:
> So what the vim users say? Out of curisoity. Sent from mobile...


I have tried vim, but switched to Emacs. The reason?

Before trying vim I used a proprietary vi port on w32 that supported
CUA. When that was no longer supported I tried vim, but at that time
vim did not support CUA. That is how I come to consider Emacs again
since I read it now had a better vi emulation mode than the old
vip-mode. (In my opinion both vi-mode and vip-mode should be marked
obsolete and phased out as soon as possible.)

I would not even consider using Emacs without a vi emulation mode. I
tried it before and found it was just too much trouble. Vi is much
faster for editing for me.


Interestingly enough vim now has CUA support. So I believe the reason
that Emacs does not have CUA support is not that the current primary
possible user base (which is probably about the same as vim) does not
want CUA.

RE: Emacs learning curve

[Drew Adams]

> I would not even consider using Emacs without a vi emulation mode.

!

> Emacs does not have CUA support

This should go in NEWS.  It's news to me, at least.
Might be news to Kim too.  Please file a bug/enhancement report.

> the current primary possible user base (which is probably
> about the same as vim)

(Same as the current vim users or same as the primary possible user base for
vim?)

Sounds like you think that the notorious newbies we've been arguing about
attracting - that horrendous, humongous horde who refuse to come to Emacs
because it does not adhere to CUA by default - those who would save Emacs from
certain, imminent extinction - are none other than ... (drumroll) ... the vim
users.

Viper will save Emacs by expropriating vim?  Surely this is not about a crusade
for Emacs to finally conquer vi by adopting CUA by default, is it?  ;-)  Instead
of The End Of Emacs, we would announce The End Of The Editor Wars?  My, we are
ambitious.  Amazing what a little CUA in the blood can do to perk one up.

Whatever happened to Eclipse in this discussion?
Now we're spiraling down to `vi vs Emacs'?

Re: Emacs learning curve

[Lennart Borgman]

On Sun, Jul 25, 2010 at 4:22 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> I would not even consider using Emacs without a vi emulation mode.
>
> !
>
>> Emacs does not have CUA support
>
> This should go in NEWS.  It's news to me, at least.
> Might be news to Kim too.  Please file a bug/enhancement report.


What could I say? That it is very interesting that you go with the
crowd? Why argue like this about that vim has CUA support turned on by
default while Emacs does not have it? (We all know the reason, it is
difficult to get it into Emacs. There is no reason to argue it is
unimportant too. Not everyone agrees on that and we all know that.)

RE: Emacs learning curve

[Drew Adams]

> >> Emacs does not have CUA support
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This should go in NEWS.  It's news to me, at least.
> > Might be news to Kim too.  Please file a bug/enhancement report.
> 
> What could I say? That it is very interesting that you go with the
> crowd? Why argue like this about that vim has CUA support turned on by
> default while Emacs does not have it?

Emacs _does_ have CUA support.

Re: Emacs learning curve

[Fabian Ezequiel Gallina]

2010/7/25 Drew Adams <drew.adams@oracle.com>:
>
> Whatever happened to Eclipse in this discussion?
> Now we're spiraling down to `vi vs Emacs'?
>

I don't know if you people were aware of this. But once I had to work
on a Java project and I was forced to use Eclipse. Looking deep at the
preferences I was amazed when I found that there was an Emacs
key-binding scheme available.

Being on the opposite situation, in Emacs is even easier to find how
to activate CUA: Options -> C-x/C-c/C-v Cut and Paste (CUA)

With that said, I guess discussing activating CUA by default is not
really relevant at all and I think a better discussion is if it should
be mentioned in the tutorial.

For me the way to improve Emacs' learning curve is not changing Emacs
itself but providing quick/easy to understand documentation.

For instance together with the Tutorial we could have:
    * a Quick Command Reference with just common basic commands.
    * an Available Minor Modes Quick Reference showing a table of the
form (minor-mode description).
    * an Available Major Modes Quick Reference. The same as above but
for major-modes.
    * Tips and Tricks describing some nice things to do with your
Emacs (for instance introducing M-x apropos and C-h k)

And I'm thinking of those to be listed in (about-emacs) just before
the Emacs Tutorial.

What do you think about that?


Best Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Jul 22, 2010 at 9:21 PM, David Kastrup <dak@gnu.org> wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> "Alfred M. Szmidt" <ams@gnu.org> writes:
>>
>>>    > Advanced users should have no problem adding a single line to their
>>>    > .emacs to switch on the compatibility mode
>>>    > e.g. (enable-classic-bindings) and new users would enjoy the familiar
>>>    > CUA-style bindings out of the box.
>>>
>>>    I side with Tom, I wouldn't mind adding one line to my .emacs in favor
>>>    of easing new users experience.
>>>
>>> There is absolutley no proof that CUA would 'ease' a new users
>>> experience; there is proof that it would make make the experience
>>> harder for all who are accustomed to emacs though.


Of course there are evidence that CUA would make it easier in some
respect for new users. They would immediately be able to use the CUA
keys.


>> I don't see that adding mode-, selection- and keypress-timing dependent
>> behavior in order to arrive at something that magically works half the
>> time like Notepad, half the time like Emacs, does much to make an
>> editing application more accessible to a new user.


Emacs is already mode dependent since it is using keybindings with
several steps.


> To illustrate: do we really want to consider the following a suitable
> user experience for new users?  Once they type more than 5 keys per
> second, CUA behavior will get replaced by native Emacs behavior?  That
> sort of cleverness is not predictable to a new user.


This is an excellent example of Kim's creativity to work around the
resistance to adopt CUA bindings in Emacs. Of course this work around
is not needed any more of CUA would be made a first class citizen in
Emacs.

It actually does not get in the way that often, but it is still
disturbing. I think Kim was aware of this because he gave another way
to work around the problem with C-c and C-x in Emacs: You can add a
shift to those keys if you want to old Emacs behavior: C-S-c and
C-S-x. (I always use this variant when it is necessary.)


> This is supposed to be an editor, not an arcade game.  And no, I don't
> think that this sort of user interface problem can be solved by
> discussing the dexterity to be expected from a new user.


Sure, it is not supposed to be an ancient arcade game, especially not
for new users.

Re: Emacs learning curve

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>> There is absolutley no proof that CUA would 'ease' a new users
>>>> experience; there is proof that it would make make the experience
>>>> harder for all who are accustomed to emacs though.
>
> Of course there are evidence that CUA would make it easier in some
> respect for new users. They would immediately be able to use the CUA
> keys.

I think by "evidence," he meant actual data, not suppositions.

I've watched at least one CUA-accustomed complete Emacs noob learn
Emacs, and who didn't seemed bothered at all by the lack of C-x/etc
(they just used the menus for those things until they had become
accustomed to Emacs keys).

Would there have been some small gain in learning speed if C-x was
available?  Probably.  Would that gain have been justified by the costs
of supporting C-x?  Arguably not.

> Emacs is already mode dependent since it is using keybindings with
> several steps.

[That is not a mode in the normal sense -- people don't think of "oh,
I'll enter C-x mode, then hit C-s," they think of the entire thing
sequence as a single entity.  So the downsides normally attributed to
modality don't really apply.]

>> To illustrate: do we really want to consider the following a suitable
>> user experience for new users?  Once they type more than 5 keys per
>> second, CUA behavior will get replaced by native Emacs behavior?  That
>> sort of cleverness is not predictable to a new user.
>
> This is an excellent example of Kim's creativity to work around the
> resistance to adopt CUA bindings in Emacs. Of course this work around
> is not needed any more of CUA would be made a first class citizen in
> Emacs.

It's certainly a clever mechanism, and it's to Kim's credit that it
works as well as it does, but that doesn't make it any less of an
unreliable kludge.  It's _not_ something we want turned on by default.

> Of course this work around is not needed any more of CUA would be made
> a first class citizen in Emacs.

No doubt --- but the costs of doing that (which you constantly seem to
simply ignore) seem very high, and thus it is unlikely to happen.

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

RE: Emacs learning curve

[Drew Adams]

> I've watched at least one CUA-accustomed complete Emacs noob learn
> Emacs, and who didn't seemed bothered at all by the lack of C-x/etc
> (they just used the menus for those things until they had become
> accustomed to Emacs keys).

Don't forget that you are talking to an Emacs non-noob who uses CUA-mode (IIUC)
and Viper.  IOW, your newbie who learned Emacs is not someone Lennart is likely
to identify with (or vice versa).

Old-timers who never tried, or never learned to use, or never accepted Emacs key
bindings, and who repeatedly push here for Emacs to lose its default bindings in
favor of the emulation modes _they_ happen to be in the habit of using are _not_
typical of either Emacs users in general or Emacs newbies.

They are as dyed-in-the-wool as us other Emacs hard-liners.  They are simply
dyed in an emulation wool.  They try to carry high and monopolize the "Newbie"
banner, but IMO they do not speak for Emacs newbies.

"Newbie uber alles."  But which newbie?

(And yes, I do consider both CUA mode and Viper to be legitimate, first-class
citizens in the Emacs world.  One is not non-Emacs or anti-Emacs if one uses an
emulation mode.  Emacs is bigger than either of them or any other emulation
mode, however.)

Re: Emacs learning curve

[Lennart Borgman]

On Fri, Jul 23, 2010 at 7:57 PM, Miles Bader <miles@gnu.org> wrote:
>
>> Emacs is already mode dependent since it is using keybindings with
>> several steps.
>
> [That is not a mode in the normal sense -- people don't think of "oh,
> I'll enter C-x mode, then hit C-s," they think of the entire thing
> sequence as a single entity.  So the downsides normally attributed to
> modality don't really apply.]


Of course it is a mode in the normal sense, however with a short life.

It can create trouble for someone used to CUA keys where you cut with
C-x or copy with C-c.


>> Of course this work around is not needed any more of CUA would be made
>> a first class citizen in Emacs.
>
> No doubt --- but the costs of doing that (which you constantly seem to
> simply ignore) seem very high, and thus it is unlikely to happen.


So is not the best to find a way to minimize the cost?

Re: Emacs learning curve

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> [That is not a mode in the normal sense -- people don't think of "oh,
>> I'll enter C-x mode, then hit C-s," they think of the entire thing
>> sequence as a single entity.  So the downsides normally attributed to
>> modality don't really apply.]
>
> Of course it is a mode in the normal sense, however with a short life.

The "normal sense" precludes "modes" that have sub-second lifetimes in
use, because they are thought about very differently by the user.

> It can create trouble for someone used to CUA keys where you cut with
> C-x or copy with C-c.

No doubt; a shame, but it's not obvious what we can do about it without
causing many more problems.

>>> Of course this work around is not needed any more of CUA would be made
>>> a first class citizen in Emacs.
>>
>> No doubt --- but the costs of doing that (which you constantly seem to
>> simply ignore) seem very high, and thus it is unlikely to happen.
>
> So is not the best to find a way to minimize the cost?

Sure -- but thus far, the only remotely practical method appears to be
"don't use CUA."

I don't have any religious objection to CUA keys (well at least the
C-x/C-c/C-v triumvirate), if there were a practical way of accommodating
them without excessive problems -- but thus far, despite all the
vigorous hand-waving and pontificating, nobody has actually come up with
anything that seems remotely practical.

-Miles

-- 
Run away!  Run away!

Re: Emacs learning curve

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> I don't have any religious objection to CUA keys (well at least the
> C-x/C-c/C-v triumvirate), if there were a practical way of accommodating
> them without excessive problems -- but thus far, despite all the
> vigorous hand-waving and pontificating, nobody has actually come up with
> anything that seems remotely practical.

I have stayed out of this discussion so far ... as the topic seemed to
about enabling CUA by default or not - I have no opinion about that --
having it as an easy to find option on the menus is good enough for me.

However, I do take offence from your statement about CUA not being
"remotely practical". 

Do you actually use CUA mode to a degree where you have practical
experience to backup that statement -- or on what facts do you base your
evaluation of the practical usefulness of CUA?

I have used it for many years now (no surprise), and yes, it does
stumble on me a few times each year -- as it to be expected - but it is
nowhere near being impractical. For every day work -- it just works!

To me, CUA bindings in emacs is about being able to easyly cut and 
paste BETWEEN applications. If you live your entire life inside Emacs,
then CUA binding has no merit on its own.  When you have to
interact with other applications, being able to use the same keys
for cut and paste is invaluable IMO - and far outweighs the tiny
quirks you may experience with CUA mode from time to time.

BTW, the major problem with enabling CUA bindings by default is NOT
C-x and C-c (and the associated hacks), but that it "steals" the C-v
binding permanently.  At least you have to rewrite all the tutorials...

-- 
Kim F. Storm  http://www.cua.dk

Re: Emacs learning curve

[Miles Bader]

no-spam@cua.dk (Kim F. Storm) writes:
> Do you actually use CUA mode to a degree where you have practical
> experience to backup that statement -- or on what facts do you base your
> evaluation of the practical usefulness of CUA?

A combination of (a) trying it out, and (b) simple reasoning.

-Miles

-- 
Arrest, v. Formally to detain one accused of unusualness.

Re: Emacs learning curve

[David Robinow]

On Sat, Jul 24, 2010 at 7:52 AM, Kim F. Storm <no-spam@cua.dk> wrote:
> BTW, the major problem with enabling CUA bindings by default is NOT
> C-x and C-c (and the associated hacks), but that it "steals" the C-v
> binding permanently.  At least you have to rewrite all the tutorials...
FWIW, I did    (global-set-key "\C-v" 'yank)
several years ago when I got tired of typos causing me to lose my
place. I realized I hadn't intentionally used C-v ever.
I've never tried CUA.

Re: Emacs learning curve

[Stefan Monnier]

> That's why CUA-style editing should be made the consistent default, so Emacs 
> works like all other modern application on KDE/Gnome/Windows, etc. and the
> current behavior should be provided as a compatibility mode for those who
> are accustomed to the old behavior.

I might agree.  But as long as noone submits actual code to do that, it
won't happen.


        Stefan

Re: Emacs learning curve

[Tom]

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> 
> > That's why CUA-style editing should be made the consistent default, so Emacs 
> > works like all other modern application on KDE/Gnome/Windows, etc. and the
> > current behavior should be provided as a compatibility mode for those who
> > are accustomed to the old behavior.
> 
> I might agree.  But as long as noone submits actual code to do that, it
> won't happen.
> 

Those against the idea say the main problem with CUA mode is it hijacks C-c
and C-x which are the standard bindings in current Emacs and they are
hardwired in lots of places.

Let's say the newbie user who wants to copy with C-c/C-x/C-v don't want
to use the bindings C-w and C-y.

Is it technically possible to implement a mode which binds copy to C-c, 
cut to C-x, but before that it rebinds all C-x bindings to C-w and
C-c bindings to C-y? It should do it dynamically, of course, so when a
new buffer is opened with new bindings or a new minor mode is activated
it should change the bindings on the fly.

This way the newbie could also have a standard and consistent set of
bindings, only the prefix keys would be different in newbie mode and
veteran mode.

RE: Emacs learning curve

[Drew Adams]

> Let's say the newbie user who wants to copy with C-c/C-x/C-v 
> don't want to use the bindings C-w and C-y.
> 
> Is it technically possible to implement a mode which binds 
> copy to C-c, cut to C-x, but before that it rebinds all
> C-x bindings to C-w and C-c bindings to C-y? It should do it
> dynamically, of course, so when a new buffer is opened with
> new bindings or a new minor mode is activated
> it should change the bindings on the fly.
> 
> This way the newbie could also have a standard and consistent set of
> bindings, only the prefix keys would be different in newbie mode and
> veteran mode.

Why not teach newbies Emacs instead of teaching Emacs "Newbie"?

We've seen no _evidence_ about a supposed dearth of newbies coming to Emacs, in
spite of repeated _claims_.  No Emacs-is-dying problem has been shown, so far.

And yet we've moved on to back-and-forth discussions of _how_ to solve this
undemonstrated problem.  No problem => don't fix it.

It was pointed out that Emacs, like Spanish, has a reason to exist even if it is
not the most widespread language and it uses vocabulary and pronunciation that
foreigners (who are admittedly more numerous than Emacs speakers) can sometimes
find disconcerting.

You cannot get off the plane in Kashgar and expect to act (and expect others to
act) like you are still in your living room in Kansas.  You're _not_ in Kansas
anymore.  If you want to enjoy Kashgar, then learn a little Turkish and a little
Chinese.  And yes, taste the local food instead of whining about there being no
McDonalds.

If you don't really want to taste the local food, speak the language, listen to
the music, dance the dance, and so on, then WTF are you doing in Kashgar?

And no, tourism to Kashgar and Emacs is not dying out.  Some tourists are really
interested in their trip and the destination.  Others are not.  That's all.  We
should not cater to the WannaMcDonalds.  Understand them?  Yes.  Remake
everything to make them feel at home?  Definitely not.

Emacs is a beautiful land.  Call it exotic, if you like.  Kansas it ain't.  And
even if it _were_ dying, the solution would not be to airlift MacDos to help it
fit in with the rest of the mess.

Call it a niche market, but Emacs, its vocabulary, keybindings, and so on is a
_system_ with its own raison d'etre.  It has internal coherency and consistency,
even if that sometimes conflicts with what outsiders might be used to.

No one claims that Emacs is perfect and its keybindings and vocabulary are set
in concrete.  But it is very good.  It has been refined by good, great, and
middling users and developers over a period of ~35 years.  It has evolved.

And improvements in keybindings, vocabulary, and such _are_ discussed here,
quite often in fact (possibly too often).  The simplistic do-what-newbie-expects
argument doesn't cut the mustard, however, and for good reason.  It just doesn't
add anything new to the party.

It's curious that these discussions start by pointing to real, solid features
that are in e.g. Eclipse but missing from Emacs.  Everyone agrees that Emacs
could do with a little catching up in some such areas.

But then, when it becomes clear that adding such features, while worthwhile, is
not trivial, the discussion morphs to newbie-izing key bindings.  The latter
discussion is facile - like taxes and government, everyone can have an easy
opinion about key bindings.

Emacs does need improving.  Eclipsify it, if you want, adding useful, powerful
features that actually do something.  Please do.  But stop with the binding-shed
color discussions.

Emacs and its internal logic are complex, like your eyeball or your kidney.
Such things are not to be fiddled with naively.

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

> We've seen no _evidence_ about a supposed dearth of newbies coming to
> Emacs, in spite of repeated _claims_.  No Emacs-is-dying problem has
> been shown, so far.

Of course it is very hard to show statistics for newbies. OTOH, absence
of proof does not indicate that the fact does not exists.

Let's turn to a source from where to get hard numbers then.

This is a list of number of committers per year, based on the changelogs:

2010  91
2009 132
2008 155
2007 147
2006 134
2005 151
2004 117
2003 127
2002 107
2001  60
2000  61
1999  86
1998  93
1997 134
1996  68
1995  70
1994  74
1993  38
1992   9
1991  14
1990  15

My very personal interpretation of that series is that Emacs development
is not growing with its potential user base.

[snip]

RE: Emacs learning curve

[Drew Adams]

> > We've seen no _evidence_ about a supposed dearth of newbies 
> > coming to Emacs, in spite of repeated _claims_.  No
> > Emacs-is-dying problem has been shown, so far.
> 
> Of course it is very hard to show statistics for newbies. 
> OTOH, absence of proof does not indicate that the fact does
> not exists.

Can you say "Tooth Fairy"? "Santa Claus"?

I won't mention other religious figures.

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > We've seen no _evidence_ about a supposed dearth of newbies 
>> > coming to Emacs, in spite of repeated _claims_.  No
>> > Emacs-is-dying problem has been shown, so far.
>> 
>> Of course it is very hard to show statistics for newbies. 
>> OTOH, absence of proof does not indicate that the fact does
>> not exists.
>
> Can you say "Tooth Fairy"? "Santa Claus"?
>
> I won't mention other religious figures.

Can you say "Barack Obama"? "Paris Hilton"?

I have the same amount of evidence about their existence than of Santa
Claus. But somehow I've concluded that Barack Obama exists, and Santa
Claus does not. Some people would oppose that conclusion, though. Maybe
that discrepancy is to to the fact that I'm interested on pursuing the
truth, while others chose to narrow their knowledge-adquiring devices
for supporting wathever makes them feel happy.

For a long period of the PC era, Emacs was the king of the text editors
for technical users. Maybe some people had other preferences, but they
could hardly argue about the power of Emacs. Nowadays Emacs lacks behind
on productivity features for the needs of a large, growing set of their
target users and is going the way of OS/2, VAX, the Amiga and other
pieces of software that stay alive as living fossils just because the
efforts of some enthusiasts. If you doubt that, please join the group
that believes on the existence of Santa Claus.

What I'm trying to convey here is that Emacs can be again a top-notch
programming environment, second to none, the first choice for every
hacker. The first requisite for that is to stop being
self-complacent. And stop looking down on others too.

RE: Emacs learning curve

[Drew Adams]

> For a long period of the PC era, Emacs was the king of the 
> text editors for technical users.

Really?  Don't let a vi user hear you claim that.  In my (anecdotal) experience,
even in software research environments the number of vi users has at least
equalled that of Emacs users.  And in software development I've seen even more
vi use than in research.  I still do.

Has Emacs ever been the "king" in terms of numbers of technical users (numbers
of users seeming to be the measure you favor)?  I seriously doubt it.

From http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.html:

"Despite emacs' higher profile as a free software poster child, I think more
people actually use vi than emacs.  We sell more copies of our vi book than of
our emacs book -- almost twice as many each year.  This could be because emacs
has a free manual that is distributed with it.  But I saw a matching statistic
at Linux Expo, where O'Reilly sponsors a vi vs. emacs paintball game each year.
I happened to check the signup list, and noticed that there were about twice as
many people signed up for the vi team as for the emacs team.  (Maybe they just
like the vi t-shirt -- the team "uniform" -- more than the emacs t-shirt, but I
don't think so.)"

The paragraph before that one, BTW, should also provide some food for thought,
and is particularly germain to the topic ("Emacs learning curve"):

"Once you learn vi's admittedly unintuitive style, it is remarkably easy to use
and tremendously powerful.  Like a lot of things about UNIX, it only *seems*
difficult.  After a small barrier to entry, it is orders of magnitude more
powerful and easy to use than commercial word processors.  (But that's true of
emacs as well!)"

The point is not `vi vs Emacs', of course.  It is that Emacs (likewise vi) was
never "king", in terms of numbers of users.  And so what?  Emacs is not for
everyone, not even for every technical user.  Different people prefer different
tools in different contexts at different times for different jobs.  There are no
kings.

Behind or ahead, ahead or behind...  It's _not_ a popularity contest.  Dunno why
this popularity thing keeps coming up here (and on help-gnu-emacs) from time to
time.

Maybe it has to do with youth and a crying need to belong, to feel popular, to
have the coolest gadget or the latest, most wannahave toy.  Dunno.  ("Oh the
shame of it - did you see what he uses as his editor?  Emacs!  LOL!")

Totally beside the point, in any case.  It's not important for Emacs to be _the
most popular_.  It's important for Emacs to be useful and become even more
useful.

A redwood tree is not the most common plant in California.  But it has its
place.  It does some things exceedingly well.  Of course, some people call it a
living fossil...  (With a little luck and a little global warming, redwoods
might just make a big comeback - they once grew planet-wide.)

> Nowadays Emacs lacks behind on productivity features

Haven't we all agreed that Emacs could be improved by adding some of those
productivity features?  And that is so even though we have not agreed that Emacs
is "behind" generally.  But just what are the "productivity features" that we
might like to add to Emacs?

There you go again, slip-sliding from (1) "productivity features", which no one
argues against and with some Eclipse features serving as oft-cited examples, to
(2) the idea that the Emacs default key bindings need to be those that a newbie
is already used to in other apps.

No, you didn't actually state #2 in that sentence, but that's what this is
about, isn't it?  That's where the disagreement and controversy lies.  A tempest
in a teapot.  Absolutely no one has spoken against adding any "productivity
features" - real, useful features that help you get things done.

You put forth a broad generality about Emacs lacking "productivity features" as
support for the proposition that CUA bindings etc. should be used.  Sheesh.

> stay alive as living fossils just because the efforts of
> some enthusiasts.

Not to worry.  Emacs will be digging up your and my remains and chuckling about
them, long, long after we - enthusiasts or not - have turned from living fossils
to dead ones.

The fact that you think that Emacs is "going the way of...a living fossil" shows
how far out into the ozone you've wandered.  Or maybe you don't really think
that but you hope that saying it will scare folks into accepting the particular
changes you have in mind?  Dunno - you tell me.

> What I'm trying to convey here is that Emacs can be again a top-notch
> programming environment, second to none, the first choice for every
> hacker.

Amen.  Hallelujah.  We all agree.  Emacs has that potential.  We do not agree
that what is lacking is to make CUA mode etc. the default.  That's all.

> The first requisite for that is to stop being
> self-complacent. And stop looking down on others too.

No one is complacent.  No one is looking down on anyone else.  Some seem to be
pretending to speak for noobs.  That is presumptuous, I agree, but even those
misleading and misguided souls are likely not looking down on anyone.

Just because some people disagree with the proposition that Emacs default key
bindings MUST CHANGE NOW OR ELSE! is no reason to attack those people as being
complacent or condescending.

Everyone here wants to improve Emacs.  No one thinks it should stand dead still.
The questions that are debated and need to be debated have to do with _which_
changes to make, not whether all change is bad.

The devil is in the details.  It happens, IMHO, that those most familiar with
Emacs have the most respect for the existing design logic, UI included.  That's
natural.

Someone less familiar with the design and the history (past analysis and debate
etc.) can easily suppose that this or that aspect is arbitrary or a historical
artifact, legacy cruft that might as well be upended and rooted out.  Dig up
that tangled old growth and plant the wonder seeds that everyone else has so
much success with.

Are there some weeds in the garden?  No doubt.  But the garden is sound and
healthy, and based on a good plan.  Show us a plant you think is a weed; show us
a replacement seed so we can argue about the pros and cons.  But please don't
just cry that the sky is falling! the garden is dying! and no one is interested
in it anymore! except a few old caretakers.

Respecting the existing design because of familiarity with its logic is not the
same thing as being stubbornly unwilling to improve Emacs.  Not agreeing that
some particular change you propose is what's needed is not the same as refusing
change itself.

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> For a long period of the PC era, Emacs was the king of the 
>> text editors for technical users.
>
> Really?  Don't let a vi user hear you claim that.  In my (anecdotal)
> experience, even in software research environments the number of vi
> users has at least equalled that of Emacs users.  And in software
> development I've seen even more vi use than in research.  I still do.

Read again what I wrote. There is no claim there about the number of
users Emacs had.

[snip]

> Behind or ahead, ahead or behind...  It's _not_ a popularity contest.
> Dunno why this popularity thing keeps coming up here (and on
> help-gnu-emacs) from time to time.

Some popularity is indispensable, unless you are happy with Emacs as a
private project.

[snip]

>> Nowadays Emacs lacks behind on productivity features
>
> Haven't we all agreed that Emacs could be improved by adding some of
> those productivity features?  And that is so even though we have not
> agreed that Emacs is "behind" generally.  But just what are the
> "productivity features" that we might like to add to Emacs?
>
> There you go again, slip-sliding from (1) "productivity features",
> which no one argues against and with some Eclipse features serving as
> oft-cited examples, to (2) the idea that the Emacs default key
> bindings need to be those that a newbie is already used to in other
> apps.

I didn't propose (2) as a must-have. I think that dismissing the
proposal arguing that "newbies keep coming" and "there is no proof of
people giving up on Emacs because the keybindings" is hand-waving.

With the keybindings issue, either you change them or you make an effort
and adapt the documentation so the newbie gets the message: "yes, we
know this is different from what you know and may be a pain at first,
but hang on, it will pay back."

[snip]

>> stay alive as living fossils just because the efforts of
>> some enthusiasts.
>
> Not to worry.  Emacs will be digging up your and my remains and
> chuckling about them, long, long after we - enthusiasts or not - have
> turned from living fossils to dead ones.
>
> The fact that you think that Emacs is "going the way of...a living
> fossil" shows how far out into the ozone you've wandered.

Oh, this is funny. I hope that you are connected enough with reality to
admit that the percentage of programmers using Emacs is dwindling. I
claim something stronger: the absolute number of people using Emacs is
decreasing too. No, no proof other than my personal, anecdotical
experience. Nor you have proof about the contrary. Now, you assume that
Emacs will be alive and kicking forever (like the PDP-10 OS?) and act
consequently (or rather, don't act.) I assume that Emacs' future is not
promising, and try to improve it. What attitude is best for Emacs?

(This reminds me so much of the climate change affaire.)

[snip]

Re: Emacs learning curve

[Óscar Fuentes]

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

> (This reminds me so much of the climate change affaire.)

s/affaire/issue. Somehow English took only the dirty meaning of the
French word.

RE: Emacs learning curve

[Drew Adams]

> > (2) the idea that the Emacs default key bindings need to
> > be those that a newbie is already used to in other apps.
> 
> I didn't propose (2) as a must-have.

Great.  CUA bindings are already available optionally.  I thought you were
arguing that the default bindings needed to be changed.  Glad to see that's not
the case.

> I think that dismissing the proposal arguing that
> "newbies keep coming" and "there is no proof of
> people giving up on Emacs because the keybindings"
> is hand-waving.

Newbies have always kept coming.  And _some_ people have always given up on
Emacs because of its default key bindings.  Nothing new.  Complaining about
Emacs key bindings is as old as Emacs.  Just like complaints about Lisp's
plethora of silly parentheses are as old as Lisp.

There were (are?) people who argued that if Lisp would just change its default
syntax to get rid of all those parens it would attract more users - newbies who
just aren't used to such weirdness - and it might thus become "mainstream".  And
there have been (still are) alternative Lisp syntaxes without the parenthomania.

Throughout its history, some Emacs tourists have decided to stay - some of them
appreciating the bindings and some of them customizing the bindings.  (I'm in
both camps, BTW.)  Others have stayed for a while (short or long) and then left.

> With the keybindings issue, either you change them or you 
> make an effort and adapt the documentation so the newbie
> gets the message: "yes, we know this is different from what
> you know and may be a pain at first, but hang on, it will
> pay back."

I and others have made an effort to pass that message, both in the Emacs docs
and menus and on EmacsWiki.  Concrete suggestions welcome, I'm sure.

It is an important message to get across - you and I apparently agree on that.
But you can only bring an ass to the cool, clear water; you cannot make it
drink.  The message is apparently not getting across to some people - even here.

If everyone here were convinced that the Emacs key bindings "will pay you back",
then we wouldn't be having at least a part of this discussion.  Look through
this very thread for arguments as to why the current bindings are bad - and not
just because they are in conflict with wider usage.

Repeatedly, people have had to explain here the logic behind the set of bindings
- the reasons, beyond historical accident, for the keys chosen.  And after that
is pointed out some readers have indeed seen the light - there is some sense to
it.  But others still don't get it.

Emacs default key bindings will indeed "pay you back", by and large.  And I
agree that that is not obvious to a newbie.

And it is precisely the newbie whom we need to reach with that message.  It is
not the seasoned Emacs veteran who for whatever reason prefers to use CUA and
Viper.

Because the default bindings will pay you back, it does not necessarily help a
newbie not to teach that from the get-go but instead to provide, as the default
behavior, an emulation of what s?he's used to.

The message is that yes, there is a hurdle of learning something new, but that
effort will pay you back.

You don't teach someone to swim by keeping them in a rowboat.  No one is saying
to just throw newbies overboard with a hearty "Sink or swim!".  Doc, menus, and
such can help people learn.  But at some point they have to get wet or they will
just emulate forever.  Nothing wrong with that, but swimming is better than
pretending to swim.

> Oh, this is funny. I hope that you are connected enough with 
> reality to admit that the percentage of programmers using
> Emacs is dwindling.

Admit?  Truthfully, I have no idea whether that percentage is dwindling,
constant, or increasing.  You seem to be sure, but you also admit that you have
nothing to back up that belief. (?)

I'm not concerned with the percentage - that's the point.  Even if dwindling I
wouldn't be concerned.  I wish more people took advantage of Emacs like I wish
more people had better health care and fewer people were superstitious.  But I'm
not worried about Emacs being #1 in the usage hit parade.

Nobody is wishing unpopularity on Emacs.  The point is that it is not a
popularity _contest_.  Like the redwood tree, which does some things exceedingly
well in its own niche, Emacs has its place.  And it is unimportant whether that
place is #1 in the usage stats.

> I claim something stronger: the absolute number of people
> using Emacs is decreasing too.  No, no proof other than my
> personal, anecdotical experience. 
>
> Nor you have proof about the contrary.

Correct.  But I don't make the contrary claim!
This is not equal, parallel.

I make no claim about either the relative or the absolute numbers of Emacs
users.  You've made strong claims for both.

You claim that there are 42 orange and electric-blue galaxies the size of
Tinkerbelle swarming around the Pope's nose right now!  And you admit that you
have no basis for claiming that.

And then you say that I have no proof to the contrary.  But - Newsflash! - I
never claimed that there were no such galaxies circling the Pontiff's nose.  I
don't know or care whether there are.  It is only you who are worried about that
particular papal, nasal crisis.

> Now, you assume that Emacs will be alive and kicking forever
> (like the PDP-10 OS?) and act consequently (or rather, don't
> act.)  I assume that Emacs' future is not promising, and try
> to improve it. What attitude is best for Emacs?

Oh please.  Save it.  We are all trying to improve Emacs.  Just because someone
doesn't buy your cry that the sky is falling does not mean that you have a
monopoly on action or commitment or that the nonbeliever is complacent and lazy.

And BTW, thinking that the future is promising is not necessarily a hindrance to
effort or progress.

> (This reminds me so much of the climate change issue.)

Sigh.  Next you'll be calling me a nazi.
Yes, and I kill baby seals too, when I can find them.

Please take off-list [Was: Emacs learning curve]

[Chong Yidong]

The signal to noise ratio in this and related threads is becoming
intolerable.

If anyone has a specific, concrete, and new suggestion, start a new
thread.  I emphasize the words "specific", "concrete", and "new".

For everyone else, let's please wrap up the lengthy discussions of
editor history, grand strategy, and the nature of the newbie.  Or, take
it off-list.

Thanks.

Re: Emacs learning curve

[Sean Sieger]

"Drew Adams" <drew.adams@oracle.com> writes:

    > > We've seen no _evidence_ about a supposed dearth of newbies
    > > coming to Emacs, in spite of repeated _claims_.  No
    > > Emacs-is-dying problem has been shown, so far.
    >
    > Of course it is very hard to show statistics for newbies.
    > OTOH, absence of proof does not indicate that the fact does
    > not exists.

    Can you say "Tooth Fairy"? "Santa Claus"?

    I won't mention other religious figures.

How about this.

First, remove cua-mode from the development trunk.

Second, make a new branch, say notepademacs-24 and include cua-mode in
it.

Third, watch that new branch, new developers and new users and
new productivity flourish.

Re: Emacs learning curve

[Tom]

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

> Of course it is very hard to show statistics for newbies. 

I tried to collect some real world data on the reasons why
newbies don't like Emacs, but the Stack Overflow admins closed
the question quickly, because they were afraid of a flame war. :)
(Though I didn't ask which tool was better.)

Anyway, here it is, some answers had made through before the 
question was closed:

http://stackoverflow.com/questions/3321392/for-what-reasons-you-dont-use-emacs

Re: Emacs learning curve

[Leo]

On 2010-07-23 20:12 +0100, Tom wrote:
> Óscar Fuentes <ofv <at> wanadoo.es> writes:
>
>> Of course it is very hard to show statistics for newbies. 
>
> I tried to collect some real world data on the reasons why
> newbies don't like Emacs, but the Stack Overflow admins closed
> the question quickly, because they were afraid of a flame war. :)
> (Though I didn't ask which tool was better.)
>
> Anyway, here it is, some answers had made through before the 
> question was closed:
>
> http://stackoverflow.com/questions/3321392/for-what-reasons-you-dont-use-emacs

Long discussion in emacs-devel has a pattern of stupidity. The longer
the discussion, the more likely inaction is the best action.

The data on SO shows the major barrier is functionality, reliably
working and superior features are what make people come to Emacs and
sadly Emacs just has so many to catch up. To borrow what Carsten said in
his google tech talk:

  "Org-mode does not offer a finished and closed solution; instead,
  org-mode facilitates a learning and development process."

That kind of thinking will be beneficial to Emacs development. Don't
limit but facilitate what users can do with Emacs i.e. if they want to
implement a "firefox" (hinting the failure of w3) for Emacs in elisp,
make it possible. Then, you will have many more people developing cool
apps for Emacs.

The recent proposal to use CUA and the like keys is just absurd. It
treats everybody like idiots, newbies and current Emacs users. There is
absolutely no evidence that all newbies want or are bothered by the 2 or
3 keys i.e. no evidence to go as far as to make it the default,
including fiddling about those [C-insert] keys.

I think a better way to address this issue of learning curve and
friendliness is to look at the tentative plan¹ for Emacs 24 and see
whether we can help with one thing or two so that the key developers can
focus on major features planned. Another area is to write some good
documents, tutorials (we need more and everywhere) and manuals for elisp
packages.

Leo



Footnotes: 
¹  http://repo.or.cz/w/emacs.git/blob/HEAD:/etc/TODO
-- 
Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp. -- Leo

Re: Emacs learning curve

[joakim]

Leo <sdl.web@gmail.com> writes:

> On 2010-07-23 20:12 +0100, Tom wrote:
>> Óscar Fuentes <ofv <at> wanadoo.es> writes:
>>
>>> Of course it is very hard to show statistics for newbies. 
>>
>> I tried to collect some real world data on the reasons why
>> newbies don't like Emacs, but the Stack Overflow admins closed
>> the question quickly, because they were afraid of a flame war. :)
>> (Though I didn't ask which tool was better.)
>>
>> Anyway, here it is, some answers had made through before the 
>> question was closed:
>>
>> http://stackoverflow.com/questions/3321392/for-what-reasons-you-dont-use-emacs
>
> Long discussion in emacs-devel has a pattern of stupidity. The longer
> the discussion, the more likely inaction is the best action.
>
> The data on SO shows the major barrier is functionality, reliably
> working and superior features are what make people come to Emacs and
> sadly Emacs just has so many to catch up. To borrow what Carsten said in
> his google tech talk:
>
>   "Org-mode does not offer a finished and closed solution; instead,
>   org-mode facilitates a learning and development process."
>
> That kind of thinking will be beneficial to Emacs development. Don't
> limit but facilitate what users can do with Emacs i.e. if they want to
> implement a "firefox" (hinting the failure of w3) for Emacs in elisp,
> make it possible. Then, you will have many more people developing cool
> apps for Emacs.
>
> The recent proposal to use CUA and the like keys is just absurd. It
> treats everybody like idiots, newbies and current Emacs users. There is
> absolutely no evidence that all newbies want or are bothered by the 2 or
> 3 keys i.e. no evidence to go as far as to make it the default,
> including fiddling about those [C-insert] keys.
>
> I think a better way to address this issue of learning curve and
> friendliness is to look at the tentative plan¹ for Emacs 24 and see
> whether we can help with one thing or two so that the key developers can
> focus on major features planned. Another area is to write some good
> documents, tutorials (we need more and everywhere) and manuals for elisp
> packages.

100% agreement. The TODO is very long, there is much to do.

> Leo
>
>
>
> Footnotes: 
> ¹  http://repo.or.cz/w/emacs.git/blob/HEAD:/etc/TODO-- 
> Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
> implementation of half of Common Lisp. -- Leo
>
-- 
Joakim Verona

Re: Emacs learning curve

[Wojciech Meyer]

Leo <sdl.web@gmail.com> writes:

> The recent proposal to use CUA and the like keys is just absurd. It
> treats everybody like idiots, newbies and current Emacs users. There is
> absolutely no evidence that all newbies want or are bothered by the 2 or
> 3 keys i.e. no evidence to go as far as to make it the default,
> including fiddling about those [C-insert] keys.

I think it has psychological meaning, saying, `if the standard keys are
so convoluted, how can I use whole power of *it*, I would need to spend
100+ years to use it'. I use happily S-insert for pasting most of time,
as it lies nearby arrows, for copying I use M-w (and yes there are
mistakes in other apps), but if I wanted I could easily switch to
C-insert (which BTW: is also situated near the arrows). I came from the
`CUA background' and at some point had those bindings co-notated in my
muscle memory. So either I am fast learning genius or the discussion
will not yield anything new. I am happy that C-x is a prefix key, and I
am happy that C-c is a prefix key as well, if it comes (as a trade-off)
with all the features (and how they are exposed) of Emacs.  To emphasise
I have been using Emacs for not that very long, and switched to it,
because I wanted, having at work visual studio 2001 to choose. It was
painful but worth.

That does not mean we should not work on user friendliness, that just
means that there would be a big price for CUA which personally I
wouldn't pay just for having two keys remapped.

As my conclusion, Amiga was a great computer before 94 (before it
collapsed), but her greatness didn't pair with marketing. To be clear
what I mean: Eclipse, Visual Studio is heavily advertised and sponsored
environment for developing main stream application, that's their success
not ours. Simple CUA support will never out-weight it. And do we want it
really?

Also, at my work almost everybody use either VIM or Emacs, and one
person Eclipse. One of them has changed to Emacs for convenience just
0.5 year ago, and he is fair user since, so there is no clear evidence
about lesser popularity, or difficulties catching up, it just depends on
the domain.

I believe also, who wants to be a hacker will be, no matter of
key-bindings, and the rest would anyway use the Notepad subset of Emacs.

> Leo

Wojciech

Re: Emacs learning curve

[Juanma Barranquero]

On Fri, Jul 23, 2010 at 18:02, Drew Adams <drew.adams@oracle.com> wrote:

> It was pointed out that Emacs, like Spanish, has a reason to exist even if it is
> not the most widespread language

Well, according to most sources Spanish is the second language
worldwide in number of native speakers (after mandarin).

> and it uses vocabulary and pronunciation that
> foreigners (who are admittedly more numerous than Emacs speakers) can sometimes
> find disconcerting.

Foreigners are disconcerted by the weirdest things... Spanish
pronunciation is simpler (far fewer phonemes) and much more regular
(systematic spelling) than English'.

    Juanma

RE: Emacs learning curve

[Drew Adams]

> > It was pointed out that Emacs, like Spanish, has a reason 
> > to exist even if it is not the most widespread language
> 
> Well, according to most sources Spanish is the second language
> worldwide in number of native speakers (after mandarin).

For "native" speakers, depending on what is meant by that, in one estimation
(second link below) you are correct: Spanish is second.  English is a close
third.  Mandarin is bigger than Spanish and English combined.

In a different estimation (first link below), however, Hindi/Urdu is second in
native speakers (Spanish 3rd, English 4th).

English is #2 in total speakers (50% more than Spanish).

http://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers

http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers

The first link also shows native speakers, and that estimation puts Hindi/Urdu
ahead of Spanish.  That underlines the fact that no one knows - these are only
estimates.

Interestingly (surprising to me, at least), there are more secondary speakers of
French than of English (and Spanish is #5 in secondary speakers).

> > and it uses vocabulary and pronunciation that
> > foreigners (who are admittedly more numerous than Emacs 
> > speakers) can sometimes find disconcerting.
> 
> Foreigners are disconcerted by the weirdest things... Spanish
> pronunciation is simpler (far fewer phonemes) and much more regular
> (systematic spelling) than English'.

Almost anything is simpler and much more regular than English.
Even Emacs.

Korean has an incredibly sensible and accurate alphabet.  Anyone can read Korean
out loud after a few minutes studying the alphabet (but of course without
necessarily having a clue what they are pronouncing).  And that alphabet was
designed once and for all back in the 1500s, if I'm not mistaken.  A good
example of the value of careful study and good design.

BTW, I heard on the radio the other day that they ("They" (TM)) have logged the
one-millionth word in English.  It was "Web 2.0", IIRC.  "Defriend" was also a
recent one.  By contrast, French was clocked at about 250,000 words.

Like sluts everywhere, English is not picky about what it picks up.  French is
picky (or it would like to be).  In English you can verb any noun.  And the
multitude of secondary English speakers represent a wealth of language
invention.  We say that English has "borrowed" here and there, but it's not
really borrowing. ;-)

Re: Emacs learning curve

[Juanma Barranquero]

On Fri, Jul 23, 2010 at 20:50, Drew Adams <drew.adams@oracle.com> wrote:

> Mandarin is bigger than Spanish and English combined.

Yes, though that's likely related to the fact that what Chinese
linguistics call dialects, indoeuropeists would call languages
(meaning that there are likely "mandarin speakers" whose native
language is as different as Portuguese is from Spanish).

> English is #2 in total speakers (50% more than Spanish).

Yes, of course.

> That underlines the fact that no one knows - these are only
> estimates.

Reading the Language Log has given me a healthy distrust of most
numbers quoted on linguistics claims in the internet or the press.

> Interestingly (surprising to me, at least), there are more secondary speakers of
> French than of English (and Spanish is #5 in secondary speakers).

Not surprising to me. French has long been considered a "language of
culture". Even in Spanish-speaking countries, French as a second
language was for a long time much more common than English (I should
know, I was never taught English).

> Almost anything is simpler and much more regular than English.
> Even Emacs.

True :-)

> And that alphabet was
> designed once and for all back in the 1500s, if I'm not mistaken.  A good
> example of the value of careful study and good design.

And a good example of politics; it wasn't official until ~1890 because
it gave the common people too much power.

> BTW, I heard on the radio the other day that they ("They" (TM)) have logged the
> one-millionth word in English.  It was "Web 2.0", IIRC.  "Defriend" was also a
> recent one.  By contrast, French was clocked at about 250,000 words.

I heartily recommend the Language Log posts about the "million word".

> Like sluts everywhere, English is not picky about what it picks up.  French is
> picky (or it would like to be).  In English you can verb any noun.

Calvin said it succinctly: "verbing weirds things".

(And, as everybody knows, if there's two things the anglo-saxon
culture should be remembered for, surely they are Shakespeare and
Calvin & Hobbes :-)

    Juanma

(OT) natural language speakers (was: Emacs learning curve)

[Drew Adams]

> > Interestingly (surprising to me, at least), there are more 
> > secondary speakers of French than of English (and Spanish
> > is #5 in secondary speakers).
> 
> Not surprising to me. French has long been considered a "language of
> culture". Even in Spanish-speaking countries, French as a second
> language was for a long time much more common than English (I should
> know, I was never taught English).

That part doesn't surprise me.  That intellectuals and rulers in Russia,
Romania, Rwanda, Rome, or Rochester learn French is neither surprising nor new.
A while ago most of (the ruling classes of) Europe spoke French on a fairly
regular basis.

What I'm guessing is that the current numbers have more to do with ex-colonies
than they have to do with "culture"-seeking upper classes and intelligentsia.
In particular, African colonies that have large populations.  Just an uninformed
guess, however.

Lemme see (...googles...).  This helps a bit, but not as much as I'd like:
http://en.wikipedia.org/wiki/French_language.  It does say: 

"A majority of the world's French-speaking population lives in Africa. According
to the 2007 report by the Organisation internationale de la Francophonie, an
estimated 115 million African people spread across 31 Francophone African
countries can speak French as either a first or a second language."

and

"Sub-Saharan Africa is the region where the French language is most likely to
expand, because of the expansion of education and rapid demographic growth."

> I heartily recommend the Language Log posts about the "million word".

Thank you.  Interesting.  This too was helpful in that regard:
http://en.wikipedia.org/wiki/Global_Language_Monitor
 
> Calvin said it succinctly: "verbing weirds things".

;-)

> (And, as everybody knows, if there's two things the anglo-saxon
> culture should be remembered for, surely they are Shakespeare and
> Calvin & Hobbes :-)

Some thing-counters would count that as 3 things.

Re: (OT) natural language speakers (was: Emacs learning curve)

[Juanma Barranquero]

On Fri, Jul 23, 2010 at 22:20, Drew Adams <drew.adams@oracle.com> wrote:

> "A majority of the world's French-speaking population lives in Africa. According
> to the 2007 report by the Organisation internationale de la Francophonie, an
> estimated 115 million African people spread across 31 Francophone African
> countries can speak French as either a first or a second language."

I hadn't thought of it. Interesting.

> Some thing-counters would count that as 3 things.

Nonsense. Calvin & Hobbes is *one* thing:

http://www.amazon.com/Complete-Calvin-Hobbes-v/dp/0740748475/ref=sr_1_1?ie=UTF8&s=books&qid=1279916727&sr=8-1

The heaviest book I've ever bought. Also the funniest  :-)

    Juanma

Re: Emacs learning curve

[Ivan Andrus]

On Jul 23, 2010, at 8:50 PM, Drew Adams wrote:

> Like sluts everywhere, English is not picky about what it picks up.  French is
> picky (or it would like to be).  In English you can verb any noun.  And the
> multitude of secondary English speakers represent a wealth of language
> invention.  We say that English has "borrowed" here and there, but it's not
> really borrowing. ;-)

English doesn't borrow from other languages. English follows other
languages down dark alleys, hits them over the head and goes through
their pockets for loose vocabulary.

-Ivan

Re: Emacs learning curve

[Lennart Borgman]

On Fri, Jul 23, 2010 at 4:41 PM, Tom <levelhalom@gmail.com> wrote:
> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>
>>
>> > That's why CUA-style editing should be made the consistent default, so Emacs
>> > works like all other modern application on KDE/Gnome/Windows, etc. and the
>> > current behavior should be provided as a compatibility mode for those who
>> > are accustomed to the old behavior.
>>
>> I might agree.  But as long as noone submits actual code to do that, it
>> won't happen.
>>
>
> Those against the idea say the main problem with CUA mode is it hijacks C-c
> and C-x which are the standard bindings in current Emacs and they are
> hardwired in lots of places.
>
> Let's say the newbie user who wants to copy with C-c/C-x/C-v don't want
> to use the bindings C-w and C-y.
>
> Is it technically possible to implement a mode which binds copy to C-c,
> cut to C-x, but before that it rebinds all C-x bindings to C-w and
> C-c bindings to C-y? It should do it dynamically, of course, so when a
> new buffer is opened with new bindings or a new minor mode is activated
> it should change the bindings on the fly.
>
> This way the newbie could also have a standard and consistent set of
> bindings, only the prefix keys would be different in newbie mode and
> veteran mode.


Yes, Emacs is a bit prepared to make this change. There are variable
named ctl-x-map (for C-x) and mode-specific-map (for C-c). See

   (info "(elisp) Prefix Keys")

I have not (yet) tried to rebind those variables to C-w and C-y but I
think that this can do what you suggest.

If this does not work then a good first step towards such a solution
would be to make this rebinding work.

Re: Emacs learning curve

[René Kyllingstad]

On Tue, Jul 13, 2010 at 7:59 AM, Drew Adams <drew.adams@oracle.com> wrote:
> We've seen no real demonstration in this thread that there is a dwindling
> interest in Emacs by users (which was the claim that started the thread), but I
> would be willing to guess that there is insufficient new blood in the Emacs
> development community.

At least in the extension packages there is new blood out there:

Tomohiro Matsuyamas auto-complete mode is really nice, super smooth
inline completion support, fast and beautiful with a complete manual
(though not in info format, but I'd easily volunteer to convert it if
it was up for inclusion in Emacs, I have a hacky version in info
format I'm using already):

    http://cx4a.org/software/auto-complete/

He has also written other coding support tools:

    http://cx4a.org/#Softwares

The collection of authors of Magit, a really nice support for git,
with a good info manual to boot:

http://philjackson.github.com/magit/

Python support is also really nice in Emacs, most of it by new blood
and not integrated into Emacs:

ropemacs, compiler supported support for showing docs, goto
definition, refactoring:

    http://rope.sourceforge.net/ropemacs.html

It is built on top of Pymacs by François Pinard, not really new blood I guess:

    http://pymacs.progiciels-bpi.ca/pymacs.html

According to that page Pymacs was once suggested for inclusion, but he
never heard back. I'm guessing it needs some person to guide it
through the process. François intented it to be used to extend Emacs
using Python, which is of course a controversial goal, but in the
meantime it's really useful just to provide Python development support
in Emacs.

Taesoo Kim wrote pylookup, for looking up docs for the standard python
library in a browser, with completion in Emacs:

    http://taesoo.org/Opensource/Pylookup

Stephen Bach wrote Lusty Explorer which provides replacements for
find-file and switch-buffer with:

   - a fuzzy matching implementation
   - showing completion candidates in columns in a buffer instead of
in a jumble in the minibuffer (I find this much nicer when there are
many completion candidates)

    http://www.emacswiki.org/emacs/LustyExplorer

Martin Svenson wrote darkroom mode, which is the start of distraction
free mode for creative writing:

     http://www.martyn.se/code/emacs/darkroom-mode/

Julien Danjou wrote rainbow mode to fontify a color specification by
giving it that background color and changing foreground to white or
black, really nice, would be nice to have in Emacs:

    http://julien.danjou.info/rainbow-mode.html

Some of these are experimenting with UI and different ways of
operating, so they're not necessarily ready for inclusion into a
coherent Emacs, but having them in the Emacs Package manager would at
least make the installation instructions shorter and easier.


-- René

Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > No, I'm not missing the point at all. Whoever chose the terms
 > split-window-horizontally and split-window-vertically did a suboptimal
 > job, because they mean different things to different people, and using
 > ambiguous terms or expressions must be avoided. The fact that this
 > sub-topic arised is proof of the problematic nature of those terms.

I have to side with Drew here.  The names are not ambiguous in
English, at least not to native speakers of my dialect interpreting
the hyphenated symbols as English phrases.  The problem is that even
those who speak my dialect may choose to interpret them in other ways,
because of the various odd things that happen in naming.  Probably the
most frequent source of confusion is glossing the symbol name as
"windows arrayed horizontally" (ie, what Drew referred to as the
result of the command).  I feel the pull of that interpretation
myself, even though I can't do an up-down inversion and get myself to
interpret the results of "split window horizontally" as a horizontal
array of windows.  (Sorry about that contuse mass of words, but
precision is necessary here.)

 > And usage of down/up on Emacs (as for scrolling) contradicts current
 > stablished practice. Yes, there is a reasoning for doing what Emacs
 > does, but the issue is that it is contrary to the expectations of almost
 > anybody who learned to use computers on the last 20 years.
 > 
 > Terms must convey meaning to users, not confuse them.

Ah, but *which* users?  Note that a natural vocabulary for new and/or
non-programmer users is a picture of the result.  A sensible way to
handle this problem would be to have an icon like "[][]" next to the
English-ized function name "Split selected window vertically" in the
menus, and a large version of the icon for use in toolbars.  (It
probably would almost never be used in the top-level toolbar, but I
can imagine a window-configuration-mode with a toolbar containing such
icons.)

OTOH, changing the terms used by long-time users would cause great
confusion and annoyance.  I don't think you can win this argument if
you target the names of commands.  It would be much easier to get
support if you create such a pictorial vocabulary for use by new users
and non-programmers.  Bonus points for making it possible to create a
"keyboard macro" using only the mouse, translate it to Lisp, and
associate the pictures with the appropriate Lisp commands.  And of
course much of the relevant vocabulary will already be present in
collections of icons provided by GNOME et al.

Re: Emacs learning curve

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snipped text where I mostly agree]

> OTOH, changing the terms used by long-time users would cause great
> confusion and annoyance.  I don't think you can win this argument if
> you target the names of commands.

I think it is more reasonable to add alias, perhaps make some commands
non-interactive and add new ones with the "new" terms, and replace all
references on the Emacs manual (not the Elisp manual) to use the new
terms.

I don't see why old timers would have a problem with this. After all, if
we expect from every newcomer to learn Emacs-ish, we can expect from the
veterans to learn that Paste means the same as Yank (in case they still
don't know.) Sure, there are technical details, none hard, although
maybe a bit controversial... Oh, wait!

> It would be much easier to get support if you create such a pictorial
> vocabulary for use by new users and non-programmers.  Bonus points for
> making it possible to create a "keyboard macro" using only the mouse,
> translate it to Lisp, and associate the pictures with the appropriate
> Lisp commands.  And of course much of the relevant vocabulary will
> already be present in collections of icons provided by GNOME et al.

Not really, the long term investment should be to teach modern terms to
Emacs, instead of insisting on forcing every newcomer to learn the Emacs
terms.

Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > I think it is more reasonable to add alias, perhaps make some commands
 > non-interactive and add new ones with the "new" terms, and replace all
 > references on the Emacs manual (not the Elisp manual) to use the new
 > terms.

Well, we already have some of that (cf the `next-line' command vs. the
`forward-line' function), but I can't say I'm a big fan of it even as
limited as it is.  It also has the major huge defect from your point
of view that it enables the COFs ("cranky old fart") to continue
coding in traditional Emacs LISP, so you have the worst of both
worlds: good code written in the traditional dialect which the
newcomers have difficulty reading, and code of really ambiguous
practicality (ie, CRAP) written by newcomers in the newfangled dialect
(remember, in current LISP most commands that have very similar
functionality to separate API functions are duplicated in this way
because they have have DWIM-ish aspects that make them inappropriate
for use in programs).

 > I don't see why old timers would have a problem with this. After
 > all, if we expect from every newcomer to learn Emacs-ish,

As Drew points out, we don't have to connect Emacs-ish to LISP naming,
though.  Most newcomers are users who learn keybindings or discover
commands via the menus, and don't program or use LISP command names at
all (they refer to commands by their bindings, not by their names).
Most new programmers among those new users actually use macros for
almost all of their programming.  Most new e-LISP programmers among
those new programmers use a very small fraction of all Emacs commands.
The small fraction (5%? 1%?) of all new users who actually go on to
program modes etc will mostly be using existing code as a model for
the arcane stuff.

 > we can expect from the veterans to learn that Paste means the same
 > as Yank (in case they still don't know.)

And how do you explain to newcomers why "Paste" is on the C-y key?
Currently most one-letter control chords have mnemonic names (f =
forward, p = previous, y = yank, etc).

Also, to me at least, "paste" does not mean the same thing as "yank".
Yank is an operation that communicates between the Emacs kill ring and
an Emacs buffer.  Paste is an operation that communicates between a
system data store (in my case, either the X PRIMARY selection or the
Mac clipboard) and an Emacs buffer.  The semantics are therefore
subtly different, and in fact this is valuable to me because most of
the stuff on the system clipboard is useless to my Emacs work, and
similarly almost nothing on my Emacs kill ring is useful outside of
Emacs.

 > Sure, there are technical details, none hard, although maybe a bit
 > controversial... Oh, wait!

Oh, wait! is right.  Many people have the old versions embedded in
private modes, additional functions, skeletal library templates, etc,
both in use and as quoted boilerplate for inserting into new code.
Not to mention people who are using older versions with some
backported code, as well as forked projects.  While none of these are
a consideration for Emacs as such, if those users or projects abandon
work on Emacs or related projects, it will be a loss to Emacs.
Balanced by what gain?  I don't really see much gain; people who use
and program Emacsen are a special breed, and I don't think it's the
particular LISP dialect that puts up the largest hurdles to newcomers.

 > > It would be much easier to get support if you create such a pictorial
 > > vocabulary for use by new users and non-programmers.  Bonus points for
 > > making it possible to create a "keyboard macro" using only the mouse,
 > > translate it to Lisp, and associate the pictures with the appropriate
 > > Lisp commands.  And of course much of the relevant vocabulary will
 > > already be present in collections of icons provided by GNOME et al.
 > 
 > Not really, the long term investment should be to teach modern terms to
 > Emacs, instead of insisting on forcing every newcomer to learn the Emacs
 > terms.

Please reread what I wrote.  My point *is* to teach Emacs a modern
vocabulary.  However, the one I propose doesn't have the defects I
point out for changing LISP above, because it's used in a completely
different context that does not conflict with historical LISP
definitions.

Re: Emacs learning curve

[Tom]

Óscar Fuentes <ofv <at> wanadoo.es> writes:
> 
> Not really, the long term investment should be to teach modern terms to
> Emacs, instead of insisting on forcing every newcomer to learn the Emacs
> terms.
> 

Exactly.

Most of the time when I tell people about Emacs they try it and they say
it's too alien and completion for popular languages (Java, C#) is much
better in other tools (Eclipse, Visual Studio, etc).

So in order to attract more new blood to Emacs there are two possible
ways:

1. Do something which people care about much better than other tools.
Completion comes to mind first, it should be very very good and it should
work out of the box without any addition configuration.

Due to the limited development resources for Emacs (I don't know how
many paid developers work on it, but I guess not many) it's not a 
realistic expectation.


2. The other way is to make Emacs more accessible to newbies. Basic things
should work out of the box as they work in other applications (e.g.
why should one use a different paste key just in emacs when C-v works fine
everywhere else?).

Ease of entry should be the main target, because more users means more
hackers too (some of them will come up with new ideas and contribute 
code), and more hackers means more resources for development which helps
catching up with other editors in features which people consider basic
in these days (e.g excellent completion out of the box).

Re: Emacs learning curve

[Stephen J. Turnbull]

Tom writes:

 > Ease of entry should be the main target, because more users means more
 > hackers too

You're ignoring the fact that some kinds of new users are far more
likely to convert to Emacs hackers.  Specifically, the kind of people
who don't pay too much attention to "ease of use" anyway, but rather
head straight for the workbench and grab a power grinder to smooth out
the nicks and burrs in their own user experience.

I'm not saying that we shouldn't target ease of use or conformance to
convention (more than we currently do).  Just that I don't think "more
users -> more hackers" is a good reason for it.

Re: Emacs learning curve

[Tom]

Stephen J. Turnbull <stephen <at> xemacs.org> writes:
> 
> You're ignoring the fact that some kinds of new users are far more
> likely to convert to Emacs hackers.  Specifically, the kind of people
> who don't pay too much attention to "ease of use" anyway, but rather
> head straight for the workbench and grab a power grinder to smooth out
> the nicks and burrs in their own user experience.
> 

Yes, and there are other kind of hackers how take a look at
Emacs and say why should I bother with it if it's so alien? I'll
create some Eclipse extension instead, since the Eclipse UI is
much friendlier.

I've read more than once in various places that Eclipse plugin
development is quite complicated. On the other hand I have
experience with extending Emacs and I know rapid prototyping in
Emacs Lisp is quite a pleasant experience (once you've learned
Emacs Lisp, that is).

Creating an entrance barrier by keeping the default Emacs
UI (keys, etc.) different than than ones people are used to in
popular systems turns away lots of potential developers who could
be very useful for Emacs once they get to know it better and get
the hang of it.


So yes, you are right. The current UI won't keep the very
determined hackers away, but in my experience the question most 
new users (and
most new hackers) ask when encountering Emacs is: "Why should I
bother with it if it's so alien?"

Since we don't have a killer feature which would attract new
users like perfect code assist (context aware completion, instant
display of documentation of elements, live indication of syntax
errors, etc.) out of the box with near-zero configuration, we
have to at least lower the barrier of entry, so users don't
encounter unfamiliar things right at the first steps (copy/paste
on different keys, etc.) which in my experience drives most of
them away.

Re: Emacs learning curve

[Stephen J. Turnbull]

Tom writes:

 > So yes, you are right. The current UI won't keep the very
 > determined hackers away, but in my experience the question most new
 > users (and most new hackers) ask when encountering Emacs is: "Why
 > should I bother with it if it's so alien?"

My point is that it's not a question of determination.  It's that
users who think in terms of "alien" and "bother" won't convert to
Emacs hackers anyway, whether or not they are competent programmers.
They focus on other goals, and if Emacs were natural and effortless
for them, they would simply forget it, not invest the saved effort in
improving it.

Sure, there are reasons to support those users.  "They will become
Emacs hackers" simply isn't one of them.

Re: Emacs learning curve

[Tom]

Stephen J. Turnbull <turnbull <at> sk.tsukuba.ac.jp> writes:
> 
> My point is that it's not a question of determination.  It's that
> users who think in terms of "alien" and "bother" won't convert to
> Emacs hackers anyway, whether or not they are competent programmers.
> They focus on other goals, and if Emacs were natural and effortless
> for them, they would simply forget it, not invest the saved effort in
> improving it.
> 
> Sure, there are reasons to support those users.  "They will become
> Emacs hackers" simply isn't one of them.

I disagree. A small percent of new users always turns into hackers and the 
more users you can attract the more hackers you can get.

It's not about effortlessness, only making the road a bit easier to walk.

Re: Emacs learning curve

[immanuel litzroth]

> So yes, you are right. The current UI won't keep the very
> determined hackers away, but in my experience the question most
> new users (and
> most new hackers) ask when encountering Emacs is: "Why should I
> bother with it if it's so alien?"
* It supports an order of magnitude more languages that *any* other program
out there.
* It runs on more operating systems than most other programs.
* In a pinch it will run fine over a limited bandwith connection.
* It's quite easy to script repetetive tasks in it especially when
they involve manipulation
of text. It's very powerfull once you get under the hood.
* There's a developer community that has usually already written what
is just a vague
idea in your mind.
* If you're happy with what you have now you shouldn't bother
changing, but the alienness
shouldn't scare you.

Are some arguments you might use if for some weird reason you want to
spend the next
weeks answering questions about emacs, elisp, .emacs(.el) etc. I
personally always advise
using Visual XX on windows and also give them the email of the
resident experts :-)
Immanuel

Re: Emacs learning curve

[Eric M. Ludlam]

On 07/13/2010 04:32 AM, Tom wrote:
> Since we don't have a killer feature which would attract new
> users like perfect code assist (context aware completion, instant
> display of documentation of elements, live indication of syntax
> errors, etc.) out of the box with near-zero configuration, we

Enabling the CEDET code completion stuff "by default" would come pretty 
close.  I know lots of folks complain about CEDET being hard to figure 
out or configure.  On GNU systems with projects written in Automake, 
however, it self configures most of the complicated stuff, and will do a 
good job with completion in C and C++ and a few other languages.

CEDET is also now a part of Emacs.  Why not configure CEDET to be on, 
use it for a while, and instead of turning it off because of some glitch 
you don't like, fix the little things that confused you or were hard. 
That would take less time than reading this thread.

One of the things I was most surprised by was that when CEDET was 
integrated into Emacs, only 2 people tried it and reported anything from 
this list.  I fixed those things too.  Now this list is posting things 
that effectively pretend CEDET doesn't exist.  What's up with that?

Eric

Re: Emacs learning curve

[David Kastrup]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> One of the things I was most surprised by was that when CEDET was
> integrated into Emacs, only 2 people tried it and reported anything
> from this list.  I fixed those things too.  Now this list is posting
> things that effectively pretend CEDET doesn't exist.  What's up with
> that?

For the effects discussed in this thread, it does not exist.  It does
much less (if at all) to make two existing separate modes more similar
than, say, cc-mode does.

It may be that this situation will be different in 10 years from now,
but I don't see the way to there.  Cedet makes it somewhat easier, as
far as I can discern, to help a programmer with creating his own
completely idiosyncratic mode with complex functionality.

It helps to manage complexity for the mode programmer, not unify
behavior for the user.

If I am wrong, so much the better, but unless everybody else _knows_ I
am wrong, the consequences will be about the same.

-- 
David Kastrup

Re: Emacs learning curve

[joakim]

David Kastrup <dak@gnu.org> writes:

> "Eric M. Ludlam" <eric@siege-engine.com> writes:
>
>> One of the things I was most surprised by was that when CEDET was
>> integrated into Emacs, only 2 people tried it and reported anything
>> from this list.  I fixed those things too.  Now this list is posting
>> things that effectively pretend CEDET doesn't exist.  What's up with
>> that?
>
> For the effects discussed in this thread, it does not exist.  It does
> much less (if at all) to make two existing separate modes more similar
> than, say, cc-mode does.
>
> It may be that this situation will be different in 10 years from now,
> but I don't see the way to there.  Cedet makes it somewhat easier, as
> far as I can discern, to help a programmer with creating his own
> completely idiosyncratic mode with complex functionality.
>
> It helps to manage complexity for the mode programmer, not unify
> behavior for the user.
>
> If I am wrong, so much the better, but unless everybody else _knows_ I
> am wrong, the consequences will be about the same.

You are wrong, but you are also right that there seems to be a lack of
understanding amongst mode coders that cedet not only provides a common
infrastructure, but also a common user interface for many things. I
think it would help if cedet was more used within emacs, and also if
more cedet clients were incorporated in Emacs, such as ECB.

-- 
Joakim Verona

Re: Emacs learning curve

[David Kastrup]

joakim@verona.se writes:

> David Kastrup <dak@gnu.org> writes:
>
>> "Eric M. Ludlam" <eric@siege-engine.com> writes:
>>
>>> One of the things I was most surprised by was that when CEDET was
>>> integrated into Emacs, only 2 people tried it and reported anything
>>> from this list.  I fixed those things too.  Now this list is posting
>>> things that effectively pretend CEDET doesn't exist.  What's up with
>>> that?
>>
>> For the effects discussed in this thread, it does not exist.  It does
>> much less (if at all) to make two existing separate modes more similar
>> than, say, cc-mode does.
>>
>> It may be that this situation will be different in 10 years from now,
>> but I don't see the way to there.  Cedet makes it somewhat easier, as
>> far as I can discern, to help a programmer with creating his own
>> completely idiosyncratic mode with complex functionality.
>>
>> It helps to manage complexity for the mode programmer, not unify
>> behavior for the user.
>>
>> If I am wrong, so much the better, but unless everybody else _knows_ I
>> am wrong, the consequences will be about the same.
>
> You are wrong, but you are also right that there seems to be a lack of
> understanding amongst mode coders that cedet not only provides a
> common infrastructure, but also a common user interface for many
> things. I think it would help if cedet was more used within emacs, and
> also if more cedet clients were incorporated in Emacs, such as ECB.

Well, cedet has no discernible documentation.  It has no info file.
semantics has an info file.  It talks about bovine and wisent parser
generators.  It mentions their source files.  They don't exist.  Wisent
files presumably have an extension of .wy.  The semantics documentation
claims that there is a mode for creating them.  Opening a file with .wy
extension puts it in fundamental mode.  There are no interactive
commands autoloaded starting with wisent- or bovin that would have
anything to do with writing language support using
Cedet/semantics/whatever.

If there is any usable infrastructure or documentation for creating a
mode/grammar with the current Emacs distribution, it is rather well
hidden.

In the current state of Cedet as delivered with Emacs, it is not usable
for creating new parsers for a language of your choice.  You can use the
existing parsers, but you'll have a hard time finding out what they do,
and even just what languages are supported.

Completely useless as a tool for a developer interested in developing
support for a language not already supported.

-- 
David Kastrup

Re: Emacs learning curve

[joakim]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> "Eric M. Ludlam" <eric@siege-engine.com> writes:
>>>
>>>> One of the things I was most surprised by was that when CEDET was
>>>> integrated into Emacs, only 2 people tried it and reported anything
>>>> from this list.  I fixed those things too.  Now this list is posting
>>>> things that effectively pretend CEDET doesn't exist.  What's up with
>>>> that?
>>>
>>> For the effects discussed in this thread, it does not exist.  It does
>>> much less (if at all) to make two existing separate modes more similar
>>> than, say, cc-mode does.
>>>
>>> It may be that this situation will be different in 10 years from now,
>>> but I don't see the way to there.  Cedet makes it somewhat easier, as
>>> far as I can discern, to help a programmer with creating his own
>>> completely idiosyncratic mode with complex functionality.
>>>
>>> It helps to manage complexity for the mode programmer, not unify
>>> behavior for the user.
>>>
>>> If I am wrong, so much the better, but unless everybody else _knows_ I
>>> am wrong, the consequences will be about the same.
>>
>> You are wrong, but you are also right that there seems to be a lack of
>> understanding amongst mode coders that cedet not only provides a
>> common infrastructure, but also a common user interface for many
>> things. I think it would help if cedet was more used within emacs, and
>> also if more cedet clients were incorporated in Emacs, such as ECB.
>
> Well, cedet has no discernible documentation.  It has no info file.
> semantics has an info file.  It talks about bovine and wisent parser
> generators.  It mentions their source files.  They don't exist.  Wisent
> files presumably have an extension of .wy.  The semantics documentation
> claims that there is a mode for creating them.  Opening a file with .wy
> extension puts it in fundamental mode.  There are no interactive
> commands autoloaded starting with wisent- or bovin that would have
> anything to do with writing language support using
> Cedet/semantics/whatever.
>
> If there is any usable infrastructure or documentation for creating a
> mode/grammar with the current Emacs distribution, it is rather well
> hidden.
>
> In the current state of Cedet as delivered with Emacs, it is not usable
> for creating new parsers for a language of your choice.  You can use the
> existing parsers, but you'll have a hard time finding out what they do,
> and even just what languages are supported.

Thanks. Maybe I can help Eric with documentation then. 

> Completely useless as a tool for a developer interested in developing
> support for a language not already supported.

I did help write support for a language not already supported, so I find
this statement a bit harsh.

-- 
Joakim Verona

Re: Emacs learning curve

[Alex Ott]

Re all

joakim@verona.se  at "Tue, 13 Jul 2010 17:49:25 +0200" wrote:
 >> Well, cedet has no discernible documentation.  It has no info file.
 >> semantics has an info file.  It talks about bovine and wisent parser
 >> generators.  It mentions their source files.  They don't exist.  Wisent
 >> files presumably have an extension of .wy.  The semantics documentation
 >> claims that there is a mode for creating them.  Opening a file with .wy
 >> extension puts it in fundamental mode.  There are no interactive
 >> commands autoloaded starting with wisent- or bovin that would have
 >> anything to do with writing language support using
 >> Cedet/semantics/whatever.
 >>
 >> If there is any usable infrastructure or documentation for creating a
 >> mode/grammar with the current Emacs distribution, it is rather well
 >> hidden.
 >>
 >> In the current state of Cedet as delivered with Emacs, it is not usable
 >> for creating new parsers for a language of your choice.  You can use the
 >> existing parsers, but you'll have a hard time finding out what they do,
 >> and even just what languages are supported.

 j> Thanks. Maybe I can help Eric with documentation then. 

For example, you can use my article about CEDET as a base --
http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html
(http://alexott.net/en/writings/emacs-devenv/EmacsCedet.muse - source)

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/        http://alexott.net/
http://alexott-ru.blogspot.com/
Skype: alex.ott

Re: Emacs learning curve

[David Engster]

David Kastrup writes:
> Well, cedet has no discernible documentation.  It has no info file.
> semantics has an info file.  It talks about bovine and wisent parser
> generators.  It mentions their source files.  They don't exist.  Wisent
> files presumably have an extension of .wy.  The semantics documentation
> claims that there is a mode for creating them.  Opening a file with .wy
> extension puts it in fundamental mode.  There are no interactive
> commands autoloaded starting with wisent- or bovin that would have
> anything to do with writing language support using
> Cedet/semantics/whatever.

When the integration of CEDET was discussed, it was decided to leave the
grammar development upstream. See

http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054

People who want to extend CEDET should always use its CVS version. It
seems this fact is not reflected in the documentation.

-David

Re: Emacs learning curve

[David Kastrup]

David Engster <deng@randomsample.de> writes:

> David Kastrup writes:
>> Well, cedet has no discernible documentation.  It has no info file.
>> semantics has an info file.  It talks about bovine and wisent parser
>> generators.  It mentions their source files.  They don't exist.  Wisent
>> files presumably have an extension of .wy.  The semantics documentation
>> claims that there is a mode for creating them.  Opening a file with .wy
>> extension puts it in fundamental mode.  There are no interactive
>> commands autoloaded starting with wisent- or bovin that would have
>> anything to do with writing language support using
>> Cedet/semantics/whatever.
>
> When the integration of CEDET was discussed, it was decided to leave the
> grammar development upstream. See
>
> http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054
>
> People who want to extend CEDET should always use its CVS version.

This means that supporting new languages with CEDET means _extending_
CEDET, and extending CEDET is apparently not possible with the CEDET
extract included in Emacs.

Whatever happened to "the preferred form for modification"?

> It seems this fact is not reflected in the documentation.

Nor is it reflected in the beliefs of the people who state on-list that
since the time CEDET was "included" in Emacs distribution, it has become
inaccurate to state that Emacs does not come with a unified approach to
creating new language modes.

-- 
David Kastrup

Re: Emacs learning curve

[David Engster]

David Kastrup writes:
> David Engster <deng@randomsample.de> writes:
>
>> David Kastrup writes:
>>> Well, cedet has no discernible documentation.  It has no info file.
>>> semantics has an info file.  It talks about bovine and wisent parser
>>> generators.  It mentions their source files.  They don't exist.  Wisent
>>> files presumably have an extension of .wy.  The semantics documentation
>>> claims that there is a mode for creating them.  Opening a file with .wy
>>> extension puts it in fundamental mode.  There are no interactive
>>> commands autoloaded starting with wisent- or bovin that would have
>>> anything to do with writing language support using
>>> Cedet/semantics/whatever.
>>
>> When the integration of CEDET was discussed, it was decided to leave the
>> grammar development upstream. See
>>
>> http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054
>>
>> People who want to extend CEDET should always use its CVS version.
>
> This means that supporting new languages with CEDET means _extending_
> CEDET, and extending CEDET is apparently not possible with the CEDET
> extract included in Emacs. 

> Whatever happened to "the preferred form for modification"?

In short: yes, that is the current state of the CEDET merge.

Longer explanation, as far as I remember it:

It's not unusual for development of Emacs packages to happen primarily
in their own projects (org, Gnus). However, CEDET is a bit special in
this regard, because it has a pretty complicated build process, in which
for example the grammars are converted to Emacs Lisp code. The grammar
files are then not needed anymore. So a full CEDET merge would also
require to merge this build process, but that's a pretty big task, and
just getting a core CEDET into Emacs was difficult enough on its own. A
full CEDET merge would be desirable; maybe it is possible for Emacs24.

>> It seems this fact is not reflected in the documentation.
>
> Nor is it reflected in the beliefs of the people who state on-list that
> since the time CEDET was "included" in Emacs distribution, it has become
> inaccurate to state that Emacs does not come with a unified approach to
> creating new language modes.

As you know, a language mode consists of different things. For instance
font locking, indentation, accessing some kind of documentation, or
communication with an interpreter. CEDET doesn't really immediately have
much to do with those, although font locking could probably profit from
a semantic parser and semantic tags can also contain documentation;
indentation is entirely another beast, though.

I think all that was said was that CEDET can provide stuff like semantic
parsing, project support and template generation under a general
framework, so that other tools (like ECB) can use that information, and
therefore it might be possible to unify those areas of a language mode.

-David

Re: Emacs learning curve

[Stephen J. Turnbull]

David Engster writes:

 > As you know, a language mode consists of different things. For instance
 > font locking, indentation, accessing some kind of documentation, or
 > communication with an interpreter. CEDET doesn't really immediately have
 > much to do with those, although font locking could probably profit from
 > a semantic parser and semantic tags can also contain documentation;
 > indentation is entirely another beast, though.
 > 
 > I think all that was said was that CEDET can provide stuff like semantic
 > parsing, project support and template generation under a general
 > framework, so that other tools (like ECB) can use that information, and
 > therefore it might be possible to unify those areas of a language mode.

Maybe that's all that was intended to be said, but the requirement was
for a unifying framework *now*, and it was claimed that CEDET fits the
bill.  According to the description above, it does not.  Instead, it
adds yet another set of semantics for overlaying on a text buffer.  It
does not unify the existing sets (syntax highlighting, grinding, MMM
for mixed-language files, maybe others like project membership), and
it hasn't even been demonstrated that it *can*.

That is in no way a criticism of the CEDET package itself.  Just a
statement that in the current state it seems to be completely
independent of the stated requirement for a seamless integration of
all the different aspects of language modes, and a unified UI across
language modes.

Note that I won't be satisfied with a statement that CEDET "could" be
extended in those directions.  I see those possibilities, too, but
there's no concrete proposal on the table.  I also see a possibility
that a completely new unifying framework might be proposed, and then
CEDET would be require to adapt itself to that.  IMO, if CEDET wants
to claim to be part of the solution, it needs to make a proposal for
such extensions and how the other aspects of language processing
should be incorporated in the framework.  Otherwise, it's a great
feature for Emacs, but not a unifying framework.

I wouldn't be surprised if the above statement represents the general
feeling of developers, but I don't claim it does. ;-)

Re: Emacs learning curve

[Eric M. Ludlam]

On 07/13/2010 10:49 PM, Stephen J. Turnbull wrote:
> David Engster writes:
>
>   >  As you know, a language mode consists of different things. For instance
>   >  font locking, indentation, accessing some kind of documentation, or
>   >  communication with an interpreter. CEDET doesn't really immediately have
>   >  much to do with those, although font locking could probably profit from
>   >  a semantic parser and semantic tags can also contain documentation;
>   >  indentation is entirely another beast, though.
>   >
>   >  I think all that was said was that CEDET can provide stuff like semantic
>   >  parsing, project support and template generation under a general
>   >  framework, so that other tools (like ECB) can use that information, and
>   >  therefore it might be possible to unify those areas of a language mode.
>
> Maybe that's all that was intended to be said, but the requirement was
> for a unifying framework *now*, and it was claimed that CEDET fits the
> bill.  According to the description above, it does not.  Instead, it
> adds yet another set of semantics for overlaying on a text buffer.  It
> does not unify the existing sets (syntax highlighting, grinding, MMM
> for mixed-language files, maybe others like project membership), and
> it hasn't even been demonstrated that it *can*.

I feel the need to both agree and disagree.

I agree that CEDET is not a unifying force for *all* things a language 
mode may wish to do.

I had responded to a couple different assertions.  One was something 
David Kastrup wrote:

| The question is why the respective facilities are not part of the
| generic Emacs language support framework.  Support for every language
| has a completely disjoint set of features, keybindings, highlighting,
| and so on of wildly differing quality, design and usability.

My response was meant that CEDET is not a C/C++ only feature, but an 
infrastructure under which a mode can support code completion and the 
like.  CEDET doesn't tackle keybindings or font lock since Emacs already 
does that.  However, a suite of minor modes based on the infrastructure 
of CEDET can provide features (like code completion) which a mode author 
then does not need to implement themselves if a grammar is supplied. 
Thus, advanced major modes that try to solve some complex problems like 
code completion, compilation, or code generation could have a unified 
set of keybindings and behaviors for those features based on those minor 
modes.

Hopefully that is more clear.

A second thing I responded to was something Tom wrote:

| Since we don't have a killer feature which would attract new
| users like perfect code assist (context aware completion, instant
| display of documentation of elements, live indication of syntax
| errors, etc.) out of the box with near-zero configuration, we

to which this current thread branch originates.   The CEDET/Semantic 
tools can do these things such as code assist, display documentation 
(though you have to ask for it) and even live indication of some syntax 
errors.  (A feature that could use some help in CEDET.)

In theory, things like font-lock, or MMM mode features could work with 
the parsers CEDET/Semantic.  I've participated in discussions on these 
topics to try and solve them, but they are not solved, so I agree there 
is no quick fix there.

Eric

Re: Emacs learning curve

[David Engster]

Eric M. Ludlam writes:
> I had responded to a couple different assertions.  One was something
> David Kastrup wrote:
>
> | The question is why the respective facilities are not part of the
> | generic Emacs language support framework.  Support for every language
> | has a completely disjoint set of features, keybindings, highlighting,
> | and so on of wildly differing quality, design and usability.
>
> My response was meant that CEDET is not a C/C++ only feature, but an
> infrastructure under which a mode can support code completion and the
> like.  CEDET doesn't tackle keybindings or font lock since Emacs
> already does that.  However, a suite of minor modes based on the
> infrastructure of CEDET can provide features (like code completion)
> which a mode author then does not need to implement themselves if a
> grammar is supplied.

Maybe I can give a small example for this, though it's more of a
shameless plug.

I've extended the Minimap package to include information from the
Semantic parser. See the first screenshot at

http://www.emacswiki.org/emacs/MiniMap

You'll see on the left that certain areas have a dark gray background,
which correspond to Semantic tags. Those areas have an overlay in the
middle with their name, in the font lock color for the class
(function/variable/type).

The code which does that is maybe 20 lines and almost trivial. It should
work with every mode which is supported by CEDET.

All one needs to know to access Semantic information is in the "Semantic
Application Development" manual; I don't know this is included in Emacs,
though.

-David

Re: Emacs learning curve

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

> When the integration of CEDET was discussed, it was decided to leave the
> grammar development upstream. See
>
> http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054
>
> People who want to extend CEDET should always use its CVS version. It
> seems this fact is not reflected in the documentation.

We can include it in Emacs 24.  I believe Eric has some infrastructure
changes to CEDET under way; once that is done, we can do another big
synch to the version included in Emacs.

Re: Emacs learning curve

[Eric M. Ludlam]

On 07/13/2010 01:12 PM, Chong Yidong wrote:
> David Engster<deng@randomsample.de>  writes:
>
>> When the integration of CEDET was discussed, it was decided to leave the
>> grammar development upstream. See
>>
>> http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054
>>
>> People who want to extend CEDET should always use its CVS version. It
>> seems this fact is not reflected in the documentation.
>
> We can include it in Emacs 24.  I believe Eric has some infrastructure
> changes to CEDET under way; once that is done, we can do another big
> synch to the version included in Emacs.

Correct.  Lluis has volunteered to create a bzr repository that matches 
the naming convention in Emacs.  I think he is waiting for a help 
request from sourceforge to be finished.  We can then cross merge from 
CEDET CVS into the CEDET bzr repository and setup scripts to keep 
Emacs/bzr and CEDET/bzr in sync.  At least, that's how I understand the 
upcoming process.

I've still been focusing on CEDET as an external package for Emacs 23.1 
and earlier, just looking to wrap that up.  From some of the other 
responses, it sounds like getting the build environment for CEDET 
working in this environment will be a big task.

Eric

Re: Emacs learning curve

[joakim]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> On 07/13/2010 04:32 AM, Tom wrote:
>> Since we don't have a killer feature which would attract new
>> users like perfect code assist (context aware completion, instant
>> display of documentation of elements, live indication of syntax
>> errors, etc.) out of the box with near-zero configuration, we
>
> Enabling the CEDET code completion stuff "by default" would come
> pretty close.  I know lots of folks complain about CEDET being hard to
> figure out or configure.  On GNU systems with projects written in
> Automake, however, it self configures most of the complicated stuff,
> and will do a good job with completion in C and C++ and a few other
> languages.
>
> CEDET is also now a part of Emacs.  Why not configure CEDET to be on,
> use it for a while, and instead of turning it off because of some
> glitch you don't like, fix the little things that confused you or were
> hard. That would take less time than reading this thread.
>
> One of the things I was most surprised by was that when CEDET was
> integrated into Emacs, only 2 people tried it and reported anything
> from this list.  I fixed those things too.  Now this list is posting
> things that effectively pretend CEDET doesn't exist.  What's up with
> that?

I too find this annoying. CEDET is the infrastructure we have. Now we
should polish it a bit so its easier to set up.

> Eric
-- 
Joakim Verona

Re: Emacs learning curve

[Tom]

Eric M. Ludlam <eric <at> siege-engine.com> writes:
> 
> CEDET is also now a part of Emacs.  Why not configure CEDET to be on, 
> use it for a while, and instead of turning it off because of some glitch 
> you don't like, fix the little things that confused you or were hard. 
> That would take less time than reading this thread.
>

That would be a step in the right direction. Lots of stuff should be
preconfigured and made as newbie friendly as possible to attract more
users (and consequently more developers).

Here's a video demo of one of the competitors language support  to which
new users compare their first Emacs experience:

http://www.jetbrains.com/idea/training/demos.html


Even if this level of integration is not attainable given the current
developer resources, something like this should be offered and configured 
by default, so the user has the feeling he gets at least a partially
comparable feature in the default install.

CEDET discoverability (was: Emacs learning curve)

[Óscar Fuentes]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

[snip]

> One of the things I was most surprised by was that when CEDET was
> integrated into Emacs, only 2 people tried it and reported anything
> from this list.  I fixed those things too.  Now this list is posting
> things that effectively pretend CEDET doesn't exist.  What's up with
> that?

Where on the Emacs documentation can I learn about CEDET? On an Emacs
compiled a few days ago, I did

M-h i S cedet [ENTER]

and it turned nothing. M-x cedet [TAB] returns nothing too.

I tried CEDET several years ago with my C++ projects and it was of no
use (slow, highly inaccurate, slowed down text editing.) I'm sure things
have improved a lot since that experience (the CEDET docs mentioned that
its C++ support was very rough) and I'll like to try again. Guess that I
must go to the CEDET website.

Re: CEDET discoverability (was: Emacs learning curve)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 13 Jul 2010 17:44:00 +0200
> Cc: "Eric M. Ludlam" <eric@siege-engine.com>
> 
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> Where on the Emacs documentation can I learn about CEDET? On an Emacs
> compiled a few days ago, I did
> 
> M-h i S cedet [ENTER]
> 
> and it turned nothing. M-x cedet [TAB] returns nothing too.

Try

   C-h i m ede RET
   C-h i m semantic RET

Re: CEDET discoverability

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Tue, 13 Jul 2010 17:44:00 +0200
>> Cc: "Eric M. Ludlam" <eric@siege-engine.com>
>> 
>> "Eric M. Ludlam" <eric@siege-engine.com> writes:
>> 
>> Where on the Emacs documentation can I learn about CEDET? On an Emacs
>> compiled a few days ago, I did
>> 
>> M-h i S cedet [ENTER]
>> 
>> and it turned nothing. M-x cedet [TAB] returns nothing too.
>
> Try
>
>    C-h i m ede RET
>    C-h i m semantic RET

semantic documentation consists of a lot of buzzwords, and some
descriptions of its organization (not matching what is installed in
Emacs), but describes pretty much _nothing_ you could actually call or
use in Emacs.

ede appears more or less like a Makefile/make infrastructure independent
from language mode support.

-- 
David Kastrup

Re: CEDET discoverability

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> semantic documentation consists of a lot of buzzwords, and some
> descriptions of its organization (not matching what is installed in
> Emacs), but describes pretty much _nothing_ you could actually call or
> use in Emacs.

See the chapter "Using Semantic" in the manual, which, appropriately
enough, explains how to use Semantic.

Re: CEDET discoverability

[Eric M. Ludlam]

On 07/13/2010 01:14 PM, Chong Yidong wrote:
> David Kastrup<dak@gnu.org>  writes:
>
>> semantic documentation consists of a lot of buzzwords, and some
>> descriptions of its organization (not matching what is installed in
>> Emacs), but describes pretty much _nothing_ you could actually call or
>> use in Emacs.
>
> See the chapter "Using Semantic" in the manual, which, appropriately
> enough, explains how to use Semantic.

CEDET is a term coined to be a sourceforge project name that contains 
several independent tools which I maintain as a group.

There is a cedet info manual that describes this and some basic setup, 
but perhaps it is not in Emacs?  In any case it would be inaccurate, as 
the upstream CEDET install "does stuff" to get everything enabled, 
whereas in Emacs some of that needs to be turned on individually.

I haven't updated to Emacs 23.2 or the trunk yet beyond what I need for 
merging code from Emacs for the upcoming structural conversion.  It 
sounds like something I need to do to help answer these kinds of questions.

Eric

Re: CEDET discoverability

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> semantic documentation consists of a lot of buzzwords, and some
>> descriptions of its organization (not matching what is installed in
>> Emacs), but describes pretty much _nothing_ you could actually call or
>> use in Emacs.
>
> See the chapter "Using Semantic" in the manual, which, appropriately
> enough, explains how to use Semantic.

It tells you how to turn it on and off.  It does not tell you how to
call or use its functions for supporting further modes.

-- 
David Kastrup

Re: CEDET discoverability

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>>> semantic documentation consists of a lot of buzzwords, and some
>>> descriptions of its organization (not matching what is installed in
>>> Emacs), but describes pretty much _nothing_ you could actually call or
>>> use in Emacs.
>>
>> See the chapter "Using Semantic" in the manual, which, appropriately
>> enough, explains how to use Semantic.
>
> It tells you how to turn it on and off.  It does not tell you how to
> call or use its functions for supporting further modes.

That's what the subnodes are for.  See "Semantic mode user commands" for
a list of commands enabled by Semantic mode.  As explained in the node
"Semantic mode", many additional features can be enabled, and these are
explained in their own subnodes (SemanticDB, Idle Scheduler, Analyzer,
Speedbar, ...).

Do you have something specific in mind about what is missing?

Re: CEDET discoverability

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>>> semantic documentation consists of a lot of buzzwords, and some
>>>> descriptions of its organization (not matching what is installed in
>>>> Emacs), but describes pretty much _nothing_ you could actually call or
>>>> use in Emacs.
>>>
>>> See the chapter "Using Semantic" in the manual, which, appropriately
>>> enough, explains how to use Semantic.
>>
>> It tells you how to turn it on and off.  It does not tell you how to
>> call or use its functions for supporting further modes.
>
> That's what the subnodes are for.  See "Semantic mode user commands" for
> a list of commands enabled by Semantic mode.  As explained in the node
> "Semantic mode", many additional features can be enabled, and these are
> explained in their own subnodes (SemanticDB, Idle Scheduler, Analyzer,
> Speedbar, ...).

Apart from the Speedbar, those are mostly not user interfaces, but
rather explanations of how to deal with sideeffects, and a list of
command names which you might or might not want to bind to keys for a
given user experience.

A user is not interested in command names.  She is interested in key
names, mouse menus, menu entries.  Also she is not interested in reading
a lot of generic buzzphrases, but rather actual examples of what a
command does.

Let us take an example:

    File: semantic,  Node: Smart Jump,  Next: Analyzer Debug,  Prev: Smart Summary,  Up: Analyzer

    2.4.3 Smart Jump
    ----------------

    The Semantic Analyzer can be used to jump directly to the definition
    for a code symbol.

     -- Command: semantic-ia-fast-jump pos
         Jump to the definition for the symbol at POS.  Called
         interactively, POS defaults to point.

     -- Function: semantic-ia-fast-mouse-jump event
         Jump to the definition for the symbol at the position of the mouse
         event EVENT.  This command is meant to be bound to a mouse
         command, like this:

              (global-set-key '[(S-mouse-1)] semantic-ia-fast-mouse-jump)

       These commands are often more accurate than than the `find-tag'
    command (*note Tags: (emacs)Tags.), because the Semantic Analyzer is
    context-sensitive.

       You can also use `C-c , j' (`semantic-complete-jump-local') and `C-c
    , J' (`semantic-complete-jump') to navigate tags.  *Note Semantic mode
    user commands::.  Those commands do not make use of the Semantic
    Analyzer.

So the only actually _existing_ keybindings we find in the
Analyzer/Smart Jump subnode tells us about keybindings that don't
actually use the analyzer.

> Do you have something specific in mind about what is missing?

There is so much in there that does not seem applicable without
reverting to Elisp programming that the few things that would likely
_be_ relevant are hard to find among the rest.

The manual needs to funnel out everything that is not at user interface
level.

-- 
David Kastrup

Re: CEDET discoverability

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> So the only actually _existing_ keybindings we find in the
> Analyzer/Smart Jump subnode tells us about keybindings that don't
> actually use the analyzer.

The main user command for using the analyzer is `C-c , <SPC>'
(semantic-complete-analyze-inline), described in the previous subsection
2.4.1.  The other commands do not have default keybindings, but that is
no reason not to document them.

The manual documents the following keybindings:

  `C-c , j', `C-c , J', `C-c , l', `C-c , g', `C-c , G', `C-c , p',
  `C-c , n', `C-c , u', `C-c, <SPC>', `C-c , C-w', `C-c , M-w',
  `C-c , C-y', `C-c , r', `C-c , up', `C-c , down',

This is a faily large command set, but bear in mind that some of the
more important pieces of Semantic's functionality involves perform tasks
(such as displaying completions) at idle time.  There are no key
bindings associated with such functionality, so merely looking for
keybindings is misleading.

The fact that Semantic provides some more additional commands, which
have no default keybinding, is not a strike against Semantic (many of
these commands are not bound because they are not as useful, but there
is no reason not to document them).  However, feel free to suggest
keybindings if you like.

Re: CEDET discoverability

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> So the only actually _existing_ keybindings we find in the
>> Analyzer/Smart Jump subnode tells us about keybindings that don't
>> actually use the analyzer.
>
> The main user command for using the analyzer is `C-c , <SPC>'
> (semantic-complete-analyze-inline), described in the previous subsection
> 2.4.1.  The other commands do not have default keybindings, but that is
> no reason not to document them.
>
> The manual documents the following keybindings:
>
>   `C-c , j', `C-c , J', `C-c , l', `C-c , g', `C-c , G', `C-c , p',
>   `C-c , n', `C-c , u', `C-c, <SPC>', `C-c , C-w', `C-c , M-w',
>   `C-c , C-y', `C-c , r', `C-c , up', `C-c , down',
>
> This is a faily large command set, but bear in mind that some of the
> more important pieces of Semantic's functionality involves perform tasks
> (such as displaying completions) at idle time.  There are no key
> bindings associated with such functionality, so merely looking for
> keybindings is misleading.
>
> The fact that Semantic provides some more additional commands, which
> have no default keybinding, is not a strike against Semantic (many of
> these commands are not bound because they are not as useful, but there
> is no reason not to document them).  However, feel free to suggest
> keybindings if you like.

The problem is likely not with Semantic.  It is with the manual that
makes it hard to find the relevant information for an end user.  Where
the end user is one that is interested in stuff important enough to be
bound to keys and menus.

When you read the manual, the explanations are more or less at
disconnected DOC string level.  Where there _are_ higher level
explanations, they mostly cover how Semantic works internally, not what
it is good for.

That is not interesting for the user.  It should be funneled off into an
internals/programming manual.

-- 
David Kastrup

Re: CEDET discoverability

[Eric M. Ludlam]

On 07/14/2010 02:48 PM, David Kastrup wrote:
> So the only actually_existing_  keybindings we find in the
> Analyzer/Smart Jump subnode tells us about keybindings that don't
> actually use the analyzer.
>
>> >  Do you have something specific in mind about what is missing?
> There is so much in there that does not seem applicable without
> reverting to Elisp programming that the few things that would likely
> _be_  relevant are hard to find among the rest.
>
> The manual needs to funnel out everything that is not at user interface
> level.

David's point is much like what I had mentioned in the past.  CEDET is a 
big collection of little tools and commands.  As a 3rd party package, 
many items are just provided to be bound on the keyboard where the user 
might want them.  Others are specified as minor modes which need to be 
turned on, and are on C-c <punctuation> or may not have keybindings.  ie 
- they just display decorations or operate on a timer.

I think it would behoove the Emacs community to think about the kinds of 
features you (or users) want, and where they go from an Emacs UI 
perspective.  The emacs integration support of CEDET can then choose to 
bind these items to different keys.  Should some of the items go into 
the global-keymap as base supported tools?  Do others stay in minor-mode 
maps on C-c <punctuation?>

For example, in CEDET/CVS there is cedet-m3.el which binds mouse-3 to 
create a context-sensitive menu of options out of the CEDET suite that 
would be appropriate to use at that specific location clicked.  What key 
could it also be bound to?

Of the items listed in the manual that you didn't feel like binding to 
keys, where should they be bound to to provide the desired UI?

Eric

Re: CEDET discoverability

[David Reitter]

On Jul 14, 2010, at 5:38 PM, Chong Yidong wrote:
> 
> That's what the subnodes are for.  See "Semantic mode user commands" for
> a list of commands enabled by Semantic mode. 

Starting out, how do I tell that it is the "Semantic" package that I want to use in the first place?

M-x info gives

* Semantic: (semantic).         Source code parser library and utilities.

While all people with a CS degree should know what "parser" means, this headline does not adequately describe what it does at the _user_ level.  Internally it parses it and provides libraries, but how it goes about providing its services hardly matters to the user.  Nor can you inspect the newbie to infer these things.

I don't know what the right description is - I don't know Semantic well enough.  Apple calls it "CodeSense", which is a bit better (Sense as English translation of Semantic), but that's still pretty idiosyncratic.  If there's an established term in the Eclipse/NetBeans/whatever world, then that would be good (because people may well know it).

Dito for the menu entry, "Source Code Parsers (Semantic)".  Emacs jargon.

Other bad entries in the info directory include

* Auth-source: (auth).          The Emacs auth-source library.  [user level? different node in info directory?]
* MH-E: (mh-e).                 Emacs interface to the MH mail system.   [ is this e-mail?? ]
* Mairix: (mairix-el).          Emacs interface to the Mairix mail indexer.  [ indexing?  it's about searching&finding, to the user!]
* SASL: (sasl).                 The Emacs SASL library.  [user level? different node in info directory?]


That said, most of the headlines in the info top node are actually pretty good!

Re: CEDET discoverability

[Christoph]

On 7/13/2010 10:29 AM, David Kastrup wrote:

> semantic documentation consists of a lot of buzzwords, and some
> descriptions of its organization (not matching what is installed in
> Emacs), but describes pretty much _nothing_ you could actually call or
> use in Emacs.

This is not true. There is discrepancies between what the manual says 
and what Semantic does, but there was quite a bit of documentation on 
functions and commands.

Christoph

Re: CEDET discoverability

[Eric M. Ludlam]

On 07/13/2010 11:44 AM, Óscar Fuentes wrote:
> "Eric M. Ludlam"<eric@siege-engine.com>  writes:
>
> [snip]
>
>> One of the things I was most surprised by was that when CEDET was
>> integrated into Emacs, only 2 people tried it and reported anything
>> from this list.  I fixed those things too.  Now this list is posting
>> things that effectively pretend CEDET doesn't exist.  What's up with
>> that?
>
> Where on the Emacs documentation can I learn about CEDET? On an Emacs
> compiled a few days ago, I did
>
> M-h i S cedet [ENTER]
>
> and it turned nothing. M-x cedet [TAB] returns nothing too.

There is no "cedet" command.  CEDET is a name on sourceforge that holds 
a host of other tools like semantic, ede, or srecode.  See the front 
page here:

http://cedet.sourceforge.net/

Perhaps I should have started by saying that CEDET/Semantic satisfies 
smart code completion requirement to help here.

> I tried CEDET several years ago with my C++ projects and it was of no
> use (slow, highly inaccurate, slowed down text editing.) I'm sure things
> have improved a lot since that experience (the CEDET docs mentioned that
> its C++ support was very rough) and I'll like to try again. Guess that I
> must go to the CEDET website.

I would have to agree with your performance statement.  A while back I 
built a set of profiling tools and ran against some very large code 
bases, and tuned the parser / analyzer gaining some huge performance 
boosts.  In one experiment I went from an 8 minute analysis down to 1.5 
seconds or so.  There is still lots of overhead for parsing everything 
the first time, but once the databases are there, keeping the tags 
databases up to date and running smart completion is pretty fast now.

Naturally time-outs and work loads are configurable.  Having Emacs 
developers use these tools and tweak these straight-forward 
configurations to come up with some better defaults would be great, 
especially since I don't write code for a living any more and thus lack 
some of that insight. ;(

Note that my results are with Emacs 23.1 and CEDET from the sourceforge 
project.  I would expect the integrated version to be the same.

Eric

Re: CEDET discoverability

[Bruce Stephens]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> On 07/13/2010 11:44 AM, Óscar Fuentes wrote:

[...]

>> M-h i S cedet [ENTER]
>>
>> and it turned nothing. M-x cedet [TAB] returns nothing too.
>
> There is no "cedet" command.

Maybe there should be, with some helpful docstring pointing at the
things that people ought to look at?

It could turn on some set of defaults, for example.  (Or, for all I
care, display the message "Please do not use this command again".)

[...]

CEDET (was: Emacs learning curve)

[Leo]

On 2010-07-13 12:59 +0100, Eric M. Ludlam wrote:
> Enabling the CEDET code completion stuff "by default" would come
> pretty close. I know lots of folks complain about CEDET being hard to
> figure out or configure. On GNU systems with projects written in
> Automake, however, it self configures most of the complicated stuff,
> and will do a good job with completion in C and C++ and a few other
> languages.
>
> CEDET is also now a part of Emacs. Why not configure CEDET to be on,
> use it for a while, and instead of turning it off because of some
> glitch you don't like, fix the little things that confused you or were
> hard. That would take less time than reading this thread.
>
> One of the things I was most surprised by was that when CEDET was
> integrated into Emacs, only 2 people tried it and reported anything
> from this list. I fixed those things too. Now this list is posting
> things that effectively pretend CEDET doesn't exist. What's up with
> that?
>
> Eric

I think any new feature should be enabled for a period of time for
testing purpose. If they are not tested in the development process, they
get tested in the release where users expect things to work reliably and
any problems for them can only be fixed in the next release which at
least is 1-year. Given that Emacs really doesn't have enough man-power
to handle bugs and new features, it seems even more important to find as
many bugs and feature requests to any new addition while its main author
is active.

I really hope CEDET (actually some of its components) can eventually
become a new layer for writing intelligent modes for programming
languages. Syntax highlighting through regexp is pretty dumb. In this
respect Eclipse (the latest release) has become superior to Emacs.

Leo

Re: CEDET

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> I really hope CEDET (actually some of its components) can eventually
> become a new layer for writing intelligent modes for programming
> languages. Syntax highlighting through regexp is pretty dumb. In this
> respect Eclipse (the latest release) has become superior to Emacs.

This is the reason Stefan and I wanted to include CEDET in the first
place.  For various reasons, the integration has been a difficult one,
but I consider it a long-term project.

Re: Emacs learning curve

[Joe Brenner]

Drew Adams <drew.adams@oracle.com> wrote:

> > >> Obviously, there is no reason to choose words perversely
> > >> (e.g. use "red" when we mean green).
> > >
> > > Or use "scroll-up" where it means scroll down, or use
> > > "split-horizontally" where it splits vertically ;)
> >
> > Good one.
>
> Actually no, bad one.

> I specifically chose red/green and _not_ up/down, because up from one
> vantage point is down from another.  _Not_ so for red/green.  It is
> not perverse to call something "up" which someone else might naturally
> think of as down - it depends on the context.

> The question of whether to consider scrolling from the point of view
> of the view port / window or the point of view of the paper / data
> surface / buffer (which is moving?) is as old as the hills.  And the
> answer sometimes depends on the particular application in a logical
> way (think cockpit); otherwise it is arbitrary.

I'm sorry, I think you're completely off base here.  You're right this
issue is as old as the hills, but the actual trouble is that emacs is even
older than the hills, and this is a good example of a UI mistake that's
grandfathered in.

Ted Nelson nailed this one a long time ago.  I paraphrase: "Either way
makes sense if you think about it, but one makes sense if you don't
think about it.  Because users are *drivers*."

I've had this in my .emacs for a few decades now:

  ; Un-dyslexicize emacs
  (global-set-key "\C-x<" 'scroll-right)
  (global-set-key "\C-x>" 'scroll-left)

  (global-set-key "\C-x{" 'enlarge-window-horizontally)
  (global-set-key "\C-x}" 'shrink-window-horizontally)

(And I see that "scroll-left" is disabled by default because new users
find it confusing... I don't want to come on like a rabid "modernize
emacs!" type, but might it not be better to just *fix* what they find
confusing about it?)

Re: Emacs learning curve

[Richard Stallman]

    Ted Nelson nailed this one a long time ago.  I paraphrase: "Either way
    makes sense if you think about it, but one makes sense if you don't
    think about it.  Because users are *drivers*."

I am not sure what you mean by "drivers", and I doubt that your
conclusion is true.  Do you have any evidence that this is true
for people _in general_?

I doubt that is true.

    (And I see that "scroll-left" is disabled by default because new users
    find it confusing

You have misunderstood.  This problem has nothing to do with the
command names.  Some users do horizontal scrolling by accident, not
knowing what they typed, and they don't understand why the buffer
looks strange.  So I decided to disable that command.

We could make horizontal scrolling less confusing if we added
horizontal scroll bars.

Re: Emacs learning curve

[Sean Sieger]

    Actually no, bad one.

    I specifically chose red/green and _not_ up/down, because up from
    one vantage point is down from another.  _Not_ so for red/green.  It
    is not perverse to call something "up" which someone else might
    naturally think of as down - it depends on the context.

I recall your red / green comment ... I mean to say I recall my
confusion.  Red means right and green means left ... and even starboard
and port, in my work and leisure.

I've spent thirty years on theatrical stages where three-dimensional
orientation is key.  Facing down stage (for example) and being able to
say, reflexively, to the person opposite you, ``Goin' right ...,''
meaning moving stage right and _reflexively_ they move in the correct
direction, is key.  Not to mention house left's (or camera left's)
relationship to stage right (it's been my experience that one should
never assume that a camera person has any idea where stage left is).

Identifying objects with red paint on them as stage right pieces as
opposed to green one's that belong on the left---house right.  Um, like
in the maritime world.  People have been using un-usual terminology for
thousands of years.

Anyway, and then there's up / down.  Meaning in / out, into the scene /
out of the scene (whether it's movement through a hole in the stage or
into the upper regions of the stagehouse (the flys).  Up and down are
reserved for the forward and backward, now-days, horizontal, movement.

People that do not get this do not become rigging carpenters---they
don't get to hang stuff over people's heads.  People that can't get
stage left and right right bump into others a lot.  Some just don't work
in theater.

When I first noticed the vertical / horizontal split-thing in Emacs, I
thought to myself, ``I can make this work and save myself some time.''
When I found `C-h t', I thought, ``Cool, that's how this works and works
well.''  I'll only mention touch typing:  touch typing.

RE: Emacs learning curve

[Drew Adams]

> People that do not get this do not become rigging carpenters---
> they don't get to hang stuff over people's heads.

;-)

Do you have an up/down, left/right, red/green test that potential hangers must
pass?

Consider timing them and counting mistakes as they try to fumble through an
Emacs scrolling and window-splitting exercise.  The final exam could attach
hanging and dropping actions to Emacs keys (with no one onstage, of course).

And now I know where the idea of "upstaging" someone came from.
I knew something good would come of this thread.

Re: Emacs learning curve

[Sean Sieger]

"Drew Adams" <drew.adams@oracle.com> writes:

    > People that do not get this do not become rigging carpenters---
    > they don't get to hang stuff over people's heads.

    ;-)

    Do you have an up/down, left/right, red/green test that potential
    hangers must pass?

Riggers.  No, it's a catch twenty-two, you can't become a rigger unless
you're a rigger and ... and your father, uncles and grandfather were
riggers first.  Yes, spacial-conteptual tests are given.  Back in the
day (when we threw lit cigarettes on the stage when we were through
smoking them and so on) we did what old guys told us to, people that
didn't, well, didn't come back.  I remember when Yale graduates first
started showing up---glazed looks in their eyes, but my boss had taught
them, so they came through all right.

    Consider timing them and counting mistakes as they try to fumble
    through an Emacs scrolling and window-splitting exercise.  The final
    exam could attach hanging and dropping actions to Emacs keys (with
    no one onstage, of course).

Yuh-huh.  Every install starts with removing counterbalance-rigging and
replacing it with computer-controlled drives ... red means `stand by'
(warning), green means `go' (the whole f'n stage moves ... ooof).  The
sucky software back then was written in C++ oh-by-the-way.  Rigging and
Automation are not for the faint of heart.

    And now I know where the idea of "upstaging" someone came from.  I
    knew something good would come of this thread.

Emacs tends toward good.  (That's a belief ... I didn't know I had any
beliefs.)

Re: Emacs learning curve

[Uday S Reddy]

On 7/12/2010 11:03 PM, Drew Adams wrote:

> The question of whether to consider scrolling from the point of view of the view
> port / window or the point of view of the paper / data surface / buffer (which
> is moving?) is as old as the hills.  And the answer sometimes depends on the
> particular application in a logical way (think cockpit); otherwise it is
> arbitrary.

I thought sensible systems always did it from the point of view of the human 
user, ergo human-centered systems.

When I teach, I say "delete left subtree" using my right arm.  Nobody ever gets 
confused.  It took me a while to learn to do it though.

The aerobic instructors don't do that.  They say raise you right arm and 
demonstrate by raising *their* right arm.  People seem to manage ok, but I have 
to admit I do get confused.

So, a human-centered Emacs would "scroll-down" by letting the human user move 
down a document (not move the document down).  The real Emacs does the opposite.

Cheers,
Uday

RE: Emacs learning curve

[Drew Adams]

> > The question of whether to consider scrolling from the 
> > point of view of the view port / window or the point of
> > view of the paper / data surface / buffer (which
> > is moving?) is as old as the hills.  And the answer 
> > sometimes depends on the particular application in a
> > logical way (think cockpit); otherwise it is arbitrary.
> 
> I thought sensible systems always did it from the point of 
> view of the human user, ergo human-centered systems.

Of course, but what is the point of view of the human user?

It depends on the application and what the user is doing, where s?he "naturally"
places her point of view.  In some graphics domains it sometimes makes sense to
take the point of view of the paper (object) and not the view port; in other
contexts, vice versa.

"The human" is neither the view port nor the paper, and can identify with
either, whichever is more convenient/pertinent to the task at hand.

For things like scrolling, there is no "correct", "natural", or "human" point of
view (IMO).  Witness the number of scrolling implementations with both
orientations developed over the years.

Now if one of the orientations becomes much more widely used, then everyone
becomes used to it and it does indeed appear natural, human-oriented, normal. Of
course.  But there is nothing inherently more natural or human about either
(IMO).

A Brit in Yankland or a Yank in Britland can easily relate to this when trying
to cross the street or drive.  What seems so natural to the one is alien to the
other.  These side-of-the-road conventions are basically arbitrary (yes, I know
the history, but for practical purposes we can call it a toss-up).

And yet! And yet one side of the road really _does_ feel natural and human - the
side you are used to.

Re: Emacs learning curve

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > The question of whether to consider scrolling from the 
>> > point of view of the view port / window or the point of
>> > view of the paper / data surface / buffer (which
>> > is moving?) is as old as the hills.  And the answer 
>> > sometimes depends on the particular application in a
>> > logical way (think cockpit); otherwise it is arbitrary.
>> 
>> I thought sensible systems always did it from the point of 
>> view of the human user, ergo human-centered systems.
>
> Of course, but what is the point of view of the human user?

In Greece, I made quite a tangle in the rope when the climbing
instructor very strongly stated I should leave the tree to the left.
Usually I would have passed it to the right (and it looked quite obvious
like the thing to do), but after his insistence, to his chagrin, I
passed it on the left.

I did not really focus on his exact wording, and the Greek view seems to
be different...

-- 
David Kastrup

Re: Emacs learning curve

[Alfred M. Szmidt]

You are conflating two separate issue, one of terminology, and one of
non-working features, so are many people in this thread.

The terminology debate will be ongoing for eternity, so I'll sing abit
instead:

| You like potato and I like potahto, you like tomato and I like
| tomahto.  Potato, potahto, tomato, tomahto, let's call the whole
| thing off...

Point being, depending on context we define words to mean things, and
sometimes when taken out of ontext they might mean other things.
Neither is more right nor more wrong, it is just different.


Regarding features, this is infact what people are having problems
with, like yourself and _not_ about terminology.  The most basic
prerequisite for any feature is that it should work without any
configuration, one shouldn't have to define what a tetromino is to
play tetris even though your tetromino might be different from mine.

In your case, CEDET not working out of the box, and being hard to
configure on top of that.  This is a bug, could you file a bug report
so that the problem can be looked at?  If people don't report problems
they experience, then they won't be known.

Re: Emacs learning curve

[Óscar Fuentes]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> You are conflating two separate issue, one of terminology, and one of
> non-working features, so are many people in this thread.

Not really. The terminology is just a small part of the whole issue,
which is the kind of people Emacs development should target. Here on the
Bikeshedding Paradise (a.k.a. emacs-devel) it is understandable that
people tend to see this as a debate on terminology and ignore the really
important issue, but let's try to not do that.

[snip]

> Regarding features, this is infact what people are having problems
> with, like yourself and _not_ about terminology.  The most basic
> prerequisite for any feature is that it should work without any
> configuration, one shouldn't have to define what a tetromino is to
> play tetris even though your tetromino might be different from mine.

I'm glad you think like this. I have the impression that some prominent
hackers here think that it is a good thing and a show of distinction to
produce systems that require reading a manual and do quite a bit of
tinkering before usage. This is a symptom of the hacker's limitations,
of course. He implicitly acknowledges that designing the system on a way
that does not require that burden from the user was too much for him
(there is no derogatory intention towards any Emacs hacker here)

> In your case, CEDET not working out of the box, and being hard to
> configure on top of that.  This is a bug, could you file a bug report
> so that the problem can be looked at?  If people don't report problems
> they experience, then they won't be known.

I'm afraid that the problem was on the third party Elisp package that
provided C# support to CEDET. It required tweaks here and there to make
compile with the CEDET that is distributed with Emacs, lacked detailed
instructions and smelled like unmaintained since a few years ago.

Again, this is not the real issue. The lesson here is that Emacs can
learn a lot from other projects wrt how to behave towards its potential
audience.

Re: Emacs learning curve

[Uday S Reddy]

On 7/13/2010 1:18 AM, Óscar Fuentes wrote:

> I'm glad you think like this. I have the impression that some prominent
> hackers here think that it is a good thing and a show of distinction to
> produce systems that require reading a manual and do quite a bit of
> tinkering before usage. This is a symptom of the hacker's limitations,
> of course. He implicitly acknowledges that designing the system on a way
> that does not require that burden from the user was too much for him
> (there is no derogatory intention towards any Emacs hacker here)

I think we are a bit past that stage in the Emacs world.  [A historical 
throwback: when Emacs started, the reigning champion of the computing world was 
Unix.  To use Unix, not only did you have to read its manuals and memorize them 
as much as you could, but also the manuals were ugly and boring.  In contrast, 
the Emacs manual was readable and insightful and you didn't have to memorize 
more than what you had to.  The manual was at your finger tips whenever you 
wanted to look up something.  It was a great advance over the extant practice.]

The present Emacs allows you to do quite a bit without reading a manual.  But 
unless you read the manual, you won't have the depth of understanding necessary 
to solve problems or to have a good mental model of what is actually happening. 
  This is true not only of Emacs, but all other tools that are supposedly 
famous for being grandmother-friendly, i.e., Microsoft/Apple/Mozilla etc.

A few months ago, we had some users trying to switch from Thunderbird to VM. 
The biggest problem they had was that, when they deleted messages in 
Thunderbird they apparently disappeared.  But when they viewed the same folders 
in VM, all those deleted messages came back!  Well, they had a slash through 
them in the summary display but they were still there.

It took me some 10 minutes of digging through the Thunderbird manuals (the 
so-called "Knowledge Base") to find out that:

(a) Thunderbird doesn't delete messages when you delete them.  It does a 
separate expunge either automatically or when you ask it to.

(b) The so-called "Trash" folder isn't actually recycle bin.  So, you couldn't 
undelete messages by just going to it.

In fact, the Thunderbird knowledge base offered the rather innovative method of 
logging into the same IMAP account via a webmail system (imagine!) in order to 
undelete the messages that you might have accidentally deleted in Thunderbird.

Thus, in 10 minutes, I had more insight into what Thunderbird was doing than 
these habituated users that might have used it for years.

Literacy is a great advance for humanity, not because it makes us feel 
sophisticated, but because it is efficient for acquiring knowledge.

Cheers,
Uday

Re: Emacs learning curve

[Richard Stallman]

"Alfred M. Szmidt" <ams@gnu.org> wrote:

    > Regarding features, this is infact what people are having problems
    > with, like yourself and _not_ about terminology.  The most basic
    > prerequisite for any feature is that it should work without any
    > configuration, one shouldn't have to define what a tetromino is to
    > play tetris even though your tetromino might be different from mine.

I agree completely.

We cannot hope to make all Emacs features totally easy to use without
a manual and without configuration, because that would require
discarding what makes Emacs good for us.  But we can make a lot of
Emacs features a lot easier to use without a manual or configuration,
without giving up anything important.

I think it is very important to do that.

Re: Emacs learning curve

[christian.lynbech]

I disagree that Emacs is actively trying to work against certain classes
of users, as you seem to suggest.

Obviously, Emacs has varying degrees of support for different
programming languages. Somebody has to provide such support, it does not
materialise out of the blue, and as with most free software support
follows the interest of the developers.

If C# is poorly supported, it simply means that very few dedicated emacs
hackers has had the need/motivation/time to provide it. In contrast,
Emacs offers some of the best Common Lisp support anywhere, complete
with cross-referencing, documentation access, completion and minibuffer
argument hints.

And also when it comes to backwards compability, Emacs is no different
than so many other tools. As the story goes, the inventors of `make'
quickly realised that using a whitespace character as command indicator
was a poor choice but they dared not change it as the tool already had
something like 10 users! 

Of course seasoned users will protest if features ingrained in Emacs
past decades are suggested altered, such is the nature of any user of
any tool. Just listen to the debates over the ribbon in Microsoft Office
or when Facebook redesigns its interface. 

It is then up to the current maintainers to decide whether or not to
listen, and as allways there will be a bias to cater to an existing
audience rather than sway to whatever illusive potential attraction this
or that change will provide.

Like almost any other kind of software, Emacs has not got infinite
amount of resources and thus must pick its battles carefully and there
will always be people who will find their particular needs ill-served.
Even if such a group may be really big in a global perspective (like C#
users) they still represent a dwindling population among those that have
the means to move Emacs in that direction.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Emacs learning curve

[David Kastrup]

<christian.lynbech@tieto.com> writes:

> I disagree that Emacs is actively trying to work against certain classes
> of users, as you seem to suggest.
>
> Obviously, Emacs has varying degrees of support for different
> programming languages. Somebody has to provide such support, it does not
> materialise out of the blue, and as with most free software support
> follows the interest of the developers.
>
> If C# is poorly supported, it simply means that very few dedicated emacs
> hackers has had the need/motivation/time to provide it. In contrast,
> Emacs offers some of the best Common Lisp support anywhere, complete
> with cross-referencing, documentation access, completion and minibuffer
> argument hints.

The question is why the respective facilities are not part of the
generic Emacs language support framework.  Support for every language
has a completely disjoint set of features, keybindings, highlighting,
and so on of wildly differing quality, design and usability.

One problem with learning Emacs is that you have to learn it new for
each language, and every person writing language support has to create
it new from almost scratch.

If there is a new language, and two different people write non-trivial
support for it, the results will be wildly different.

-- 
David Kastrup

Re: Emacs learning curve

[joakim]

David Kastrup <dak@gnu.org> writes:

> <christian.lynbech@tieto.com> writes:
>
>> I disagree that Emacs is actively trying to work against certain classes
>> of users, as you seem to suggest.
>>
>> Obviously, Emacs has varying degrees of support for different
>> programming languages. Somebody has to provide such support, it does not
>> materialise out of the blue, and as with most free software support
>> follows the interest of the developers.
>>
>> If C# is poorly supported, it simply means that very few dedicated emacs
>> hackers has had the need/motivation/time to provide it. In contrast,
>> Emacs offers some of the best Common Lisp support anywhere, complete
>> with cross-referencing, documentation access, completion and minibuffer
>> argument hints.
>
> The question is why the respective facilities are not part of the
> generic Emacs language support framework.  Support for every language
> has a completely disjoint set of features, keybindings, highlighting,
> and so on of wildly differing quality, design and usability.
>
> One problem with learning Emacs is that you have to learn it new for
> each language, and every person writing language support has to create
> it new from almost scratch.
>
> If there is a new language, and two different people write non-trivial
> support for it, the results will be wildly different.

I agreep. I find the lack of consistency between Emacs tools quite
frustrating.

Personally I try to help improving this situation by intermittently
helping out with CEDET, and whine about consistent key-bindings between
modes now and then.

-- 
Joakim Verona

Re: Emacs learning curve

[immanuel litzroth]

> One problem with learning Emacs is that you have to learn it new for
> each language, and every person writing language support has to create
> it new from almost scratch.

Almost from scratch? There is support for highlighting, code
indentation, running
inferior interpreters, running debuggers... -- There is a unified mode
for debuggers
that does perldb, pythondb, ocamldb, gdb....
I wouldn't say that is almost from scratch.
Code completion is just irealistic without compiler/interpreter support.

Moreover the competition isn't doing much better... In my job we have
at two recent
emacs converts -- from vi and/or eclipse -- and two more coming once
they decide they've
had enough of doing ocaml in vi -- we do c++ on linux and ocaml and python.
Immanuel

Re: Emacs learning curve

[Eric M. Ludlam]

On 07/13/2010 04:10 AM, David Kastrup wrote:
> <christian.lynbech@tieto.com>  writes:
>
>> I disagree that Emacs is actively trying to work against certain classes
>> of users, as you seem to suggest.
>>
>> Obviously, Emacs has varying degrees of support for different
>> programming languages. Somebody has to provide such support, it does not
>> materialise out of the blue, and as with most free software support
>> follows the interest of the developers.
>>
>> If C# is poorly supported, it simply means that very few dedicated emacs
>> hackers has had the need/motivation/time to provide it. In contrast,
>> Emacs offers some of the best Common Lisp support anywhere, complete
>> with cross-referencing, documentation access, completion and minibuffer
>> argument hints.
>
> The question is why the respective facilities are not part of the
> generic Emacs language support framework.  Support for every language
> has a completely disjoint set of features, keybindings, highlighting,
> and so on of wildly differing quality, design and usability.

I have to agree with David here.  I'd noticed for a long time that every 
mode is a little different.  Different C-c special bindings doing 
similar things, or the same C-c binding doing the different things.

This is something I addressed from the start with CEDET.  Every 
mode-specific configuration fits in the CEDET infrastructure, not at the 
user interaction level.  Parsers, project support, template support, etc 
can be provided for a language without consideration for how it might be 
used.  The results are managed by the CEDET infrastructure, and tools 
built on top of that infrastructure will work for every language with 
support the same way.  ECB is a great example of this language 
homogenization at work on a complex and very cool app.

Getting the suite of tools in CEDET to do this wasn't that hard, but did 
take time.  Finding tools I liked, figuring out the commonality between 
languages, and trying to make it "easy" to add language support was the 
first step, and there are lots of tools out there to start from.  Many 
other "ui" like tools do the same.  Anything and predictive come to mind.

I don't want to claim that CEDET is the best thing going, but I do think 
that building up infrastructure for languages to add specialty support 
is what will make having consistent language support more likely, and 
thus make Emacs easier to learn for all languages.

Eric
Eric

Re: Emacs learning curve

[Óscar Fuentes]

<christian.lynbech@tieto.com> writes:

> I disagree that Emacs is actively trying to work against certain classes
> of users, as you seem to suggest.

I'm not suggesting that.

[snip]

Re: Emacs learning curve

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 12 Jul 2010 22:53:24 +0200
> 
> A few weeks ago I was required to translate an old, small Visual Basic
> application to C#. I was less than thrilled with the job, but anyways
> the first thing was to configure Emacs as a C# editor. There is
> csharp-mode, which does code formatting. So far, so good. There are two
> methods for code completion, one based on CEDET and the other on an
> external tool. The CEDET method was a nonstarter, the other worked
> so-so. As I'm an absolute beginner on C# and it comes with a vast API,
> code completion was too much of a time-saver to be neglected. After 3
> hours trying to raise Emacs to the minimum usability level, I gave up
> and tried certain popular IDE, out of despair. 15 minutes later my
> client's application, on its basic inception, was running on the screen,
> mostly thanks to an accurate and fast code completion system that not
> only shows the candidates for completion, but also displays some
> documentation explaining what every method does. This saves a lot of
> time browsing documentation.

CEDET is a relatively new addition to Emacs.  I don't use it, but from
some comments by its maintainer posted here, it sounds like it needs
some work to bring it up to a reasonable level of usability for
newbies.  Like everything else in Emacs, this job needs motivated
individuals to step forward and do it.  I don't see anything in this
situation that could trigger this outburst:

>                                   It is disheartening to see how every
> time that someone proposes a tiny change on the default configuration
> for lowering the entry barrier, a vociferous group of reactionaries try
> to block the initiative, usually winning the fight, just because they
> don't want to add a line or two to their .emacs file.

What "reactionaries"?  All I see is a newly added package and a job to
be done with making it better, waiting (for a relatively short time,
up until now) for volunteers to do it.

How on earth evident problems with a single Emacs package can lead to
such extremist opinions?  Did you have an awfully bad day or
something?

> Emacs does just the opposite. See how people on this discussion says "of
> course the new Emacs user will read the Tutorial etc."

Contrary to what you've read, I maintain that reading the tutorial is
not a necessity.  Half of it describes issues that are common
knowledge nowadays, anyway (e.g., "If you want to insert text, just
type the text").  The other half is only needed for "advanced users".
Most of that is available through menus, so no need to learn the
keyboard keybindings, unless you are a touch typist.

We are keeping the tutorial and recommend that users read it because
of a certain policy.  I happen to agree with that policy, but I also
know that it has nothing to do with the ability to use Emacs
reasonably well, right from day one.

Of course, what you can do with Emacs from day one does not
necessarily include features like CEDET or Gnus -- but the tutorial
will not help here, either.

> IMAO the Emacs maintainers should ignore the winning and threatening of
> those users and focus on making Emacs as attractive as possible to the
> new generations of hackers.

Breaking news: There is no such thing as "Emacs maintainers".  There's
a group of people who contribute to Emacs development, each one in the
area of his/her interests.  (In addition, they fix bugs, as much as
their time and energy allows them -- but I hope you will agree that
what you want cannot be achieved by way of fixing bugs.)  Areas that
are not within the interests or expertise of these developers do not
get developed, no matter how important they are.  The support for
editing bidirectional text is a good recent case in point, if you need
one.

Conclusion: people who are interested in making Emacs more usable by
"new generations of hackers" should stop complaining, and instead
_act_.  Don't try to fix this or that isolated feature -- this just
tends to get bogged down in endless bike-shed arguments about defaults
and faces.  Instead, work out and present "The Plan" -- a list of
issues that need to be handled, infrastructure that needs to be added,
and features and packages that need to be developed or added, in order
to reach the goal.  Then start producing code according to that Plan.
There's nothing like a working code to convince non-believers (if
there are such among the active developers) and there's nothing like a
workable plan to attract followers.  If there's anything clear from
this confused thread, it's that we sorely need some kind of unified
"vision" and specific goals.  Throwing random ideas and critique will
get us nowhere.

Developer contributions / was: Re: Emacs learning curve

[David Reitter]

On Jul 12, 2010, at 9:43 AM, Stephen J. Turnbull wrote:

>  But I bet there is also a fair amount of
> good code sitting around out there that people are unwilling to
> contribute because of the scutwork and bikeshedding entailed in
> getting anything into Emacs, and which experienced developers could
> whip into shape quite quickly if they just took the code and said "it
> will be our pleasure".
> 
but:
On Jul 12, 2010, at 10:20 AM, Eli Zaretskii wrote:

> However, I hope you will understand that making the necessary changes
> for a contributor who is unwilling to make them by herself is not a
> good policy in the long run, because (1) it's hardly a good use of the
> limited time resources I have, and (2) we will need to do this
> forever, as the contributor doesn't want to adapt their practices to
> some minimal requirements of QA and code cleanness.  He even refuses
> to reformat his code as to facilitate the review!
> 

Often, I find that developers here insist on diagnosing and fixing more than is necessary to address an annoyance reported by the user.  Usually, they technically right and I applaud their thoroughness.  However, given limited resources, I prioritize issues reported by our users (n>1).  Hunting down some deep issues tends to be very difficult if you don't know the relevant code intimately.  So, I leave this to people who can do it.  (An example is the recent discussion about frame order management that should be left to the window manager on NS.)

A "diff" between Emacs and Aquamacs currently runs >500k lines.  While much of it may not be to Emacs code quality standards (it's not about formatting!), it represents an incremental improvement nonetheless.   All of this is GPL'ed of course.  I cannot assign every bit of code to the FSF (it was contributed by many authors), but then again, nobody ever asked or volunteered their time to adapt code for upstream integration anyway.

Further development issues:

- If the Git mirror finally allowed commits, I would at least commit some bug fixes and small improvements!  Am I the only one?

- In some cases, where I have analyzed bugs and almost present them on a plate, the bug reports still go ignored for a long time. Given limited resources, let's improve collaboration here to maximize efficiency.

Re: Emacs learning curve

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> I don't see anything in this situation that could trigger this
> outburst:
>
>>                                   It is disheartening to see how every
>> time that someone proposes a tiny change on the default configuration
>> for lowering the entry barrier, a vociferous group of reactionaries try
>> to block the initiative, usually winning the fight, just because they
>> don't want to add a line or two to their .emacs file.
>
> What "reactionaries"?  All I see is a newly added package and a job to
> be done with making it better, waiting (for a relatively short time,
> up until now) for volunteers to do it.
>
> How on earth evident problems with a single Emacs package can lead to
> such extremist opinions?  Did you have an awfully bad day or
> something?

If you do selective quoting and paragraph reordering for reaching a
negative opinion, I'm left wondering who of us is having an awfully bad
day. Read again my message and you see how between the two paragraphs
you quoted there is a lot of substance.

>> Emacs does just the opposite. See how people on this discussion says "of
>> course the new Emacs user will read the Tutorial etc."
>
> Contrary to what you've read, I maintain that reading the tutorial is
> not a necessity.

I'm not sure about this. Maybe we should experiment with a few seasoned
hackers who never used Emacs and observe if they reflect surprise or
confussion about some features that are contrary to all their previous
experience, without perceiving any advantage on them.

[snip]

> Of course, what you can do with Emacs from day one does not
> necessarily include features like CEDET or Gnus -- but the tutorial
> will not help here, either.

As is implicit on the message you quoted, the features provided by CEDET
are a must-have if you pretend to advertise Emacs as a productivity
boost for certain tasks which are becoming more prevalent as time
passes, so those features should work (and work well) from the very
moment the user visits a file where they are applicable.

>> IMAO the Emacs maintainers should ignore the winning and threatening of
>> those users and focus on making Emacs as attractive as possible to the
>> new generations of hackers.
>
> Breaking news: There is no such thing as "Emacs maintainers".

Well, call them by some other name, but the maintainers I'm thinking of
are those with the power of making controversial decisions against the
opinion of other prominent Emacs contributors. Currently they are Chong
and Stefan, AFAIK.

> There's a group of people who contribute to Emacs development, each
> one in the area of his/her interests.  (In addition, they fix bugs, as
> much as their time and energy allows them -- but I hope you will agree
> that what you want cannot be achieved by way of fixing bugs.)  Areas
> that are not within the interests or expertise of these developers do
> not get developed, no matter how important they are.  The support for
> editing bidirectional text is a good recent case in point, if you need
> one.

This is fine with me, as far as those people do not stop development,
advancement, change or whatever you call it, on other areas. One related
example comes to mind: when the bug tracker was discussed, some
maintainer of a key package threatened with stopping his Emacs work if
the tracker's interface was such and such (being "such and such"
precisely the kind of UI which is considered the most open and
user-friendly for beginners.)

> Conclusion: people who are interested in making Emacs more usable by
> "new generations of hackers" should stop complaining, and instead
> _act_.  Don't try to fix this or that isolated feature -- this just
> tends to get bogged down in endless bike-shed arguments about defaults
> and faces.  Instead, work out and present "The Plan" -- a list of
> issues that need to be handled, infrastructure that needs to be added,
> and features and packages that need to be developed or added, in order
> to reach the goal.

Well, I was thinking on that plan, because I'm working on a project that
is tangential to this, so I was even considering to write an sketch and
submit it here just in case there is something on it that is unaceptable
or someone proposes an improved strategy. Guess what? there was no need
for it: was smashed a few post above.

It seems that a workable plan here must meet the following conditions:

* Follow the GNU guidelines wrt the programming language. There is quite
  a bit of personal, questionable opinions there. But well, maybe we
  could devise a design that buries the "ugly" code out of sight (I
  share the opinion about the uglyness, but I must take on account the
  usefulness of the beast. Besides, some C code in Emacs can rival a C++
  template meta-programming library on terms of readability.)

* When there is a GNU package for doing something, use it instead of a
  non-GNU one. It doesn't help much that the non-GNU package is
  compatible with the GPL. Given the nature of the GNU project, this
  makes sense, as long as the GNU package is a match for the non-GNU one
  on terms of how good is it for the job. However, as we have
  experienced recently, an inferior GNU system triumphs over a superior
  non-GNU one, hoping that, eventually, the GNU system improves. There
  is little point on convincing the key people about the slight
  possibilities of seeing those hopes ever realized.

* Unless it is something accessory that does not conflict with existing
  code, the plan must be technically acceptable for an overwhelming
  majority of the key Emacs hackers. For a plan that introduces
  significant changes, this happens with less frequency than the
  alignment of the four outer planets of the Solar System.

* Ditto for the UI changes included in the plan. This is, possibly, even
  more difficult. Once you have write access to the repo you are on your
  own for changing things (or you can work on your own branch) but some
  existing users will complain out loud if they are suppossed to add a
  line to their .emacs for keeping the previous behavior. Think about
  something that changes some core piece of Emacs philosophy.

> Then start producing code according to that Plan.  There's nothing
> like a working code to convince non-believers (if there are such among
> the active developers)

Sorry, only for the GUI infrastructure, this would be a multi-year
effort (working an average of 10 hours per week.) But it doesn't matter,
because my plan was already rejected.

> and there's nothing like a workable plan to attract followers.  If
> there's anything clear from this confused thread, it's that we sorely
> need some kind of unified "vision" and specific goals.  Throwing
> random ideas and critique will get us nowhere.

I completely agree, but it is in contradiction with what you wrote above
about every developer scratching it itch.

Re: Emacs learning curve

[Juanma Barranquero]

On Wed, Jul 14, 2010 at 00:37, Óscar Fuentes <ofv@wanadoo.es> wrote:

> but some
>  existing users will complain out loud if they are suppossed to add a
>  line to their .emacs for keeping the previous behavior.

If by "users" you mean "developers", I don't think that's a fair
assessment. People argues harshly against even the tiniest change in
default behaviour, but it is not out of laziness, but strong beliefs
on what the right default is (or should be).

    Juanma

Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Well, call them by some other name, but the maintainers I'm thinking of
 > are those with the power of making controversial decisions against the
 > opinion of other prominent Emacs contributors. Currently they are Chong
 > and Stefan, AFAIK.

And Richard.  Note that Stefan and Yidong are *officially* maintainers,
anointed by the GNU Project, IIRC.  However, for the present purposes
they are more like a Supreme Court than they are like an Environmental
Protection Agency.

But it's also true that any committer can make such a decision
(outside of the UI).  I can't recall a thread off-hand, but basically
what happens is that other committers think "Well, on your head be it,
then," and somebody who commits against substantial opposition is
staking their credibility.  Knowing most of the people involved, I
would bet you don't even have to be right.  Rather, if you recognize
that your idea is going south and revert it before somebody else does,
you get credit for bold but objective thinking.

 > Well, I was thinking on that plan, because I'm working on a project that
 > is tangential to this, so I was even considering to write an sketch and
 > submit it here just in case there is something on it that is unaceptable
 > or someone proposes an improved strategy. Guess what? there was no need
 > for it: was smashed a few post above.

If there is a policy rule that smashes it, then why mention it?  The
only thing that needs to be said in that case is "we newer
contributors need an explicit list of policy rules."  (And I don't
mean scattered through historical documents like the GNU Manifesto.)

If it's merely the weight of developer opinion that smashed it, maybe
you really ought to make the proposal formally.  If not accepted (and
you're right, few are) but none of the criticism convinces you
otherwise, make a branch.  What's your big hurry?

Think, how long has Miles's lexbind branch been around?  That's a
great idea with a consensus behind it, but since it changes everything
it needs substantial testing.  I gather that there is almost consensus
for integrating it "soon" (ie within a couple of release cycles).  I
think a good demo of "something better" that's more superficial than
changing the default semantics of binding (wow, what a concept) would
take far less time to be embraced.  But you need to show people that
it's better with a demo; words rarely are enough unless you have a
track record of introducing significant improvements.

 > It seems that a workable plan here must meet the following conditions:
 > 
 > * Follow the GNU guidelines wrt the programming language.

True.  That's policy, and a good one.  (Not the particular choice of
C, but some specific choice.)

 > * When there is a GNU package for doing something, use it instead of a
 >   non-GNU one.

True.  That's policy, arbitrary but with great support in the core
developer group.  Live with it.

 >   It doesn't help much that the non-GNU package is compatible with
 >   the GPL.

Of course it does.  You can make a friendly fork that uses it.  It
some cases (Windows OS, Mac GUI) it doesn't even have to be
GPL-compatible.  Then bombard the relevant GNU package with bug
reports and screenshots. :-)

 > * Unless it is something accessory that does not conflict with existing
 >   code, the plan must be technically acceptable for an overwhelming
 >   majority of the key Emacs hackers.

No.  You need Stefan and Yidong behind the proposal, and Richard's
silence at least.  I haven't seen Yidong make a decision for a change
against the majority opinion, but I'm sure he's capable, and I have
seen Stefan do so.

It is true that Stefan and Yidong typically seem to follow the
consensus of the key hackers, but that's only because they tend to
speak last.  Really they're leading it. :-)

You do, of course, have to show them that your plan actually can work,
but even performance issues can be postponed in the trunk.

 >   For a plan that introduces significant changes, this happens with
 >   less frequency than the alignment of the four outer planets of
 >   the Solar System.

Not true.  The internals of Emacs have changed dramatically several
times in the last decade (I know that's true because the attendant,
relatively small, changes in API and/or UI are a massive pain in my
ass).  I can only imagine that other, smaller, internal changes happen
quite frequently.

 > * Ditto for the UI changes included in the plan.

That depends.  My sketch of a proposal for a thorough addition of
iconic vocabulary in the UI (a) does not conflict with existing usage,
(b) can be implemented with existing features of the API, and (c) can
be done incrementally over many years.  (That doesn't mean it's
*right*, but it's do-able, and if a committer were to "Just Do It,"
they might be criticized but I doubt it would be forcibly reverted
unless there's some horrible aspect I haven't foreseen.)

 > > and there's nothing like a workable plan to attract followers.  If
 > > there's anything clear from this confused thread, it's that we sorely
 > > need some kind of unified "vision" and specific goals.  Throwing
 > > random ideas and critique will get us nowhere.
 > 
 > I completely agree, but it is in contradiction with what you wrote above
 > about every developer scratching it itch.

No, Eli's saying that some developers have momentary itches, and other
developers have the ten-year itch.  He's looking for someone with a
ten-year itch. :-)

Find a copy of the TV drama "Numbers", I think it's the second show.
The protagonist goes into a game arcade and tells his mentor that he's
totally mentally blocked.  His mentor says, "*You* are?  Ah, I see:
you're trying to deal with human beings, right?" and he nods.  His
mentor then advises him, "When humans are in the equation, things get
messy and paradoxical" or something like that.  Great scene.

Re: Emacs learning curve

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 14 Jul 2010 00:37:30 +0200
> 
> Read again my message and you see how between the two paragraphs
> you quoted there is a lot of substance.

That substance seemed unrelated to the outburst.  Basically, I don't
understand how a bunch, even a large bunch, of usability problems
could lead to far-fetched (and IMO wrong) conclusions that Emacs
development is controlled by a band of reactionaries.

> > Contrary to what you've read, I maintain that reading the tutorial is
> > not a necessity.
> 
> I'm not sure about this. Maybe we should experiment with a few seasoned
> hackers who never used Emacs and observe if they reflect surprise or
> confussion about some features that are contrary to all their previous
> experience, without perceiving any advantage on them.

I already conducted those experiments, on my daytime job.  None of the
users whom I introduced to Emacs ever read the tutorial.

> >> IMAO the Emacs maintainers should ignore the winning and threatening of
> >> those users and focus on making Emacs as attractive as possible to the
> >> new generations of hackers.
> >
> > Breaking news: There is no such thing as "Emacs maintainers".
> 
> Well, call them by some other name, but the maintainers I'm thinking of
> are those with the power of making controversial decisions against the
> opinion of other prominent Emacs contributors. Currently they are Chong
> and Stefan, AFAIK.

None of whom said anything against better usability so far.  And
Yidong did most of the hard work of integrating CEDET into Emacs to
begin with.

> This is fine with me, as far as those people do not stop development,
> advancement, change or whatever you call it, on other areas.

I don't recollect any incident that would go by that handle.  There
was a lot of tiresome longish discussions about defaults for this or
that option, but I wouldn't recommend generalizing them to something
as significant as what you are talking about.  That's why I suggested
not to start arguing about options, but instead to present a vision
and a plan.

> One related
> example comes to mind: when the bug tracker was discussed, some
> maintainer of a key package threatened with stopping his Emacs work if
> the tracker's interface was such and such (being "such and such"
> precisely the kind of UI which is considered the most open and
> user-friendly for beginners.)

How's this relevant to Emacs features and usability in general?  Did
anyone suggest a change that was rejected because it was incompatible
with the bug tracker?

> Well, I was thinking on that plan, because I'm working on a project that
> is tangential to this, so I was even considering to write an sketch and
> submit it here just in case there is something on it that is unaceptable
> or someone proposes an improved strategy. Guess what? there was no need
> for it: was smashed a few post above.

I didn't see anyone smashing the plan, because no plan was ever
presented.

> * Follow the GNU guidelines wrt the programming language. There is quite
>   a bit of personal, questionable opinions there. But well, maybe we
>   could devise a design that buries the "ugly" code out of sight (I
>   share the opinion about the uglyness, but I must take on account the
>   usefulness of the beast. Besides, some C code in Emacs can rival a C++
>   template meta-programming library on terms of readability.)

If you read those parts of the Standards document carefully, you will
see that they are merely _recommendations_.  A case in point is the
Groff project: a very old member of the GNU family, it was implemented
in C++ from day one.

Anyway, I'd expect most, if not all, of the usability-related job to
be done in Lisp, so I see no problems with the choice of programming
language here.

> * When there is a GNU package for doing something, use it instead of a
>   non-GNU one. It doesn't help much that the non-GNU package is
>   compatible with the GPL. Given the nature of the GNU project, this
>   makes sense, as long as the GNU package is a match for the non-GNU one
>   on terms of how good is it for the job. However, as we have
>   experienced recently, an inferior GNU system triumphs over a superior
>   non-GNU one, hoping that, eventually, the GNU system improves. There
>   is little point on convincing the key people about the slight
>   possibilities of seeing those hopes ever realized.

Is this even relevant?  Did someone analyze what external packages are
needed for the job at hand and presented that analysis?

Giving up because of theoretical complications doesn't sound wise to
me.

> * Unless it is something accessory that does not conflict with existing
>   code, the plan must be technically acceptable for an overwhelming
>   majority of the key Emacs hackers. For a plan that introduces
>   significant changes, this happens with less frequency than the
>   alignment of the four outer planets of the Solar System.

Again, is this relevant?  What "significant changes" are we talking
about?  I would imagine a specialized package, perhaps built based on
CEDET, and/or specialized mode.  These can be turned on and off; those
"reactionaries" who don't want these features will never turn them on,
or at worst will turn them off in their ~/.emacs.  Puff -- the problem
is gone.

> * Ditto for the UI changes included in the plan. This is, possibly, even
>   more difficult. Once you have write access to the repo you are on your
>   own for changing things (or you can work on your own branch) but some
>   existing users will complain out loud if they are suppossed to add a
>   line to their .emacs for keeping the previous behavior. Think about
>   something that changes some core piece of Emacs philosophy.

See above: start with making it an optional feature that is off by
default.  If it's good, it will eventually be turned on.  There were
enough examples of that in Emacs history.

> > Then start producing code according to that Plan.  There's nothing
> > like a working code to convince non-believers (if there are such among
> > the active developers)
> 
> Sorry, only for the GUI infrastructure, this would be a multi-year
> effort (working an average of 10 hours per week.)

Yeah!  But even a 1000-mile journey begins with a single first step.
If no one will ever make that step, the journey will never end.

In other words, the fact that a significant effort is required is just
a test of the will and motivation of those who are the most profound
critics of the current state of Emacs usability.  If the motivation
and the will power are high enough, they will pass that test with
flying colors.

> But it doesn't matter, because my plan was already rejected.

No, it wasn't.  Don't give up too early.  Most of the complications
and obstacles you see are imaginary, or could made to be so, given
some creative thinking and positive attitude.  Be prepared to listen
to the old guard and respect their opinions, and be prepared to look
for ways to compromise that don't defeat your goals.  It's not that
hard.

> > and there's nothing like a workable plan to attract followers.  If
> > there's anything clear from this confused thread, it's that we sorely
> > need some kind of unified "vision" and specific goals.  Throwing
> > random ideas and critique will get us nowhere.
> 
> I completely agree, but it is in contradiction with what you wrote above
> about every developer scratching it itch.

I was hoping the Plan will attract new developers with the right itch.

Re: Emacs learning curve

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> A few weeks ago I was required to translate an old, small Visual Basic
> application to C#. I was less than thrilled with the job, but anyways
> the first thing was to configure Emacs as a C# editor. 
...
> I gave up
> and tried certain popular IDE, out of despair. 15 minutes later my
> client's application, on its basic inception, was running on the screen,
> mostly thanks to an accurate and fast code completion system that not

MS has spent vast amounts of resources pushing C# and .net as hard as
they can.  It's not surprising that VS has very good C# support.

But C# is a minor niche language in the sort of environments where Emacs
is most popular.  Given relatively limited resources for Emacs
development, and the unpopularity of C#, it's hardly surprising that
Emacs C# support is less good....

-Miles

-- 
Quack, n. A murderer without a license.

Re: Emacs learning curve

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> A few weeks ago I was required to translate an old, small Visual Basic
>> application to C#. I was less than thrilled with the job, but anyways
>> the first thing was to configure Emacs as a C# editor. 
> ...
>> I gave up
>> and tried certain popular IDE, out of despair. 15 minutes later my
>> client's application, on its basic inception, was running on the screen,
>> mostly thanks to an accurate and fast code completion system that not
>
> MS has spent vast amounts of resources pushing C# and .net as hard as
> they can.  It's not surprising that VS has very good C# support.

For the code completion, I don't think that a huge effort is
necessary. The most difficult part is to obtain the semantic info, which
MS does with the compiler and Emacs can do likewise with CEDET/Semantic
(or with a Free C# compiler.) Once you have that, you need the means for
displaying the suggested completions and the associated documentation on
a convenient way. Emacs already supports tooltips for the documentation,
and a floating listbox doesn't seem too hard to do.

This is for the code completion. I dunno about the real-time syntax
checking, the project manager, debugger, refactoring...

The most difficult part is to do it so it produces the Wow! reaction on
the user. His first reaction must be "that's what I want to use."

> But C# is a minor niche language in the sort of environments where Emacs
> is most popular.  Given relatively limited resources for Emacs
> development, and the unpopularity of C#, it's hardly surprising that
> Emacs C# support is less good....

C#, VB, F# are niche languages on the Unix world. But think about
Java. Actually, think about any statically-typed language, or a dynamic
one writing code at the same time the application is running. Once you
work with one of those smart IDEs (count the Free Eclipse and
SharpDevelop IDEs among them) you get addicted to those features and
will consider as inferior choices any editor that lacks them.

Re: Emacs learning curve

[Richard Stallman]

    Or use "scroll-up" where it means scroll down, or use "split-horizontally"
    where it splits vertically ;)

These names are used because they are logical.  scroll-down scrolls
down through the text, and split-horizontally makes two windows that
are horizontal neighbors.

Re: Emacs learning curve

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Or use "scroll-up" where it means scroll down, or use
>     "split-horizontally" where it splits vertically ;)
>
> These names are used because they are logical.  scroll-down scrolls
> down through the text,

No, it doesn't.  It scrolls the text down, moving _up_ through the text
in the process.  So it is "scroll down" but at the same time "scroll up
through".

It does not seem like anybody can remember its direction properly, but
everybody will readily defend as the most logical choice what he thinks
remembering.

-- 
David Kastrup

Re: Emacs learning curve

[Uday S Reddy]

On 7/13/2010 3:10 PM, David Kastrup wrote:

>> These names are used because they are logical.  scroll-down scrolls
>> down through the text,
>
> No, it doesn't.  It scrolls the text down, moving _up_ through the text
> in the process.  So it is "scroll down" but at the same time "scroll up
> through".

What a cool exchange!

I suppose the youngsters can be excused for thinking we are all loonies.

Uday

Re: Emacs learning curve

[grischka]

Richard Stallman wrote:
>     Or use "scroll-up" where it means scroll down, or use "split-horizontally"
>     where it splits vertically ;)
> 
> These names are used because they are logical.  scroll-down scrolls
> down through the text, and split-horizontally makes two windows that
> are horizontal neighbors.

Sure, given this information it makes sense.  It is just that the
same thing called "split-vertically" makes sense even without further
information ;)

--- grischka

Re: Emacs learning curve

[Richard Stallman]

    Sure, given this information it makes sense.  It is just that the
    same thing called "split-vertically" makes sense even without further
    information ;)

For some of us, `split-horizontally' makes sense and the other would
require explanation.

Re: Emacs learning curve

[grischka]

Richard Stallman wrote:
>     Sure, given this information it makes sense.  It is just that the
>     same thing called "split-vertically" makes sense even without further
>     information ;)
> 
> For some of us, `split-horizontally' makes sense and the other would
> require explanation.
> 

Horizon is the line between earth and sky.

--- grischka

Re: Emacs learning curve

[Ted Zlatanov]

On Wed, 14 Jul 2010 13:16:00 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> For some of us, `split-horizontally' makes sense and the other would
RS> require explanation.

It's confusing.  I think split-sideways (or split-side-to-side) and
split-top-to-bottom may be good aliases to the originals.

Ted

Re: Emacs learning curve

[Sean Sieger]

    It's confusing.  I think split-sideways (or split-side-to-side) and
    split-top-to-bottom may be good aliases to the originals.

Still:

Does the splitting `line' get drawn from side-to-side? or the does the
split result in two new windows side-by-each?

Does the splitting `line' get drawn from top-to-bottom ...

Will there always be an aporia---gap between the denomination and the
materiality of this mechanism?

Re: Emacs learning curve

[martin rudalics]

 >     It's confusing.  I think split-sideways (or split-side-to-side) and
 >     split-top-to-bottom may be good aliases to the originals.
 >
 > Still:
 >
 > Does the splitting `line' get drawn from side-to-side? or the does the
 > split result in two new windows side-by-each?
 >
 > Does the splitting `line' get drawn from top-to-bottom ...
 >
 > Will there always be an aporia---gap between the denomination and the
 > materiality of this mechanism?

We should abandon the whole idea of "splitting" and call these, for
example, `create-window', `create-window-on-the-right', ...

Why leave creativity to Renault?  Emacs - créateur de fenêtres!

martin

Re: Emacs learning curve

[Eli Zaretskii]

> Date: Sat, 31 Jul 2010 15:32:38 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> We should abandon the whole idea of "splitting" and call these, for
> example, `create-window', `create-window-on-the-right', ...

In Emacs 24 and later, you cannot safely use "on the right" because
with some R2L scripts it could actually come out on the left...

(Not that Emacs already does that, nor do I think it should, but we
might one day.)

"Side by side" and "above/below" are still the winners.

Re: Emacs learning curve

[martin rudalics]

 > In Emacs 24 and later, you cannot safely use "on the right" because
 > with some R2L scripts it could actually come out on the left...
 >
 > (Not that Emacs already does that, nor do I think it should, but we
 > might one day.)

... invert the meanings of "left" and "right"?
So a R2L script is a L2R script.  Hmmm ...

martin

Re: Emacs learning curve

[Ted Zlatanov]

On Sat, 31 Jul 2010 08:02:24 -0400 Sean Sieger <sean.sieger@gmail.com> wrote: 

SS>     It's confusing.  I think split-sideways (or split-side-to-side) and
SS>     split-top-to-bottom may be good aliases to the originals.

SS> Does the splitting `line' get drawn from side-to-side? or the does the
SS> split result in two new windows side-by-each?

SS> Does the splitting `line' get drawn from top-to-bottom ...

SS> Will there always be an aporia---gap between the denomination and the
SS> materiality of this mechanism?

Words are always imprecise but mixing concepts is sure to confuse users.

I did usability studies for this exact terminology a few years ago so my
proposal comes from testing experience and was much less confusing to
our users.

Ted

Re: Emacs learning curve

[Sean Sieger]

    I did usability studies for this exact terminology a few years ago so my
    proposal comes from testing experience and was much less confusing to
    our users.

Uh-huh.  I meant to only report _my_ experience of that language.  Not
others, and certainly not the interpretation of a group of others
experience.  There is a gap that disappears altogether with something
like create-window-on-the-left, -bottom and so on (I think Eli named 'em
pretty well the other day).

I've said, I can tolerate my world ... perception ... being turned
upside down and my mind keeping up with it:

This afternoon a lighting director facing me will say to me, ``Make the
left cut (holding out her right hand) here,'' and I will instinctively
reach for the shutter on the right side on an ellipsoidal lighting
fixture and push it left through the beam of light while the result will
be for the light beam outside of the instrument to be narrowed from the
left.

The gap between denomination and mechanism is as narrow and functional
as it can be.

I won't repeat how my mind processes the current language used to name a
function that creates new windows, let alone how proposed language names
... narrows the gap between the name of the function and the resulting
new window.

I just doesn't make sense to me to argue the point.  And new users??
What a phantom.  Shoot.  At least we agree on the abysmal nature of
language.

RE: Emacs learning curve

[grischka]

 > So now you will need to make clear when you mean the cursor as the visible
 > thing that is on a character (display artifact) and when you mean the
 > position before that character.

Users don't need to make such distinction and hackers don't have to (as
in an integer world there is no position before a character other than
the position of the character before).

--- grischka

RE: Emacs learning curve

[grischka]

 > Perhap you naturally drive on the left.  I naturally drive on the right.  I am
 > not making the argument that only driving on the right is "natural".  Would you
 > be making such an argument for driving on the left perchance?

There is much less difference between left and right than between
up and down.  Even in politics ;)

 > I did not say that humans identify only with the document.  They
 > _can_ do so, and in some applications/contexts, they do do so.

No, they don't and they can't.  Because the document is the ultimate
object in the whole setting.  If you identify with it then there is
nothing left to interact.

--- grischka

RE: Emacs learning curve

[grischka]

> It depends on the application and what the user is doing, where s?he "naturally"
 > places her point of view.  In some graphics domains it sometimes makes sense to
 > take the point of view of the paper (object) and not the view port; in other
 > contexts, vice versa.
 >
 > "The human" is neither the view port nor the paper, and can identify with
 > either, whichever is more convenient/pertinent to the task at hand.

The human can identify with the paper?  What drug does that?

--- grischka

RE: Emacs learning curve

[Drew Adams]

> > It depends on the application and what the user is doing, 
> > where s?he "naturally" places her point of view.  In some
> > graphics domains it sometimes makes sense to take the point
> > of view of the paper (object) and not the view port; in other
> > contexts, vice versa.
> >
> > "The human" is neither the view port nor the paper, and 
> > can identify with either, whichever is more convenient/pertinent
> > to the task at hand.
> 
> The human can identify with the paper?  What drug does that?

Ever drag the page around in Adobe Reader or Google Maps or Google Earth?

When you drag an object you are identifying with the object, not the window.
Dragging is a kind of scrolling.

The point is that both points of view can be useful and both are used. The
wikipedia page for Scrolling refers to both in its very first paragraph:

 "In computer graphics, movies, television, and other kinetic
  displays, scrolling is sliding text, images or video across a
  monitor or display.  Scrolling, as such, does not change the
  layout of the text or pictures, or but incrementally moves
  (pans or tilts) the user's view across what is apparently a
  larger image that is not wholly seen." -
http://en.wikipedia.org/wiki/Scrolling

Sliding the text (first sentence) vs moving the view (second sentence).  Neither
has a monopoly wrt scrolling.  They are two different vantage points.  And
sometimes the scrolling affordances or tools we use emphasize one or the other.

* A scroll bar typically is associated with the view, not the paper: when you
drag it down, the view moves down (and the paper up).

* A hand pointer typically is associated with the paper, not the view; when you
drag it down, the paper moves down (and the view up).

There is nothing new (and nothing controversial) about any of this.  It is as
old as the hills.  What drug makes you see things only one way?

Re: Emacs learning curve

[Uday S Reddy]

On 7/14/2010 7:05 PM, Drew Adams wrote:


> Dragging is a kind of scrolling.

If you say so!

But you have a useful idea there.  If we make aliases drag-up and drag-down for 
scroll-up and scroll-down, I suppose everybody can be happy.

> The point is that both points of view can be useful and both are used. The
> wikipedia page for Scrolling refers to both in its very first paragraph:

I suppose you have clearly made the point that "scrolling" is not precise 
enough a word to hang our coats on.  It is better to focus on "up" and "down" 
and see if they are human-centered.  According to you, the human user 
identifies with the document being edited and, therefore, scrolling "up" feels 
perfectly natural for moving up.  I think you would be in a minority if you 
think this way.  It feels strange to most of us.

For the vast majority of Emacs users, these names don't matter an inch because 
they use the key bindings.  Neither for me.  But, when I started using speech 
recognition, I had to vocalize the commands, and I really couldn't bring myself 
to say "scroll up" when I wanted to move down the document.  So, I defined a 
voice command "page down" for scroll-up and, when I found it hard on my voice, 
just called it "scroll down".

Cheers,
Uday

RE: Emacs learning curve

[Drew Adams]

> > Dragging is a kind of scrolling.
> 
> If you say so!

Dragging is simply one way to make the view and paper move relative to each
other. Have you used applications where dragging can optionally be limited to
only purely vertical or only purely horizontal, in addition to being free-rein?
(E.g. holding a modifier key such as shift while dragging.)

There are many ways to initiate/effect scrolling, as I'm sure you would agree.
Even the history of scroll bars alone is rich with variation in approach and
behavior.

No doubt you and I both would find much of it unnatural now, though it appeared
natural enough to those using it or experimenting with it at the time.  There
are even arguments here about Emacs scroll bar behavior from time to time.

Perhap you naturally drive on the left.  I naturally drive on the right.  I am
not making the argument that only driving on the right is "natural".  Would you
be making such an argument for driving on the left perchance?

> According to you, the human user identifies with the
> document being edited

No, I did not say that.  I said that humans are capable of identifying with
_either_ the window or the document when they move relative to each other.  I
did not say that humans identify only with the document.  They _can_ do so, and
in some applications/contexts, they do do so.

Re: Emacs learning curve

[Richard Stallman]

    * A scroll bar typically is associated with the view, not the paper: when you
    drag it down, the view moves down (and the paper up).

    * A hand pointer typically is associated with the paper, not the view; when you
    drag it down, the paper moves down (and the view up).

When these command names were chosen, Emacs had neither of those,
and both analyses made sense. I chose to identify them with the paper.

Since Emacs has scroll bars, and no hand pointers, it would be more
consistent today if the scroll commands were named identifying with
the view.  The change could be made compatibly by choosing new names
such as scroll-view-down and scroll-view-up.

Still, I am not sure it is worth the transient.  Ordinary use of Emacs
doesn't involve knowing the names of these commands, so I don't think
they could be a real obstacle to learning to use it.

Re: Emacs learning curve

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Since Emacs has scroll bars, and no hand pointers, it would be more
> consistent today if the scroll commands were named identifying with
> the view.  The change could be made compatibly by choosing new names
> such as scroll-view-down and scroll-view-up.
>
> Still, I am not sure it is worth the transient.  Ordinary use of Emacs
> doesn't involve knowing the names of these commands, so I don't think
> they could be a real obstacle to learning to use it.

Even it's not worth any real "change", I think just adding the more
explicitly named command names (with the non-explicit names as aliases)
would be generally very useful for people that want to bind them
themselves or use them in lisp.  Despite using emacs for decades, I'm
_still_ a little confused by the direction of "scroll-up"... :O (which I
suppose confirms your point that nobody actually looks at them :).

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: Emacs learning curve

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     * A scroll bar typically is associated with the view, not the
>     paper: when you 
>     drag it down, the view moves down (and the paper up).
>
>     * A hand pointer typically is associated with the paper, not the
>     view; when you
>     drag it down, the paper moves down (and the view up).
>
> When these command names were chosen, Emacs had neither of those, and
> both analyses made sense. I chose to identify them with the paper.

> Since Emacs has scroll bars, and no hand pointers, it would be more
> consistent today if the scroll commands were named identifying with
> the view.

No, it wouldn't.  You can't exchange the "move in text" view with the
"move the canvas" view interchangeably because Emacs definitely moves
the canvas.  Any point movement associated with it happens as a side
effect of keeping point on-screen.  So if for example you put point in
the middle of your window, then use C-u 3 next (bound to
scroll-up-command), then the canvas will move 3 lines up, but point will
stay put at its buffer position.  The only perceived motion here is
indeed up.

Without the equivalent of some scroll-in-place functionality, the scroll
commands are _not_ a reliable way of moving point through the buffer.
You could claim they are a reliable way of moving window-start through
the buffer.  But I don't think that a user really thinks of window-start
as a separate user-controlled entity.

-- 
David Kastrup

RE: Emacs learning curve

[grischka]

From: Drew Adams
> But with the point of view of splitting (the verb), the answer unambiguosly
> agrees with Emacs terminology - you do in fact split the window horizontally.
> Take an axe, hold it horizontally, and split the window.  Go ahead.  You get two
> windows disposed vertically, one above the other.  It is simply incorrect to say
> that "`split-horizontally' splits vertically".  Bad one, I'm afraid.

Sure, the answer that you give is unambiguous, but unlike you say it does not
agree with Emacs terminology.

> (Disclaimer: I was not involved in the Emacs choices for scroll "up" or split
> "horizontally".)

Maybe not ;)

RE: Emacs learning curve

[Drew Adams]

> > But with the point of view of splitting (the verb), the 
> > answer unambiguosly agrees with Emacs terminology - you do
> > in fact split the window horizontally.  Take an axe, hold it
> > horizontally, and split the window.  Go ahead.  You get two
> > windows disposed vertically, one above the other.  It is 
> > simply incorrect to say that "`split-horizontally' splits
> > vertically".  Bad one, I'm afraid.
> 
> Sure, the answer that you give is unambiguous, but unlike you 
> say it does not agree with Emacs terminology.

I stand corrected.  Thank you!

What I said is correct about the meaning of the name.  And Emacs is wrong about
it.  Emacs, like all of us, does not always speak the best English.

That just goes to show, however, that the command name is not so terribly
important for this kind of command.  Just as for the PageDown
(`scroll-up-command') example I gave, a user will not spend much time with the
actual command name `split-window-horizontally'.  And _I_ obviously didn't spend
enough time (zero) testing the name against the behavior.  mea culpa.

And just as in the case of the scroll-up example, the doc here makes things
clear.  The doc does not say that the command `split-window-horizontally' splits
the window horizontally (because, alas, it does not!).  The doc says that it
splits the window so that the result is two windows side by side, i.e. arrayed
horizontally.  The doc is correct but the command name is incorrect.

So this is indeed a case where a poor choice was made for the command name.
Instead of trying to change the name as a fix, a (successful) attempt was made
to rectify things in the doc.  That's probably the best that can be done at this
point, given that this function is not only a user command (where the name is
not so important).  It is also a commonly used Lisp function.  Maybe it could be
aliased away, but I'm not sure it's worth it.

I was mistaken in thinking that you were asking for the behavior that Emacs in
fact provides, and that by explaining the name I was defending the behavior that
it does not, alas, provide.  We agree now that `split-window-horizontally' does
_not_ do what it says - it splits the window vertically.

As I said, words do matter, and it is sometimes the case that less than ideal
wording is chosen for something, right from the beginning.  If it is poorly
worded doc, that can be fixed and it often is, thanks to the efforts of multiple
contributors (users, developers).  But when there is a poorly named function,
variable, face, or whatever, the ability to correct the name is more limited.
Even there, it does happen (sometimes by attrition/obsoletion or aliasing).

Things (bugs) like this need to be handled on a case-by-case basis.  What should
be done about the particular case of the command names
`scroll-(up|down)-command' at this point?  Dunno how easy it would be to change
them (they certainly cannot just be reversed).  My guess (only a guess) is that
these names will remain with us for a long while.

But that's not cause for much concern.  We really do have bigger fish to fry.
It is not the backward choice of a command name for window splitting that puts
Emacs in contradiction with other apps or makes Emacs difficult to learn.  I
seriously doubt that new users will stumble for long over the
vertical/horizontal command names here.

FWIW - Just in case you need a demonstration of the fact that I do take words
seriously and I feel strongly that Emacs can and should improve its verbal UI
(doc, names), take a look at today's back-and-forth for bug #6591.  That will
also show that I am well aware (!) how difficult it can be to advance the Emacs
schmilblick.  And it will show that I somehow continue to believe that people
can learn, even in the face of apparent futility.  Still tilting at windmills,
no doubt.

Thanks for the correction.

Re: Emacs learning curve

[MON KEY]

On Sat, 10 Jul 2010 10:36:46 +0000 Tom wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> Doesn't the manual help discovering what Emacs can do?  Why do you
>> need to search the Internet when you have most of the stuff right
>> under your fingertips?
>

> Using established terminology would help here.

Which established terminology the _new_ stuff or the _old_ stuff that
the new stuff stands upon? See DLW email below.

> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?

Yes, b/c it is an established standing convention for at least 30 yrs.
One that did much to establesh 'modern' GUI's Lisa/Nextstep/x11 etc.

> Why do we call the cursor the point? And so on.

See DLW email below.

> These relics of old terminology should be updated to the accepted modern
> variants to make the documentation is more accessible for emacs newbies.

I truly believe that w/re the manual, it would be exceedingly
beneficial if it did a better job indicating and celebrating the long
history of both Emacs and the various lisp dialects in general. I also
believe that where it does so already it could do better to avoid certain
outmoded political perspectives. Which is to say GNU won -- part of
being a good winner is knowing how to honor those defeated).

New and old Emacs users alike should be reminded from whence we
came. It should be a source of pride and a mark of prestige that Emacs
has endured the test of time.

Following from the file named: mit/extract/nzwei/info.zwei
as extracted from the archive at:
http://www.unlambda.com/download/mit/mit-20041117.tar.gz
:SEE (URL `http://www.unlambda.com/lisp/mit.page')

It is worth noting that the comparison made below between Emacs and
Zwei is w/re to what were already circa Summer 1980 divergent
implementations of _established_ convention.

,----
| Date: 19 JUL 1980 0411-EDT
| From: DLW at MIT-AI (Daniel L. Weinreb)
| Subject: Differences between ZWEI and EMACS
| To: INFO-ZWEI at MIT-AI
|
| There is a subtle difference between ZWEI and EMACS that many people
| probably don't know about: while EMACS has a "mark PDL", ZWEI has a
| "point PDL".  The EMACS mark is the same as the top of the mark PDL,
| but the ZWEI mark has nothing to do with the point PDL.  The reason for
| this was so that setting the mark for purposes of defining a region
| would not interfere with the saved buffer pointers on the PDL; that
| always bothered me in EMACS and I considered the ZWEI method an
| improvement.
|
| However, it is not fully compatible with EMACS.  One difference that
| may cause some users trouble is that certain commands which, in EMACS,
| set the mark, and thus push on the mark PDL, do not affect the ZWEI
| point PDL.  In particular, the "Yank" and "Insert Buffer" commands in
| ZWEI set the mark to the other end of the inserted region, but do not
| affect the point PDL.  In EMACS, you can get to the other side of
| the inserted text either by swapping point and mark (with c-X c-X)
| or by popping the mark PDL (c-Space or c-@); in ZWEI only the
| former works.
|
| Another difference between EMACS and ZWEI is that in ZWEI, the region
| either "exists" or "does not exist"; there is no such concept in EMACS.
| When the region exists, it is underlined; when it doesn't exist, the
| underlining goes away.  The main point of this is to keep the
| underlining from being visually distracting when the user is not
| concerned about the region.  It also keeps region-munging commands
| (such as Uppercase Region or Fill Region) from happening unexpectedly
| if your fingers slip.  Usually the region is created when you set the
| mark, and usually it goes away when you give any command that does
| something more complex than moving the point; the mouse can also create
| the region.  But even when the region does not exist, the mark is still
| there, albeit invisibly as in EMACS.  If you want to turn on the region
| without affecting the current position of mark, you can use c-X c-X,
| which is what some people usually use in EMACS to find out where the
| mark is.
|
| Also, in a few special cases, some commands that refer to the region
| will still work even if the region does not exist.  In particular, the
| Kill Region (c-W) command will work immediately following a yanking
| command (such as c-Y), so that you can kill what you just yanked if you
| don't like it.
`----

--
/s_P\

Re: Emacs learning curve

[Lennart Borgman]

On Sat, Jul 10, 2010 at 9:27 PM, MON KEY <monkey@sandpframing.com> wrote:
> On Sat, 10 Jul 2010 10:36:46 +0000 Tom wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> Doesn't the manual help discovering what Emacs can do?  Why do you
>>> need to search the Internet when you have most of the stuff right
>>> under your fingertips?
>>
>
>> Using established terminology would help here.
>
> Which established terminology the _new_ stuff or the _old_ stuff that
> the new stuff stands upon? See DLW email below.

Just do a reality check.

Re: Emacs learning curve

[MON KEY]

On Sat, Jul 10, 2010 at 10:16 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
>> Which established terminology the _new_ stuff or the _old_ stuff that
>> the new stuff stands upon? See DLW email below.
>
> Just do a reality check.
>

OK, so I went and checked. Reality is doing just fine... she asked me
to tell you that she misses you and wanted you to see this:

,----
|
| In 1990 at my job we had an asshole consultant
| (a typical MS worshipper) who came in to deliver a program.
| My colleague Anu and I were debating a UI feature, and the
| consultant said,
|  "Did you read your CUA?"
|
| We found it on a shelf and handed it to him.
| It still had the shrink-wrap on it.
|
| Anu said,
|  "Well, we read it.
|   But then we put the shrink-wrap back on it."
|
`---- (URL `http://www.c2.com/cgi/wiki?CommonUserAccess')

--
/s_P\

Re: Emacs learning curve

[Lennart Borgman]

On Sun, Jul 11, 2010 at 5:39 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Sat, Jul 10, 2010 at 10:16 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>>
>>> Which established terminology the _new_ stuff or the _old_ stuff that
>>> the new stuff stands upon? See DLW email below.
>>
>> Just do a reality check.
>>
>
> OK, so I went and checked. Reality is doing just fine... she asked me
> to tell you that she misses you and wanted you to see this:
>
> ,----
> |
> | In 1990 at my job we had an asshole consultant
> | (a typical MS worshipper) who came in to deliver a program.
> | My colleague Anu and I were debating a UI feature, and the
> | consultant said,
> |  "Did you read your CUA?"
> |
> | We found it on a shelf and handed it to him.
> | It still had the shrink-wrap on it.
> |
> | Anu said,
> |  "Well, we read it.
> |   But then we put the shrink-wrap back on it."
> |
> `---- (URL `http://www.c2.com/cgi/wiki?CommonUserAccess')


A bit fun, but this kind of humor does only attract those that does
not want to think about the real issue. It tends to lock people into
corners by saying "look how good we are".

The humor that works and releases our thinking capacity is that kind
of humor that is free from contempt. That is very effective. (And much
harder for us to find.)

It is also needed to help us stay well, both physically and mentally.

This is on my reading list if someone is more interested in the subject:

  Grumet GW. Laughter: nature's epileptoid catharsis. Psychol Rep.
1989 Dec;65(3 Pt 2):1059-78.
  http://www.ncbi.nlm.nih.gov/pubmed/2695954

Re: Emacs learning curve

[Noah Lavine]

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

Everyone's experience could potentially be different, of course, but I am someone who started learning Emacs recently, and perhaps you would like to hear the things I found difficult.

The big issue, I think, is discovering what Emacs can do. I know that Emacs is *potentially* extremely powerful, but I don't know enough to make use of this power. The Emacs Starter Kit showed me some things, and I found a few more through different web pages, but I think I still don't know very much. I don't know where I would find Emacs features that are useful for me.

One issue is that a lot of good Elisp code is scattered around the internet, and it's hard to find. The future integration of package.el should help with that a lot. (Although the package.el interface still needs better descriptions of what packages do.)

Another issue is that there are a lot of commands to learn. Perhaps one solution would be to emphasize more general functions over specific ones. For instance, you don't need isearch-forward when you've got isearch-forward-regexp.

Finally, it would be interesting to compare the experiences of different Emacs newbies like myself to see if there are similarities, but that could be quite a project.

I hope these things help
Noah Lavine

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

Re: Emacs learning curve

[Eli Zaretskii]

> From: Noah Lavine <noah549@gmail.com>
> Date: Fri, 9 Jul 2010 15:12:51 -0400
> Cc: emacs-devel@gnu.org
> 
> The big issue, I think, is discovering what Emacs can do. I know that
> Emacs is *potentially* extremely powerful, but I don't know enough to
> make use of this power. The Emacs Starter Kit showed me some things, and
> I found a few more through different web pages, but I think I still
> don't know very much. I don't know where I would find Emacs features
> that are useful for me.

Doesn't the manual help discovering what Emacs can do?  Why do you
need to search the Internet when you have most of the stuff right
under your fingertips?

Re: Emacs learning curve

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Doesn't the manual help discovering what Emacs can do?  Why do you
> need to search the Internet when you have most of the stuff right
> under your fingertips?
> 

Using established terminology would help here.

Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?
Why do we call the cursor the point? And so on.

These relics of old terminology should be updated to the accepted modern
variants to make the documentation is more accessible for emacs newbies.

Re: Emacs learning curve

[Eli Zaretskii]

> From: Tom <levelhalom@gmail.com>
> Date: Sat, 10 Jul 2010 10:36:46 +0000 (UTC)
> 
> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?

From the Emacs manual:

  * Killing::	        Killing (cutting) text.
  * Yanking::	        Recovering killed text.  Moving text. (Pasting.)

and then:

    12 Killing and Moving Text
    **************************

    "Killing" means erasing text and copying it into the "kill ring", from
    which you can bring it back into the buffer by "yanking" it.  (Some
    applications use the terms "cutting" and "pasting" for similar
    operations.)

> Why do we call the cursor the point?

Because point is not the cursor.  The cursor only shows the position
of point in the visible windows (and on character terminals, only in
the single selected window).  We still need a term for the ``current
position in the buffer''.

> These relics of old terminology should be updated to the accepted modern
> variants to make the documentation is more accessible for emacs newbies.

And then they will be queuing up to start using Emacs, no doubt.

Re: Emacs learning curve

[Lennart Borgman]

On Sat, Jul 10, 2010 at 1:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Tom <levelhalom@gmail.com>
>> Date: Sat, 10 Jul 2010 10:36:46 +0000 (UTC)
>>
>> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?
>
> From the Emacs manual:
>
>  * Killing::           Killing (cutting) text.
>  * Yanking::           Recovering killed text.  Moving text. (Pasting.)
>
> and then:
>
>    12 Killing and Moving Text
>    **************************
>
>    "Killing" means erasing text and copying it into the "kill ring", from
>    which you can bring it back into the buffer by "yanking" it.  (Some
>    applications use the terms "cutting" and "pasting" for similar
>    operations.)

I think it is quite clear from this text that there is no logical
reason any more not to use the common terms copy/cut/paste.

>> Why do we call the cursor the point?
>
> Because point is not the cursor.  The cursor only shows the position
> of point in the visible windows (and on character terminals, only in
> the single selected window).  We still need a term for the ``current
> position in the buffer''.

So the term used for cursor is really "window point". Which could be
changed to "cursor".

>> These relics of old terminology should be updated to the accepted modern
>> variants to make the documentation is more accessible for emacs newbies.
>
> And then they will be queuing up to start using Emacs, no doubt.

I have several times pointed out that it is the sum of the differences
that makes it difficult for new users. The stories about users wanting
to try but giving up partly because they realize they do not have time
to go through all the differences are frequent.

Re: Emacs learning curve

[Tom]

Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> 
> I have several times pointed out that it is the sum of the differences
> that makes it difficult for new users. The stories about users wanting
> to try but giving up partly because they realize they do not have time
> to go through all the differences are frequent.
> 

Exactly. Emacs should be similar to popular tools in those respects
where the difference is arbitrary and does not add anything of value.

Yank is a good example of this. Paste is just as good terminology and
it is widely accepted, so it should be used instead and this term
should appear in the Info menu, not Yank.

One less thing to explain to new users and surely more examples similar
to this can be found.

Re: Emacs learning curve

[Alfred M. Szmidt]

I doubt that words like yank, kill, point, etc hinder new users from
using emacs.  The argument seems extremly weak.

Re: Emacs learning curve

[Deniz Dogan]

2010/7/10 Alfred M. Szmidt <ams@gnu.org>:
> I doubt that words like yank, kill, point, etc hinder new users from
> using emacs.  The argument seems extremly weak.
>
>

When I converted from Vim I was surprised when I learned that in
Emacs yanking means pasting. In Vim it means copying. Neither of
the uses made much sense to me.

What I'm trying to say is that yanking could mean anything. It is
not intuitive to anyone that yanking means inserting text that
was previously removed (sorry, murdered). The same applies for
killing and especially "point". Nice job on the last one.

The only reason I can think of to keep the current names of the
operations is that the underlying functions are named this way as
well and it would be impossible to simply change those now.

-- 
Deniz Dogan

Re: Emacs learning curve

[Lennart Borgman]

On Sat, Jul 10, 2010 at 6:23 PM, Alfred M. Szmidt <ams@gnu.org> wrote:
> I doubt that words like yank, kill, point, etc hinder new users from
> using emacs.  The argument seems extremly weak.


Please try to be more specific. Exactly what argument is it you think
of? Exactly why do you think it is weak?

Re: Emacs learning curve

[Sean Sieger]

    Please try to be more specific. Exactly what argument is it you think
    of? Exactly why do you think it is weak?

That your line of thinking in this thread has gone nearly unchecked up
to this point is exasperating ... that you pose these questions as if
everything is okay.  Nothing is okay.  The GNU Emacs Manual is one of
the cool-daddiest texts that I've ever read for EXACTLY the reason that
it's in it's OWN stinking world ... that GNU Emacs is in it's own world
to the degree that it is.

Sameness!

You're so full of shit!

CUA??  Viper??  I don't get it ...

  -- Sean  ``The Unapologetic Reactionary Biggot''

Re: Emacs learning curve

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 561 bytes --]

   > I doubt that words like yank, kill, point, etc hinder new users
   > from using emacs.  The argument seems extremly weak.

   Please try to be more specific. Exactly what argument is it you
   think of? Exactly why do you think it is weak?

I find it weak since it side tracks the real issue, namley how to use
emacs more efficiently when you are a new user.  What words you use
won't hinder that.  You will always encounter new definitions for
words, if one goes about renaming everything to what is currently
popular it will only cause mass confusion.

Re: Emacs learning curve

[Lennart Borgman]

On Sun, Jul 11, 2010 at 10:33 AM, Alfred M. Szmidt <ams@gnu.org> wrote:
>   > I doubt that words like yank, kill, point, etc hinder new users
>   > from using emacs.  The argument seems extremly weak.
>
>   Please try to be more specific. Exactly what argument is it you
>   think of? Exactly why do you think it is weak?
>
> I find it weak since it side tracks the real issue, namley how to use
> emacs more efficiently when you are a new user.

Thanks. I see what you mean. There are different opinions on this. My
view is that raising complexity makes it much, much harder to learn.
This is not a linear growth. Talking about working memory could
perhaps make it easy to understand for many people here. Our working
memory is very limited. (Much can be said about this, but I do not
know if it is confusing here. For example one thing to say is that
frustration may use part of it more constantly.)

> What words you use
> won't hinder that.  You will always encounter new definitions for
> words, if one goes about renaming everything to what is currently
> popular it will only cause mass confusion.

The words matter since it raises complexity to use unfamiliar words.

Re: Emacs learning curve

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 679 bytes --]

   > What words you use won't hinder that.  You will always encounter
   > new definitions for words, if one goes about renaming everything
   > to what is currently popular it will only cause mass confusion.

   The words matter since it raises complexity to use unfamiliar words.

Recently I've started using Eclipse as part of my job, and it uses
several words whos definition I'm not familiar with; for example view,
perspective and workspace.  I've used Eclipse daily now for four
months, and the terminology still doesn't stick for me.  Does this
make Eclipse harder to use? Not at all.  Does it make it more complex?
Not really.  They are just words, with some meaning.

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Jul 12, 2010 at 6:54 PM, Alfred M. Szmidt <ams@gnu.org> wrote:
>   > What words you use won't hinder that.  You will always encounter
>   > new definitions for words, if one goes about renaming everything
>   > to what is currently popular it will only cause mass confusion.
>
>   The words matter since it raises complexity to use unfamiliar words.
>
> Recently I've started using Eclipse as part of my job, and it uses
> several words whos definition I'm not familiar with; for example view,
> perspective and workspace.  I've used Eclipse daily now for four
> months, and the terminology still doesn't stick for me.  Does this
> make Eclipse harder to use? Not at all.  Does it make it more complex?
> Not really.  They are just words, with some meaning.

You say it does not make it more complex to you. That is ok of course.
It is how you experience it.

But consider a person who have used Eclipse, is familiar with the
words "view", "perspective" and "workspace". It that person want to
try Emacs instead he might try a quick look at the documentation and
there he searches for these words, since those happens to be important
to him/her.

Woldn't that be a bit harder if different words where used in Emacs
for the same things?

Re: Emacs learning curve

[joakim]

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

> On Mon, Jul 12, 2010 at 6:54 PM, Alfred M. Szmidt <ams@gnu.org> wrote:
>>   > What words you use won't hinder that.  You will always encounter
>>   > new definitions for words, if one goes about renaming everything
>>   > to what is currently popular it will only cause mass confusion.
>>
>>   The words matter since it raises complexity to use unfamiliar words.
>>
>> Recently I've started using Eclipse as part of my job, and it uses
>> several words whos definition I'm not familiar with; for example view,
>> perspective and workspace.  I've used Eclipse daily now for four
>> months, and the terminology still doesn't stick for me.  Does this
>> make Eclipse harder to use? Not at all.  Does it make it more complex?
>> Not really.  They are just words, with some meaning.
>
> You say it does not make it more complex to you. That is ok of course.
> It is how you experience it.
>
> But consider a person who have used Eclipse, is familiar with the
> words "view", "perspective" and "workspace". It that person want to
> try Emacs instead he might try a quick look at the documentation and
> there he searches for these words, since those happens to be important
> to him/her.
>
> Woldn't that be a bit harder if different words where used in Emacs
> for the same things?

You are arguing in general terms. I think arguing specifics might be
more fruitful.

For instance, lets assume Emacs will use the terms cut and paste instead
of killing/yanking, what will be the consequences?

- some new users might maybe start using Emacs
- all the emacs documentation would need to be changed
- the Emacs lisp api needs to be changed
- old code will break
- 3rd party code will break

As opposed to status quo:
- Some new users will wonder why cutting and pasting wont work like they
are used to. They might then RTFM and find out that Emacs does things
differently, but they can use CUA mode if they want to.

So, IMHO, this specific case will be a lot of pain for little gain.

OTOH, when we introduce a new concept in Emacs that is already well
known in other environments, like "tabs" we should call them tabs and
not pseudo-frames, or somesuch. 

BTW as an anecdote, I had no trouble learning my daughter to do a
specific task in Emacs. She uses the computer a lot, but only the mouse
for copy/paste, so using the Emacs bindings for the task in question was
in fact easier than she was used to.

-- 
Joakim Verona

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Jul 12, 2010 at 7:45 PM,  <joakim@verona.se> wrote:
>
> For instance, lets assume Emacs will use the terms cut and paste instead
> of killing/yanking, what will be the consequences?
>
> - some new users might maybe start using Emacs

Yes.

> - all the emacs documentation would need to be changed

A small exaggeration perhaps .. ;-)

> - the Emacs lisp api needs to be changed
> - old code will break
> - 3rd party code will break

I would expect there to be aliases for backward compatibility.

I also expect this change not to happen ;-)

Re: Emacs learning curve

[David Kastrup]

joakim@verona.se writes:

> For instance, lets assume Emacs will use the terms cut and paste instead
> of killing/yanking, what will be the consequences?
>
> - some new users might maybe start using Emacs
> - all the emacs documentation would need to be changed
> - the Emacs lisp api needs to be changed
> - old code will break
> - 3rd party code will break

- new users will stop using Emacs altogether since they won't be able to
  remember the arbitrary keybindings C-k (M-k C-M-k ...) for cut and C-y
  for paste.

-- 
David Kastrup

Re: Emacs learning curve

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1513 bytes --]

   > Recently I've started using Eclipse as part of my job, and it
   > uses several words whos definition I'm not familiar with; for
   > example view, perspective and workspace.  I've used Eclipse daily
   > now for four months, and the terminology still doesn't stick for
   > me.  Does this make Eclipse harder to use? Not at all.  Does it
   > make it more complex?  Not really.  They are just words, with
   > some meaning.

   You say it does not make it more complex to you. That is ok of
   course.  It is how you experience it.

   But consider a person who have used Eclipse, is familiar with the
   words "view", "perspective" and "workspace". It that person want to
   try Emacs instead he might try a quick look at the documentation
   and there he searches for these words, since those happens to be
   important to him/her.

   Woldn't that be a bit harder if different words where used in Emacs
   for the same things?

If we can assume that a new emacs user has followed the tutorial --
which I hink is a fair assumption, then the user will know what those
terms mean in the context of emacs.  If the user is still confused
after reading the tutorial, then that is a bug in the tutorial, not in
the terminology we use.

The different terminology does make it harder at times to communicate,
but it doesn't hinder one from using emacs (or any other program),
when you do need to explain something to someone you can always use
baby-talk: that knob, do you know how to frob it so that it bobs?

RE: Emacs learning curve

[Drew Adams]

>    > What words you use won't hinder that. You will always encounter
>    > new definitions for words, if one goes about renaming everything
>    > to what is currently popular it will only cause mass confusion.
> 
>    The words matter since it raises complexity to use 
>    unfamiliar words.
> 
> Recently I've started using Eclipse as part of my job, and it uses
> several words whos definition I'm not familiar with; for example view,
> perspective and workspace.  I've used Eclipse daily now for four
> months, and the terminology still doesn't stick for me.  Does this
> make Eclipse harder to use? Not at all.  Does it make it more complex?
> Not really.  They are just words, with some meaning.

Yes, words matter.  Yes, we should keep an eye out for whatever might help users
use Emacs better.

But no, choice of words is not what is _most_ important.  If the features that
people need are there, the word will spread and people will learn to use it.
IOW, what you said is right on.

Obviously, there is no reason to choose words perversely (e.g. use "red" when we
mean green). Or use words sloppily (e.g. sometimes use "red" for green and
sometimes use "green" for green).

And obviously we should make both the UI and the doc as clear and easy to
discover and use as possible.

But if Emacs has a killer mousetrap then users _will_ find and use it.  Same for
Eclipse or Textmate or any other tool.  Improving Emacs had better start by
improving what it can do and how you can do it, not just by the words used to
describe that.

And yes, I'm someone who does care about the words very much - more than most
people.  The better the product, especially its user interface, the less doc is
important and necessary to fill the gap and explain the product.  It does not
matter whether it's a toaster or a software app.

Analogy (not really the same thing, but it is suggestive):  Remember those
experiments where people put on special glasses that flip their vision
vertically - everything looks upside down.  In a relatively short time their
brains adapt completely, so they actually see everything rightside up.

http://www.graphpaper.com/2007/10-19_the-user-experience-flip-mode

http://wearcam.org/tetherless/node4.html

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Jul 12, 2010 at 7:48 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> Analogy (not really the same thing, but it is suggestive):  Remember those
> experiments where people put on special glasses that flip their vision
> vertically - everything looks upside down.  In a relatively short time their
> brains adapt completely, so they actually see everything rightside up.

Maybe that is what happens to old time Emacs users ... ;-)

(Actually I believed it took fourteen days rather than five days to
accommodate to that but I can't find my book on that now.)

Probably something similar is true about motor skills too though I am
not sure. However there will still be the burden of keeping track of
where you are at the same time so you can switch your behavior
according to that.

Whether such burdens are always negative is another thing. It might be
brain training instead. However for new users I think it is an
unnecessary trouble.

Re: Emacs learning curve

[Tom]

Alfred M. Szmidt <ams <at> gnu.org> writes:

> 
> I doubt that words like yank, kill, point, etc hinder new users from
> using emacs.  The argument seems extremly weak.
> 
> 

As Lennart said before the little things add up. The more unfamiliar 
things the new user encounters the more time and effort he needs to 
invest to try emacs and it can be a turn off.

There is no reason to use the word yank for an operation which practically
every other system calls paste. It's one of those totally unnecessary 
roadblocks for newbies in emacs.

Re: Emacs learning curve

[Bernardo Barros]

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

Reasons to change: there is not a very strong reason to fight for a mere
terminology as if this terminology would do something for us. It doesn't do
anything positive. As a text editor with a long history it has to change, it
will probably survive existent hardware and operating systems, but it can`t
forget what hardware and the standards that happens to occur at a preset
time. I think this is important for Emacs as a eternal uberhardware being.


2010/7/10 Tom <levelhalom@gmail.com>

> Alfred M. Szmidt <ams <at> gnu.org> writes:
>
> >
> > I doubt that words like yank, kill, point, etc hinder new users from
> > using emacs.  The argument seems extremly weak.
> >
> >
>
> As Lennart said before the little things add up. The more unfamiliar
> things the new user encounters the more time and effort he needs to
> invest to try emacs and it can be a turn off.
>
> There is no reason to use the word yank for an operation which practically
> every other system calls paste. It's one of those totally unnecessary
> roadblocks for newbies in emacs.
>
>
>
>
>

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

Re: Emacs learning curve

[David Kastrup]

Tom <levelhalom@gmail.com> writes:

> Alfred M. Szmidt <ams <at> gnu.org> writes:
>
>> 
>> I doubt that words like yank, kill, point, etc hinder new users from
>> using emacs.  The argument seems extremly weak.
>> 
>> 
>
> As Lennart said before the little things add up. The more unfamiliar 
> things the new user encounters the more time and effort he needs to 
> invest to try emacs and it can be a turn off.
>
> There is no reason to use the word yank for an operation which practically
> every other system calls paste. It's one of those totally unnecessary 
> roadblocks for newbies in emacs.

Au contraire.  If the operations were named "cut" and "paste", the
newbie would be completely without mnemonics for C-k, C-y and their ilk.

-- 
David Kastrup

Re: Emacs learning curve

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> >
> > There is no reason to use the word yank for an operation which practically
> > every other system calls paste. It's one of those totally unnecessary 
> > roadblocks for newbies in emacs.
> 
> Au contraire.  If the operations were named "cut" and "paste", the
> newbie would be completely without mnemonics for C-k, C-y and their ilk.
> 


This could be the other part of making Emacs more easy to use for
newbies.

For cut/copy/paste the most popular systems all have an accepted
de facto standard:

GNOME/KDE/Windows: control-X/C/V
Macintosh: Command X/C/V


A new user who takes a look at emacs (while having lots of other
options like Eclipse and stuff) obviously accepts these keyboard
shortcuts to work.

C-y is not superior to C-v. It's different and has no intrinsic
advantage. I understand hardcore emacs users don't want to use
different keys and it is perfectly acceptable. But they can
easily configure emacs while newbies can't. The default Emacs
configuration should support the keys above (and similar editing
keys commonly used in different operation systems) and there
should be a single setting like (classic-mode 1) or something
which seasoned emacs users could put into their config files to
make keys work like it works today.

It will not happen, obviously, judging from the responses sent to
this thread, because veteran users want to keep things the way
they are. They want people to change their ways to use emacs,
instead of changing emacs to be more similar to popular tools to
ease the entry for new users. Most people won't change their
usual ways for the sake of using emacs, because they expect basic
things (like copy/paste) to work as they work everywhere else out
of box without any configuration. And it's an acceptable
expectation. Why should they spend time to configure such basic
things to try an obscure editor? They won't do that and that's
why with time emacs will probably be more and more an obscure editor.

It's sad, because it's such a great tool, and I don't want to see
it fade away in obscurity. But if easy of entry is not increased
for casual users then it is the most probable future for our
beloved editor.

Re: Emacs learning curve

[Sebastian Rose]

Tom <levelhalom@gmail.com> writes:
> David Kastrup <dak <at> gnu.org> writes:
>> >
>> > There is no reason to use the word yank for an operation which practically
>> > every other system calls paste. It's one of those totally unnecessary 
>> > roadblocks for newbies in emacs.
>> 
>> Au contraire.  If the operations were named "cut" and "paste", the
>> newbie would be completely without mnemonics for C-k, C-y and their ilk.
>> 
>
>
> This could be the other part of making Emacs more easy to use for
> newbies.
>
> For cut/copy/paste the most popular systems all have an accepted
> de facto standard:
>
> GNOME/KDE/Windows: control-X/C/V
> Macintosh: Command X/C/V

Has nothing to do with killing in emacs.

> C-y is not superior to C-v. It's different and has no intrinsic
> advantage. I understand hardcore emacs users don't want to use
> different keys and it is perfectly acceptable.

C-w, C-y, M-w etc. use a different clipboard.  It's sooo useful!  If you
mark a region with your mouse, the contents are copied to that
clipboard, too.

And I can kill and yank confidential data between emacs buffers (which I
often do) and be sure to not paste it in a e.g. web browser's form!
To paste there, I'd have to use middle click, which means I'd have to
use the mouse.

Using the mouse, on the other hand, is very fast in some cases to copy
lots of pieces of data. This can only be done, because of the way emacs
kill-ring-saves text (M-w). 


Every application on a GNU/Linux system distinguishes between those two
clipboards.  I see how windows (and MAC?) users cannot judge this.

Both of these applications are not available on Windows systems, because
Windows it's an working environment many people use, but it's a bad and
stupid and restricted working environment - everyone here knows that.




BUT: I can see no reason, why `clipboard-kill-ring-save' et al could not
be bound to a sensible and simple key by default.



  Sebastian

Re: Emacs learning curve

[Juri Linkov]

> Using the mouse, on the other hand, is very fast in some cases to copy
> lots of pieces of data. This can only be done, because of the way emacs
> kill-ring-saves text (M-w).

I don't use the mouse because using the keyboard is more convenient.

> BUT: I can see no reason, why `clipboard-kill-ring-save' et al could not
> be bound to a sensible and simple key by default.

That's why I suggested to bind it to the CUA key <C-insert>, and also
to another CUA key `C-c' because using the clipboard is the standard
semantics of these CUA keys.

There are numerous user requests asking for this, the most recent
was just yesterday:
http://stackoverflow.com/questions/3216081/integrate-emacs-copy-paste-with-system-copy-paste

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emacs learning curve

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> BUT: I can see no reason, why `clipboard-kill-ring-save' et al could not
>> be bound to a sensible and simple key by default.
>
> That's why I suggested to bind it to the CUA key <C-insert>, and also
> to another CUA key `C-c' because using the clipboard is the standard
> semantics of these CUA keys.
>
> There are numerous user requests asking for this, the most recent
> was just yesterday:
> http://stackoverflow.com/questions/3216081/integrate-emacs-copy-paste-with-system-copy-paste


Binding "C-c", is a non-starter of course.

But other than that, why not just tell them to set
x-select-enable-clipboard ?

-Miles

-- 
  Dinanzi a me non fuor cose create
se non etterne, e io etterno duro.
Lasciate ogne speranza, voi ch'intrate.

Re: Emacs learning curve

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> But other than that, why not just tell them to set
> x-select-enable-clipboard ?

Thanks for reminding me: is there any reason x-select-enable-clipboard
isn't t by default?

Re: Emacs learning curve

[David De La Harpe Golden]

On 11/07/10 18:14, Chong Yidong wrote:
> Miles Bader<miles@gnu.org>  writes:
>
>> But other than that, why not just tell them to set
>> x-select-enable-clipboard ?
>
> Thanks for reminding me: is there any reason x-select-enable-clipboard
> isn't t by default?
>


Because it will do an incredibly annoying thing unless you also 
reconfigure certain other settings:

If you want emacs cut and paste to act like other recent X11 apps:

(setq mouse-drag-copy-region nil)
(setq x-select-enable-primary nil
(setq x-select-enable-clipboard to t)
(setq select-active-regions to t)
(global-set-key [mouse-2] 'mouse-yank-primary)

Then C-w/M-w/C-y act very similarly to C-x/C-c/C-v in other apps -
if then you also want the keybindings to be similar, turn on cua-mode.

[Aside: I think select-active-regions has bitrotted slightly on trunk as 
it's occasionally messing up (apart from the known issue with mousewheel 
scrolling), though I haven't managed a repeatable test case yet.]

Re: Emacs learning curve

[David De La Harpe Golden]

On 11/07/10 18:59, David De La Harpe Golden wrote:

> (setq x-select-enable-clipboard to t)
> (setq select-active-regions to t)

or without the "to" heh.

Re: Emacs learning curve

[Jan Djärv]

David De La Harpe Golden skrev 2010-07-11 19.59:

>
> If you want emacs cut and paste to act like other recent X11 apps:
>
> (setq mouse-drag-copy-region nil)
> (setq x-select-enable-primary nil

Wouldn't this make it so selected text isn't in primary anymore?

	Jan D.

Re: Emacs learning curve

[David De La Harpe Golden]

On 11/07/10 20:00, Jan Djärv wrote:
>
>
> David De La Harpe Golden skrev 2010-07-11 19.59:
>
>>
>> If you want emacs cut and paste to act like other recent X11 apps:
>>
>> (setq mouse-drag-copy-region nil)
>> (setq x-select-enable-primary nil
>
> Wouldn't this make it so selected text isn't in primary anymore?
>

On its own, yes.  select-active-regions then makes it primary,
for both mouse and keyboard selected text, but without it affecting the 
kill ring.

Re: Emacs learning curve

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

>> Thanks for reminding me: is there any reason x-select-enable-clipboard
>> isn't t by default?
>
> Because it will do an incredibly annoying thing unless you also
> reconfigure certain other settings:
>
> If you want emacs cut and paste to act like other recent X11 apps:
>
> (setq mouse-drag-copy-region nil)
> (setq x-select-enable-primary nil
> (setq x-select-enable-clipboard to t)
> (setq select-active-regions to t)
> (global-set-key [mouse-2] 'mouse-yank-primary)

Yes, this is what I have in mind.  I remember that we postphoned these
changes during Emacs 23, because not all the necessary code was in place
at the time.

To summarize:

  C-w and M-w should copy to the clipboard and set the primary
    in addition to updating the kill-ring.

  shift-selection and mouse-dragging should set/update the primary,
    leaving the clipboard and the kill-ring alone.

  mouse-2 should yank the primary.

The main downside, IIRC, is that some users may not want C-w in Emacs to
clobber the clipboard.  I can understand how this may be a concern,
since the Emacs kill-ring is much more flexible than the clipboard.  But
this seems to be something for advanced users to worry about; for the
default, we ought to stick close to X11 "standards").

Re: Emacs learning curve

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 11 Jul 2010 18:49:03 -0400
> Cc: Juri Linkov <juri@jurta.org>, Sebastian Rose <sebastian_rose@gmx.de>,
> 	emacs-devel@gnu.org, Tom <levelhalom@gmail.com>,
> 	Miles Bader <miles@gnu.org>
> 
> To summarize:
> 
>   C-w and M-w should copy to the clipboard and set the primary
>     in addition to updating the kill-ring.
> 
>   shift-selection and mouse-dragging should set/update the primary,
>     leaving the clipboard and the kill-ring alone.
> 
>   mouse-2 should yank the primary.

What about the region highlighted by typing C-SPC twice and then
moving cursor -- will it go to the primary as well?

> The main downside, IIRC, is that some users may not want C-w in Emacs to
> clobber the clipboard.  I can understand how this may be a concern,
> since the Emacs kill-ring is much more flexible than the clipboard.  But
> this seems to be something for advanced users to worry about; for the
> default, we ought to stick close to X11 "standards").

Perhaps make a simple minor mode for those users who don't want C-w
etc. to clobber the clipboard.

Re: Emacs learning curve

[David De La Harpe Golden]

On 12/07/10 08:25, Eli Zaretskii wrote:
>> From: Chong Yidong<cyd@stupidchicken.com>
>> Date: Sun, 11 Jul 2010 18:49:03 -0400
>> Cc: Juri Linkov<juri@jurta.org>, Sebastian Rose<sebastian_rose@gmx.de>,
>> 	emacs-devel@gnu.org, Tom<levelhalom@gmail.com>,
>> 	Miles Bader<miles@gnu.org>
>>
>> To summarize:
>>
>>    C-w and M-w should copy to the clipboard and set the primary
>>      in addition to updating the kill-ring.
>>
>>    shift-selection and mouse-dragging should set/update the primary,
>>      leaving the clipboard and the kill-ring alone.
>>
>>    mouse-2 should yank the primary.
>
> What about the region highlighted by typing C-SPC twice and then
> moving cursor -- will it go to the primary as well?
>

[it's c-spc once out-of-box, you must have turned off transient-mark-mode?]

I would expect so and n.b. it already does with the relevant settings 
already given.


>> The main downside, IIRC, is that some users may not want C-w in Emacs to
>> clobber the clipboard.  I can understand how this may be a concern,
>> since the Emacs kill-ring is much more flexible than the clipboard.  But
>> this seems to be something for advanced users to worry about; for the
>> default, we ought to stick close to X11 "standards").
>
> Perhaps make a simple minor mode for those users who don't want C-w
> etc. to clobber the clipboard.

They would turn off x-select-enable-clipboard and then use 
clipboard-kill/yank (either bound to some key or the existing ones on 
the menu) for the times they want to interact with the clipboard.

I suppose a mode could set that up, but it borders on trivial.

Re: Emacs learning curve

[Eli Zaretskii]

> Date: Mon, 12 Jul 2010 10:00:50 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> >> To summarize:
> >>
> >>    C-w and M-w should copy to the clipboard and set the primary
> >>      in addition to updating the kill-ring.
> >>
> >>    shift-selection and mouse-dragging should set/update the primary,
> >>      leaving the clipboard and the kill-ring alone.
> >>
> >>    mouse-2 should yank the primary.
> >
> > What about the region highlighted by typing C-SPC twice and then
> > moving cursor -- will it go to the primary as well?
> >
> 
> [it's c-spc once out-of-box, you must have turned off transient-mark-mode?]

Yes.

> I would expect so

That would be an annoyance, IMO.

> > Perhaps make a simple minor mode for those users who don't want C-w
> > etc. to clobber the clipboard.
> 
> They would turn off x-select-enable-clipboard and then use 
> clipboard-kill/yank (either bound to some key or the existing ones on 
> the menu) for the times they want to interact with the clipboard.
> 
> I suppose a mode could set that up, but it borders on trivial.

It's easier to toggle a mode than to figure out what should go into
it.

Re: Emacs learning curve

[David De La Harpe Golden]

On 12/07/10 10:30, Eli Zaretskii wrote:
>> Date: Mon, 12 Jul 2010 10:00:50 +0100
>> From: David De La Harpe Golden<david@harpegolden.net>
>>
>>>> To summarize:
>>>>
>>>>     C-w and M-w should copy to the clipboard and set the primary
>>>>       in addition to updating the kill-ring.
>>>>
>>>>     shift-selection and mouse-dragging should set/update the primary,
>>>>       leaving the clipboard and the kill-ring alone.
>>>>
>>>>     mouse-2 should yank the primary.
>>>
>>> What about the region highlighted by typing C-SPC twice and then
>>> moving cursor -- will it go to the primary as well?
>>>
>>
>> [it's c-spc once out-of-box, you must have turned off transient-mark-mode?]
>
> Yes.
>
>> I would expect so
>
> That would be an annoyance, IMO.
>

Well, I find it isn't in practice (quite some time thereof now), in fact 
it is least surprising: It feels quite in keeping with X11 user 
expectations that the most recently selected whatever is to be found in 
primary.

RE: Emacs learning curve

[Drew Adams]

> > But other than that, why not just tell them to set
> > x-select-enable-clipboard ?
> 
> Thanks for reminding me: is there any reason x-select-enable-clipboard
> isn't t by default?

New thread, please.  This is a general discussion about the Emacs learning
curve.

Re: Emacs learning curve

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > But other than that, why not just tell them to set
>> > x-select-enable-clipboard ?
>>
>> Thanks for reminding me: is there any reason x-select-enable-clipboard
>> isn't t by default?
>
> New thread, please.  This is a general discussion about the Emacs learning
> curve.

We're discussing making the Emacs cut/paste behavior closer to what new
users expect.

RE: Emacs learning curve

[Drew Adams]

> > New thread, please.  This is a general discussion about the 
> > Emacs learning curve.
> 
> We're discussing making the Emacs cut/paste behavior closer 
> to what new users expect.

Precisely.  And that's what you should call the new thread:
"new cut/paste behavior" or "better cut/paste for new users" or some such.

That is not part of a _general_ discussion about the Emacs learning curve.  Or
if it is, then that general discussion becomes a giant pit with multiple rat
holes down which subthreads will wind.  And those subthreads will not be labeled
as such, hence more difficult to find later.

Do you want the thread to contain all discussion (implementation details etc.)
of each possible change in behavior?

Not a good idea.  Especially where possible UI changes are concerned - you've
seen (I hope) how much of a detour any individual UI change discussion can take.
Did someone say "bike shed"?

Re: Emacs learning curve

[Sebastian Rose]

Chong Yidong <cyd@stupidchicken.com> writes:
> Miles Bader <miles@gnu.org> writes:
>
>> But other than that, why not just tell them to set
>> x-select-enable-clipboard ?
>
> Thanks for reminding me: is there any reason x-select-enable-clipboard
> isn't t by default?


I wouldn't want that.  It's non-conform to what _all_ other applications on
Linux do (same on Windows, I believe).

I mean no one would expect Firefox to put text into the clipboard if you
select it using the mouse.

Why would I want to have each and every snippet I kill in the clipboard?


  Sebastian

RE: Emacs learning curve

[Drew Adams]

> It's sad, because it's such a great tool, and I don't want to see
> it fade away in obscurity.

Don't be sad.  Emacs will be here long after you and I will have bit the dust.

50 years from now someone who has newly discovered Emacs and tried
unsuccessfully to turn casual-user friends, family, and colleagues onto it will
opine the same anxious/delerious opinion that Emacs MUST move QUICKLY to adopt
the ever-popular and universal FLOMBIT (TM) standard or it will RAPIDLY WASTE
AWAY.  If you could search the emacs-devel archives in the future you would see
plenty of such periodic threads.

This is not very different from someone who discovers fresh, organic, local food
or fine French or Chinese cooking for the first time and wants to stop the world
from wasting its time and health on junk food.  Well, the difference is that
such discoverers do not usually spend their time trying to convince the foodie
community to start packaging their organic fare in Happy Meal (TM) boxes in
order to reach the masses.

It's normal when you discover something good (good wine, good music, good art,
good science, good health...) to want to share that discovery and feeling, to
turn everyone else onto it.  Visit Facebook if that's not clear.  ATTENTION!!
EVERYONE ****MUST**** LEARN THAT X IS WHERE IT'S AT, NOW!!!.

But that's an individual learning experience.  Do not confuse your enthusiasm
arising from the gap between you yesterday and new-you today with the gap
between the world without X and the world + X.  Do not conclude that X will soon
disappear if everyone does not quickly wake up and smell the coffee.

Proselytize for Emacs, if you will, and wrap it in CUA-mode and such if you
think that will help you proselytize, but do not confuse your missionary zeal
with some real lack on the part of Emacs.  You want to close the gap, fine.  But
do not assume that the reason Emacs is not on every breakfast table is that it
is missing what Fruit Loops has.

> But if easy of entry is not increased for casual users then
> it [fade away into obscurity] is the most probable future
> for our beloved editor.

Evidence?

News of the impending demise of Emacs is yesterday's (false) news.

Emacs can, does, and will learn from outside developments.  Sometimes it learns
slowly; sometimes it learns the wrong lesson; but in the long run it tends to
pick up useful improvements.  It is a mistake to think that it MUST or even
should adopt this or that approach or feature.

If you really want to help, then find and promote real improvements (see the
mention of Eclipse features and CEDET in this thread), not just "improvements"
that amount only to syncing with the mainstream of the moment.

For a century or two everyone was convinced that whole-grain bread was
old-fashioned and inferior for health and in taste.  It was considered on its
way out, a vestige consumed only by a few ignorant, old country folk on their
last legs.  One can imagine some well-intentioned "Defenders of the Wholely
Grain" crying Chicken Little, stressing the urgency of bleaching whole grain to
make it look like the white bread that the masses had become accustomed to, in
order to save wholeness from outright extinction.  Save the Wholes!

White flour is still popular (and dominant) today, but whole grain has been
around for millenia and is still appreciated, even by some who are not on their
last legs.  The period when its imminent demise was foreseen amounts, so far, to
only a teeny blip on the history screen.

Someone might well repeat `This tends to lock people into corners by saying
"look how good we are".'  If so, don't bother - you're missing the point.  Not
agreeing to follow a fad or the mainstream on this or that feature is not a
refusal to consider all new features or improvements.

The argument that Emacs should (or MUST) do X just because the mainstream or the
Flavor Of The Week does X is a weak argument.  It _is_ an argument to consider,
but it is a weak one.  If that is the _only_ support for making some change
then, well...

Am I satisfied that Emacs development always adds the right features in the
right way or otherwise makes the changes that _I_ think would be improvements?
Hehe - if you read this list then you know the answer.

What it's about is discussion - argument and evidence - of possible changes.  If
you want some change, then argue to support it on its merits.  The devil is in
the _details_.

Blanket whining that we should do X because EVERYONE is doing X doesn't work for
teenie boppers trying to get parental permission, and it doesn't work here
either.  Argue your case, with particulars.  And be prepared to think again -
and not necessarily to win your case.

FWIW, I feel the same about changes that ARE made by Emacs development.  IMHO,
changes are sometimes (too often) made without sufficient reason, discussion,
and argument.  The same thing I say to those who want this or that change I say
also to those who implement this or that change without sufficient debate and
investigation: "Reasons, argument, evidence, please."

Re: Emacs learning curve

[Walter Alejandro Iglesias]

Do you think using "ed" is difficult?  Try it a Sunday and you'll learn
how to use it in minutes.

The same happens with the vi editor.  Why?  Because since the first time
it is showed to the new user like a "different" tool.  Especially
different to what users are accustomed today.  Vi, since the first time
says to you "I am not notepad!", so spend a few minutes following the
tutorial or choose another tool.

The same could happen with Emacs but, like most gnu/linux graphical
applications (those you find in gnome, kde), Emacs (I mean the graphical
interface) tries to be friendly to the new user.  That is the mistake.

Most gnu/linux distributions install a command line version of vi but the
X11 or gtk version of emacs.  So the new user open emacs and expects the
menu, similar to the menu of the rest of applications, behaves like the
menu of rest of applications.  This is what common sense expects of a
"system": an unified behavior.  After a few clicks the newbie close Emacs
screwing to the mother of somebody.

What windows, mac os and some "graphical desktop gnu/linux" users don't
know is that Emacs is coherent with the wonderful gnu base system (core
utils and family), a good, moderate, evolution of unix tools.  And I am
seriously suspecting, reading this mailing list, some advanced emacs
users-developers suffer the same ignorance.  That's why, I think, Emacs
leaning curve is developing in a black hole (using gnus to read mail is
an example).

But I love you all.  So, let me KISS you! ;)

PD: elisp function's names are descriptive enough.  Why don't include
them "literally" in the menu, instead of the friendly descriptions that
just confuse.  In this way you at least invite the new user to learn.

Re: Emacs learning curve

[Barry Fishman]

Walter Alejandro Iglesias <eloi@roquesor.com> writes:
> What windows, mac os and some "graphical desktop gnu/linux" users don't
> know is that Emacs is coherent with the wonderful gnu base system (core
> utils and family), a good, moderate, evolution of unix tools.  And I am
> seriously suspecting, reading this mailing list, some advanced emacs
> users-developers suffer the same ignorance.  That's why, I think, Emacs
> leaning curve is developing in a black hole (using gnus to read mail is
> an example).

Since I started using Emacs I have seen many window systems come and
go.  What people call "Modern" window interfaces are just that, the
currently popular window system behavior soon to be replaced by
something else.

I learned Emacs in spite of any initial difficulties because it provided
me with a better and more flexible and productive environment in which
to work.  It was not overly difficult to learn, even in an environment
where none of my colleagues were using it, but it did take some effort.
Why is learning something different a bad thing?

One of the benefits of Emacs was that on the occasions I needed to move
from my usual Unix-like systems to Windows, I was able to install and
run Emacs and get my mail, editing, and printing setups working.  This
gave me a beachhead on the platform and time to learn to work with the
new computer environment.  I found that even the best Window's tools of
the time had gaps that were filled by continuing to use Emacs.  If it is
only a short term task under the new OS, much of that (mis-)learning can
be avoided.

Emacs, by using control sequences to do common things, becomes ingrained
in your thought processes and automatic.  If you ask me how to do a
particular operation, I will probably not be able to tell you what the
key sequence is.  It is just something my fingers do when I think about
doing the operation.

Changing long term Emacs bindings to match the current (transient)
window system flavor of the day fills me with some dread.  One could
make Emacs easier to pick up by people who have already spent time
learning the (often badly designed) window environment on which it is
being run.  However, these people are less likely to explore the aspects
of Emacs that make it a productive environment, developed over decades
of effort.  The easy adaption to Emacs's dummy editor functionality does
not expose them to the initial learning process which also opens up the
greater functionality of Emacs.  The cost is that people who spend the
time to learn Emacs now must work around platform specific changes and
gratuitous changes between different Emacs versions.  This is
particularly difficult since many of these operations are performed
automatically by your fingers and not thought about in a way you can
apply remembered rules about what was popular on each particular Emacs
version or on each particular window system.

My .emacs file contains a section called "Forward into the past", which
I use to undo changes made to placate new users at the expense of people
that already use Emacs.  Unsurprisingly, this section is not continually
growing.  The bindings generally bounce around while developers sort out
all that was lost by the change, and then usually settle in on a
consistent setup, at which point I can often take out my patches and
relearn the final, now stable bindings (while working with non-sensitive
files).

The question ultimately is whether the purpose of developing free
software is to spend ones time copying the evolving and gratuitous
behavior of proprietary software, or looking long term into that would
make computers a more productive and user /empowering/ environment in
which to work.  We know this is not the goal of Microsoft, Apple, or
whoever succeeds them.  Their goal as corporations has to be to make
money for themselves.  They do that or they get bought out by someone
with that goal.  Unfortunately, there is more money in getting people to
pay you to think for them, than in teaching people how to solve problems
themselves.

People are not naturally stupid.  They only become stupid when the
opportunities to learn are closed or hidden from them.  Shouldn't the
free software efforts be focused on making computers a more worthwhile
and enriching environment than in making proprietary environments
cheaper?

-- 
Barry Fishman

Re: Emacs learning curve

[Stephen J. Turnbull]

Barry Fishman writes:

 > Why is learning something different a bad thing?

Learning something different is not a bad thing.  Learning something
different *unnecessarily* sucks, though.  It sucks for the individual,
it sucks for society, and it sucks for free software.

You give an excellent example:

 > One of the benefits of Emacs was that on the occasions I needed to
 > move from my usual Unix-like systems to Windows, I was able to
 > install and run Emacs and get my mail, editing, and printing setups
 > working.  [...]  If it is only a short term task under the new OS,
 > much of that (mis-)learning can be avoided.

This works in reverse for people migrating from Windows to *nix or
performing short-term tasks in *nix.  Since encouraging people to move
away from proprietary systems like Windows is a goal (*the* goal?) of
the GNU Project, Emacs *should* *consider* whether specific measures
claimed to make it easier for people to make the move are worthwhile.

Personally, for changing the keymap I think the answer is "no" (for
the reasons you give among others, specifically Windows-a-like GNOME
programs are a dime a dozen -- and even so overpriced), but it's *not*
a no-brainer (except for people who are stuck on "no" because they
have no brain).  It's something that deserves a bit of rethinking
every once in a while.  Mostly for the effect it will have of focusing
attention on alternative ways to encourage migration to free software
via Emacs.

 > Shouldn't the free software efforts be focused on making computers
 > a more worthwhile and enriching environment than in making
 > proprietary environments cheaper?

That's two spellings for the same thing, you know.  The cost of
proprietary environments to users is mostly not pecuniary.[1][2]  It's
that they suck, both on their own terms (but so does free software,
otherwise we wouldn't need "emacs-devel" ;-), but more importantly, on
the terms that *we* want to use software -- it does what we want, not
vice versa, and mostly the only way to get software to do what we want
is to write it ourselves.

Footnotes: 
[1]  There is a *social* cost of the Microsoft tax, for example, but
for most users it's cheaper to buy a Windows box and reformat the HDD
than it is to get a GNU system preinstalled (and forget about getting
a GNU system from a vendor unless you ask for "Linux"; if you ask for
"GNU/Linux", they'll say "never heard of that one, we offer Ubuntu and
Red Hat Linux"!)  Dell France apparently is currently quoting a price
of 461 euros to give you the same box but with Ubuntu on it instead of
Windows!  Dell Japan, when pressed, will tell you that their own
website is wrong, they don't actually offer pre-installed Linux[sic]
any more.  Windows is free-beer free for most users.

Similarly, if you like Apple hardware, good luck getting a box without
Mac OS X on it.

[2]  Proprietary applications can be horribly expensive, of course.

Re: Emacs learning curve

[Lennart Borgman]

On Thu, Aug 5, 2010 at 7:39 PM, Barry Fishman <barry_fishman@acm.org> wrote:
>
> Since I started using Emacs I have seen many window systems come and
> go.  What people call "Modern" window interfaces are just that, the
> currently popular window system behavior soon to be replaced by
> something else.

Is not this rather one of the problems with free software? I think
most users would like a stable window system standard interface in
this regard.

Re: Emacs learning curve

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Since I started using Emacs I have seen many window systems come and
>> go.  What people call "Modern" window interfaces are just that, the
>> currently popular window system behavior soon to be replaced by
>> something else.
>
> Is not this rather one of the problems with free software? I think
> most users would like a stable window system standard interface in
> this regard.

I think you're misinterpreting the time-frame here -- proprietary
windowing systems have been no more stable over the time many people
have been using emacs.

[Apple may have the best claim, but even there, it's a pretty dubious one.]

-Miles

-- 
Insurrection, n. An unsuccessful revolution.

Re: Emacs learning curve

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Is not this rather one of the problems with free software? I think
 > most users would like a stable window system standard interface in
 > this regard.

The question is not what "most users" would want.

It's what "most users who would benefit from and actually choose
Emacs" would want.

Re: Emacs learning curve

[Walter Alejandro Iglesias]

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

> On Thu, Aug 5, 2010 at 7:39 PM, Barry Fishman <barry_fishman@acm.org> wrote:
>>
>> Since I started using Emacs I have seen many window systems come and
>> go.  What people call "Modern" window interfaces are just that, the
>> currently popular window system behavior soon to be replaced by
>> something else.
>
> Is not this rather one of the problems with free software? I think
> most users would like a stable window system standard interface in
> this regard.


The term "freedom" is a double-edged knife.  Young developers could
think "Why might I pay attention to what was done along the years?
Why might I pay attention to what others have done?".

Popular gnu/linux desktops and its applications are a good example.
Most of them seem trying to "replace" (and hide) the base system
instead of "complement" it.  Then final users think even the terminal
is halfway obsolescence.

They may think it is the better way to attract new users.  But, in the
long term, pathetically looking like a windows-macosx fake just get
the opposite.  Mostly if the graphical application returns a crash
popup window.

A clever new user takes in care the compatibility-universality of a
new interface (new for him) at time to decide if suffering or not its
"learning curve".

So gnu (not just desktop environments) are in a dilemma.  To keep
coherent with unix (gnu itself) base system tradition or with fashion
(what people understand for "modern system").


With the famous big graphical applications to edit images, videos, 3d
animations. etc (what people understand for "professional tools") the
user must learn hundred of submenus with crazy named obscure functions
(I know because my wife is a graphical designer).  The user "eats" all
this shit thinking to do a good investment.  But, more or late he/she
are fired of his/her job and in the new job he/she find he/herself in
front of other famous application that do the same, or the same app in
other system, or an update of the same app, but the stuff of functions
that take he/she month to learn, have a different name or are in other
place in the menu (i.e. take a look to the "exclusive windoze" 3DMax).

Re: Emacs learning curve

[Juri Linkov]

> I think it is quite clear from this text that there is no logical
> reason any more not to use the common terms copy/cut/paste.

While improving terminology, we could also fix a security hole in
copy/cut/paste.  Several times I accidentally submitted confidential
information (like passwords, etc.) because by default copy/cut/paste has
a limited scope.  In a bare Emacs instance (`emacs -Q'), I select and
copy a region, and paste it to a web form inside the web browser.
After submitting it, I notice that pasted text is not the same as
I copied from Emacs, but some text that I put some time ago to the
clipboard from a program other than Emacs.  And often it's too late
to interrupt the web operation.

A fix would be to bind `clipboard-kill-ring-save' to <C-insert>,
`clipboard-kill-region' to <S-delete>, `clipboard-yank' to <S-insert>.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emacs learning curve

[Sean Sieger]

    I have several times pointed out that it is the sum of the differences
    that makes it difficult for new users. The stories about users wanting
    to try but giving up partly because they realize they do not have time
    to go through all the differences are frequent.

This is ridiculous, Lennart.

Not reading something because it doesn't `read' the way you want it to
... um, sounds like sheer laziness.

How much reading would not have gotten done in the history of reading
because of your illogic.

I think you're wrong for promoting not-reading.

Re: Emacs learning curve

[Óscar Fuentes]

Sean Sieger <sean.sieger@gmail.com> writes:

>     I have several times pointed out that it is the sum of the differences
>     that makes it difficult for new users. The stories about users wanting
>     to try but giving up partly because they realize they do not have time
>     to go through all the differences are frequent.
>
> This is ridiculous, Lennart.
>
> Not reading something because it doesn't `read' the way you want it to
> ... um, sounds like sheer laziness.

You are assuming that the begginner is determined to learn and use
Emacs. Nowadays this is a big assumption. People no longer is restricted
to a few options that a sysadmin installed. It would be wiser to arrange
things as if the user was taking a quick look at Emacs out of curiosity.

I learned about Emacs' existence circa 1998. It looked strange, complex
and primitive. Some years after I did the significant effort of learning
and configuring Emacs only after some strong recommendation from someone
whom I respect highly. Then we tried to proselytize among the members of
the programming community where both of us were quite active, but only
gained one or two converts. Although we convinced quite a few people to
try Emacs, the usual reaction was the same I had at the beginning:
intimidating, weird, unnecessarily complex... and they stopped there.

[snip]

Re: Emacs learning curve

[Lennart Borgman]

On Sun, Jul 11, 2010 at 3:00 AM, Sean Sieger <sean.sieger@gmail.com> wrote:
>
>    I have several times pointed out that it is the sum of the differences
>    that makes it difficult for new users. The stories about users wanting
>    to try but giving up partly because they realize they do not have time
>    to go through all the differences are frequent.
>
> This is ridiculous, Lennart.
>
> Not reading something because it doesn't `read' the way you want it to
> ... um, sounds like sheer laziness.
>
> How much reading would not have gotten done in the history of reading
> because of your illogic.
>
> I think you're wrong for promoting not-reading.

I do not understand a word of what you are trying to say. What are you
trying to say? What implications does it have for our discussion about
cut/copy/paste?

Re: Emacs learning curve

[Sean Sieger]

    > This is ridiculous, Lennart.
    >
    > Not reading something because it doesn't `read' the way you want it to
    > ... um, sounds like sheer laziness.
    >
    > How much reading would not have gotten done in the history of reading
    > because of your illogic.
    >
    > I think you're wrong for promoting not-reading.

    I do not understand a word of what you are trying to say. What are you
    trying to say? What implications does it have for our discussion about
    cut/copy/paste?

I swear to God you are a troll.  Do you realize that you make this same
response to virtually every person you communicate with here?

Re: Emacs learning curve

[Lennart Borgman]

On Sun, Jul 11, 2010 at 4:23 AM, Sean Sieger <sean.sieger@gmail.com> wrote:
>    > This is ridiculous, Lennart.
>    >
>    > Not reading something because it doesn't `read' the way you want it to
>    > ... um, sounds like sheer laziness.
>    >
>    > How much reading would not have gotten done in the history of reading
>    > because of your illogic.
>    >
>    > I think you're wrong for promoting not-reading.
>
>    I do not understand a word of what you are trying to say. What are you
>    trying to say? What implications does it have for our discussion about
>    cut/copy/paste?
>
> I swear to God you are a troll.  Do you realize that you make this same
> response to virtually every person you communicate with here?

Yes, I am a bit irritated about your response. I did not find that it
positive and leading forward. So I asked you to be more precise.

Re: Emacs learning curve

[Giorgos Keramidas]

On Sat, 10 Jul 2010 13:41:25 +0200, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Sat, Jul 10, 2010 at 1:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Tom <levelhalom@gmail.com>
>>> Date: Sat, 10 Jul 2010 10:36:46 +0000 (UTC)
>>>
>>> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?
>>
>> From the Emacs manual:
>>
>>  * Killing::           Killing (cutting) text.
>>  * Yanking::           Recovering killed text.  Moving text. (Pasting.)
>>
>> and then:
>>
>>    12 Killing and Moving Text
>>    **************************
>>
>>    "Killing" means erasing text and copying it into the "kill ring", from
>>    which you can bring it back into the buffer by "yanking" it.  (Some
>>    applications use the terms "cutting" and "pasting" for similar
>>    operations.)
>
> I think it is quite clear from this text that there is no logical
> reason any more not to use the common terms copy/cut/paste.

Not really, but this hasn't stopped people from arguing about it.  There
are tunables and functions called `kill-xxx', e.g.:

    kill-ring
    kill-ring-max
    kill-ring-save
    ...

If we change the manual to only use cut/paste then we have to find a new
name for `kill-ring', a new name for the associated functions or
variables, and we will probably have to go through a period of backwards
compatibility that supports both spellings of these options.

Then even if we stop supporting the `kill-xxx' names in the trunk of
Emacs, there will still be packages out there in the wild that break in
amusing ways just because of the rename.

Terminology is important, I don't disagree about this point.  I do have
a few reservations about the statement that kill/yank are less useful
than cut/paste though.  Both are, after all, just conventions that we
have chosen to describe a particular concept.  Once you read through the
manual *once* you know the useful terms and their meanings, so the main
problem of cut/paste = kill/yank goes away.

Re: Emacs learning curve

[Stefan Monnier]

>> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?
> From the Emacs manual:

Maybe we should make a concerted effort to change the terminology.
If someone could go through the manual and docstrings to replace
yank=>paste (and kill => cut|copy), and also find new names for
variables, functions, and commands (which will need aliases so both the
new and old names work), that would be a good start.  I'd be happy to
review such a patch.

>> Why do we call the cursor the point?
> Because point is not the cursor.  The cursor only shows the position
> of point in the visible windows (and on character terminals, only in
> the single selected window).  We still need a term for the ``current
> position in the buffer''.

I'm not sure that's a good reason: most other applications don't bother
with this distinction, they just call both concepts "cursor" and then
rely on context to disambiguate.  So here as well, I'd be willing to
entertain the idea of changing terminology if someone were to send
a patch for it.

>> These relics of old terminology should be updated to the accepted modern
>> variants to make the documentation is more accessible for emacs newbies.
> And then they will be queuing up to start using Emacs, no doubt.

The idea (for me anyway) is not to lure new users (I have given up the
hope to understand what they need/want a lot time ago), but just to make
Emacs better.  And following standards (be they protocols, libraries,
terminology, behavior) is generally a good thing.  So the only reason
not to follow standards is when we have a better story.  In the case of
yank/paste and point/cursor, I don't think our story is that much
better: it's more a historical accident.

Changing such "fundamental" things might not be terribly easy given the
fact that Emacs's names have real effects on behavior (since users refer
to them in their .emacs, you can call them via M-x, etc...) but that
doesn't mean that they're features of which we need to be proud (not
that we should be ashamed of it, either of course: it's nice to remember
that had those things before they became standard).


        Stefan

Re: Emacs learning curve

[Juanma Barranquero]

On Mon, Aug 2, 2010 at 11:19, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The idea (for me anyway) is not to lure new users (I have given up the
> hope to understand what they need/want a lot time ago), but just to make
> Emacs better.  And following standards (be they protocols, libraries,
> terminology, behavior) is generally a good thing.  So the only reason
> not to follow standards is when we have a better story.  In the case of
> yank/paste and point/cursor, I don't think our story is that much
> better: it's more a historical accident.

Wouldn't that be an argument to use window/pane too, instead of frame/window?

    Juanma

Re: Emacs learning curve

[Tassilo Horn]

On Monday 02 August 2010 15:26:54 Juanma Barranquero wrote:

> > The idea (for me anyway) is not to lure new users (I have given up
> > the hope to understand what they need/want a lot time ago), but just
> > to make Emacs better.  And following standards (be they protocols,
> > libraries, terminology, behavior) is generally a good thing.  So the
> > only reason not to follow standards is when we have a better story.
> > In the case of yank/paste and point/cursor, I don't think our story
> > is that much better: it's more a historical accident.
> 
> Wouldn't that be an argument to use window/pane too, instead of
> frame/window?

That was the first thing that came in my mind, too.  But in contrast to
copy/cut/paste, current and "modern" names are not disjunctive, so there
is no possibility to provide aliases for the old names.

One major problem I see with those modernization ideas is that it would
make it even harder to write packages that work on all emacs flavours.
Either you'd need to define lots of compatibility code or use the old
name aliases.  Neither of those alternatives looks desirable to me, and
in any case it makes life harder for potential new developers.

Bye,
Tassilo

Re: Emacs learning curve

[Juanma Barranquero]

On Mon, Aug 2, 2010 at 16:57, Tassilo Horn <tassilo@member.fsf.org> wrote:

> That was the first thing that came in my mind, too.  But in contrast to
> copy/cut/paste, current and "modern" names are not disjunctive, so there
> is no possibility to provide aliases for the old names.

Oh, I was not defending the idea, just pointing out that it doesn't
make much sense IMO to go just half the way.

    Juanma

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Aug 2, 2010 at 4:57 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>>
>> Wouldn't that be an argument to use window/pane too, instead of
>> frame/window?
>
> That was the first thing that came in my mind, too.  But in contrast to
> copy/cut/paste, current and "modern" names are not disjunctive, so there
> is no possibility to provide aliases for the old names.

Maybe it just requires some more thoughts? I do not think it is a blocker.

> One major problem I see with those modernization ideas is that it would
> make it even harder to write packages that work on all emacs flavours.

Perhaps one can also say that this kind of backward compatibility
blocks new creative ideas for Emacs?

And it stops perhaps users from upgrading.


> Either you'd need to define lots of compatibility code or use the old
> name aliases.

Or just say that if you want a newer version of my-module-x you need
to upgrade Emacs.

> Neither of those alternatives looks desirable to me, and
> in any case it makes life harder for potential new developers.

I think in most cases they will not care about older Emacs versions.

Re: Emacs learning curve

[Tassilo Horn]

On Monday 02 August 2010 17:50:49 Lennart Borgman wrote:

> > One major problem I see with those modernization ideas is that it
> > would make it even harder to write packages that work on all emacs
> > flavours.
> 
> Perhaps one can also say that this kind of backward compatibility
> blocks new creative ideas for Emacs?

Well, maybe yes.  I'm not a big fan of everlasting backwards
compatibility.

But with flavours I've meant Emacs, XEmacs, and SXEmacs.  It's totally
ok to drop support for old emacs versions, and projects like Gnus and
Org have done so.  But dropping support for XEmacs or Emacs because the
function names diverge only because of modernization initiatives is
hardly warrantable.

A coordinated modernization campain across all emacs flavours is
probably quite unlikely...

Bye,
Tassilo

Re: Emacs learning curve

[Stefan Monnier]

>> > The idea (for me anyway) is not to lure new users (I have given up
>> > the hope to understand what they need/want a lot time ago), but just
>> > to make Emacs better.  And following standards (be they protocols,
>> > libraries, terminology, behavior) is generally a good thing.  So the
>> > only reason not to follow standards is when we have a better story.
>> > In the case of yank/paste and point/cursor, I don't think our story
>> > is that much better: it's more a historical accident.
>> Wouldn't that be an argument to use window/pane too, instead of
>> frame/window?

I guess it would, yes.  I haven't heard the term "pane" used nearly as
much, but "windows" is obviously a problem.  So, same as for the others,
I'd be willing to entertain such a change, provided someone suggests
a patch.

> That was the first thing that came in my mind, too.  But in contrast to
> copy/cut/paste, current and "modern" names are not disjunctive, so there
> is no possibility to provide aliases for the old names.

I wouldn't jump to conclusion.  Rather than making backward
compatibility impossible (which means that it can't be done since
backward compatibility is an absolute requirement in this case), it just
means it's yet harder to come up with such a patch.

> One major problem I see with those modernization ideas is that it would
> make it even harder to write packages that work on all emacs flavours.

I'd expect the backward compatibility aliases to stick around for
a *long* time: take a look at the aliases for "screen rather than
frame", some of them are still with us (tho I think they deserve to
disappear now).


        Stefan

Re: Emacs learning curve

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd expect the backward compatibility aliases to stick around for
> a *long* time: take a look at the aliases for "screen rather than
> frame", some of them are still with us (tho I think they deserve to
> disappear now).

Maybe it's time to mark `exchange-dot-and-mark' obsolete.

    1985-10-05  Richard M. Stallman

            * everywhere:
            Change dot to point.

Re: Emacs learning curve

[Stefan Monnier]

>> I'd expect the backward compatibility aliases to stick around for
>> a *long* time: take a look at the aliases for "screen rather than
>> frame", some of them are still with us (tho I think they deserve to
>> disappear now).
> Maybe it's time to mark `exchange-dot-and-mark' obsolete.

Indeed, thanks,


        Stefan

RE: Emacs learning curve

[Drew Adams]

> >> Is there a compelling reason to still use yank/kill, 
> instead of copy/cut/paste?
> > From the Emacs manual:
> 
> Maybe we should make a concerted effort to change the terminology.
> If someone could go through the manual and docstrings to replace
> yank=>paste (and kill => cut|copy), and also find new names for
> variables, functions, and commands (which will need aliases 
> so both the new and old names work), that would be a good start.
> I'd be happy to review such a patch.

Is it a joke?

That would be misguided indeed.

It is better to have different names from the common, whether the Emacs name is
"kill" or "froobarb".  Emacs kill is not the same as cut, etc. but it is
sufficiently similar that using the same name will cause confusion and
frustration.  Using the names that some users are used to will lead to "bug"
reports because the Emacs behavior is different (superior) to what they expect
by the common name.

We already have Cut, Copy, and Paste in the menus, and we state clearly in the
docs what the similarities and differences are (and that's important).  That is
good and proper.  It would be misleading, incorrect, and troublesome (especially
to the newbies who will suffer the confusion) to simply change the Emacs names.

Unless you prefer (a) reams of dialog and bug discussions about how Emacs's
"cut" is broken because it is different from the "standard" cut to the current
(rare) (b) complaints that it's hard to find out how to "cut" text in Emacs
because the command name isn't "cut".

Get some perspective, please.  How many former newbies have complained that the
command names got in their way?  How many?  There are plenty on this list - take
a poll.

The complaints I've seen about the terminology have been from Emacs users (not
newbies) who hope to win more converts to Emacs.  Or the occasional complaint
from a newbie who could not find "cut" in the manual because s?he didn't really
look well or look there at all (yes, it's there, including in the index).

You are trying to solve a non-problem, and your solution will itself lead to
problems.

> >> Why do we call the cursor the point?
> > Because point is not the cursor.  The cursor only shows the position
> > of point in the visible windows (and on character terminals, only in
> > the single selected window).  We still need a term for the ``current
> > position in the buffer''.
> 
> I'm not sure that's a good reason: most other applications 
> don't bother
> with this distinction, they just call both concepts "cursor" and then
> rely on context to disambiguate.  So here as well, I'd be willing to
> entertain the idea of changing terminology if someone were to send
> a patch for it.

So now you will need to make clear when you mean the cursor as the visible thing
that is on a character (display artifact) and when you mean the position before
that character.  Which character is the cursor on at eob and bob?

What problem are you trying to solve?  This is like some first-year biology
student wanting to eliminate the jargon s?he encounters because s?he doesn't yet
understand that it serves a purpose: it is for making just such distinctions as
s?he does not yet see.  _You_, however, should know better.

> >> These relics of old terminology should be updated to the 
> accepted modern
> >> variants to make the documentation is more accessible for 
> emacs newbies.
> > And then they will be queuing up to start using Emacs, no doubt.
> 
> The idea (for me anyway) is not to lure new users (I have given up the
> hope to understand what they need/want a lot time ago), but 
> just to make Emacs better.

You're looking in the wrong place to start making Emacs better.
There's a long list of bugs..., many with proposed solutions.

> And following standards (be they protocols, libraries,
> terminology, behavior) is generally a good thing.  So the only reason
> not to follow standards is when we have a better story.  In 
> the case of yank/paste and point/cursor, I don't think our story
> is that much better: it's more a historical accident.

It is an accident that Emacs chose "kill" rather than "cut".  It is not an
accident that these are two different behaviors even if there are similarities.

> Changing such "fundamental" things might not be terribly easy 
> given the fact that Emacs's names have real effects on behavior
> (since users refer to them in their .emacs, you can call them
> via M-x, etc...) but that doesn't mean that they're features
> of which we need to be proud (not that we should be ashamed
> of it, either of course: it's nice to remember
> that had those things before they became standard).

Details, please.  Mumble mumble - which features?

Emacs did not have its kill before cutting existed elsewhere (whether or not it
was called "cut" back then).  And Emacs's kill is different from cut.

Re: Emacs learning curve

[Sean Sieger]

    > Maybe we should make a concerted effort to change the terminology.
    > If someone could go through the manual and docstrings to replace
    > yank=>paste (and kill => cut|copy), and also find new names for
    > variables, functions, and commands (which will need aliases 
    > so both the new and old names work), that would be a good start.
    > I'd be happy to review such a patch.

    Is it a joke?

The patch?  I didn't read it as such, Drew.

Worry is evil.

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Aug 2, 2010 at 4:16 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> Is there a compelling reason to still use yank/kill,
>> instead of copy/cut/paste?
>> > From the Emacs manual:
>>
>> Maybe we should make a concerted effort to change the terminology.
>> If someone could go through the manual and docstrings to replace
>> yank=>paste (and kill => cut|copy), and also find new names for
>> variables, functions, and commands (which will need aliases
>> so both the new and old names work), that would be a good start.
>> I'd be happy to review such a patch.
>
> Is it a joke?

Trying to make someone look ridiculous only works if you can convince
people that group thinking is good. (Maybe that will work here, but in
that case there is perhaps no meaning trying to continue.)

> It is better to have different names from the common, whether the Emacs name is
> "kill" or "froobarb".  Emacs kill is not the same as cut, etc. but it is
> sufficiently similar that using the same name will cause confusion and
> frustration.

I believe cut/copy/paste are suffiently generic to fit most users mind.

Subtle unnecessary differences should be cured in my opinion.

Re: Emacs learning curve

[Stefan Monnier]

> It is better to have different names from the common, whether the
> Emacs name is "kill" or "froobarb".

Of course, using completely unique names has some advantages, but
I think this would qualify as a rationalization.

> Emacs kill is not the same as cut, etc. but it is sufficiently similar
> that using the same name will cause confusion and frustration.

Humans (and Emacs users are no exceptions) deal with such problems all
the time.  It's a complete non-issue.


        Stefan

RE: Emacs learning curve

[Drew Adams]

> > Emacs kill is not the same as cut, etc. but it is 
> > sufficiently similar that using the same name will cause
> > confusion and frustration.
> 
> Humans (and Emacs users are no exceptions) deal with such problems all
> the time.  It's a complete non-issue.

The question (here) is whether it is more helpful or more of a hindrance to use
the same name for such different things.  Using "cut" emphasizes the similarity,
which helps users find this feature (discovery) - e.g. in the doc.  Using "kill"
or "froobarb" emphasizes the difference, which helps users not to suppose too
much wrt "cutting" behavior.

It's a choice.  Your saying that it is a non-issue signifies only that you've
made your choice.

Re: Emacs learning curve

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Tom <levelhalom@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 02 Aug 2010 11:19:20 +0200
> 
> >> Is there a compelling reason to still use yank/kill, instead of copy/cut/paste?
> > From the Emacs manual:
> 
> Maybe we should make a concerted effort to change the terminology.
> If someone could go through the manual and docstrings to replace
> yank=>paste (and kill => cut|copy), and also find new names for
> variables, functions, and commands (which will need aliases so both the
> new and old names work), that would be a good start.  I'd be happy to
> review such a patch.
> 
> >> Why do we call the cursor the point?
> > Because point is not the cursor.  The cursor only shows the position
> > of point in the visible windows (and on character terminals, only in
> > the single selected window).  We still need a term for the ``current
> > position in the buffer''.
> 
> I'm not sure that's a good reason: most other applications don't bother
> with this distinction, they just call both concepts "cursor" and then
> rely on context to disambiguate.  So here as well, I'd be willing to
> entertain the idea of changing terminology if someone were to send
> a patch for it.

Sorry, but I happen to think this would be a waste of our time and
energy.  If we have resources for improving the docs, there's a lot of
much more useful jobs to be done with the manuals than rephrasing
everything in terms of cut/paste etc.

If someone needs a data point that terminology doesn't matter much,
read the manual for Vim -- it uses non-standard terminology (including
"yank", btw, and other weirdly named commands), and yet is very
popular.

I already wrote long ago in this thread that to make Emacs more
attractive, we need to add to it hot new features that target software
developers.  If we do that, and do it well, terminology differences
and weird keybindings will not prevent hackers to come on board,
because hackers want productivity features.  The sooner we understand
that and start doing something towards that goal with enough
developers to provide a critical mass, the sooner will Emacs begin
gaining new users.

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Aug 2, 2010 at 8:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> If someone needs a data point that terminology doesn't matter much,
> read the manual for Vim -- it uses non-standard terminology (including
> "yank", btw, and other weirdly named commands), and yet is very
> popular.

I think that the situation is different for Vim. For example since it
uses "y" as a command prefix then talking about "yank" makes sense.
And since vi basic key bindings are fixed and that is a basic idea of
vi it makes even more sense.

But still it disturbed me quite a lot in the beginning (but learning
vi was a necessity then).

> I already wrote long ago in this thread that to make Emacs more
> attractive, we need to add to it hot new features that target software
> developers.  If we do that, and do it well, terminology differences
> and weird keybindings will not prevent hackers to come on board,
> because hackers want productivity features.

Strange key bindings makes it probably harder to attract new
developers and users.

And that is perhaps part of the reason that Emacs is lacking some features.

It seems to me that this is part of lack of coordination.
Standardizing makes is easier to coordinate. It is very difficult
though (and I think it is often mistaken as opposed to freedom to
cusomize).

Re: Emacs learning curve

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 2 Aug 2010 20:37:59 +0200
> Cc: levelhalom@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>,
> 	emacs-devel@gnu.org
> 
> On Mon, Aug 2, 2010 at 8:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > If someone needs a data point that terminology doesn't matter much,
> > read the manual for Vim -- it uses non-standard terminology (including
> > "yank", btw, and other weirdly named commands), and yet is very
> > popular.
> 
> I think that the situation is different for Vim. For example since it
> uses "y" as a command prefix then talking about "yank" makes sense.

For the same reason, it makes sense in Emacs, since we have C-y.

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Aug 2, 2010 at 9:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 2 Aug 2010 20:37:59 +0200
>> Cc: levelhalom@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>,
>>       emacs-devel@gnu.org
>>
>> On Mon, Aug 2, 2010 at 8:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > If someone needs a data point that terminology doesn't matter much,
>> > read the manual for Vim -- it uses non-standard terminology (including
>> > "yank", btw, and other weirdly named commands), and yet is very
>> > popular.
>>
>> I think that the situation is different for Vim. For example since it
>> uses "y" as a command prefix then talking about "yank" makes sense.
>
> For the same reason, it makes sense in Emacs, since we have C-y.

It makes a bit sense, yes, but not as much as in vi. Emacs key
bindings are customizable. And a lot of people (including me) would
not even use it if it were not. That is not the case for vi.

Re: Emacs learning curve

[David Kastrup]

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

> On Mon, Aug 2, 2010 at 9:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Lennart Borgman <lennart.borgman@gmail.com>
>>> Date: Mon, 2 Aug 2010 20:37:59 +0200
>>> Cc: levelhalom@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>,
>>>       emacs-devel@gnu.org
>>>
>>> On Mon, Aug 2, 2010 at 8:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> >
>>> > If someone needs a data point that terminology doesn't matter much,
>>> > read the manual for Vim -- it uses non-standard terminology (including
>>> > "yank", btw, and other weirdly named commands), and yet is very
>>> > popular.
>>>
>>> I think that the situation is different for Vim. For example since it
>>> uses "y" as a command prefix then talking about "yank" makes sense.
>>
>> For the same reason, it makes sense in Emacs, since we have C-y.
>
> It makes a bit sense, yes, but not as much as in vi. Emacs key
> bindings are customizable. And a lot of people (including me) would
> not even use it if it were not. That is not the case for vi.

Well, why don't you customize your documentation then in order to match
your keybindings?  That way you need not bother anybody else without
stopping for more than two days at a time.

-- 
David Kastrup

Re: Emacs learning curve

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:

> I already wrote long ago in this thread that to make Emacs more
> attractive, we need to add to it hot new features that target software
> developers.  

And why not add these by simply reusing the work of others?


The most requested and popular features are code
completion, refactoring and such. I know CEDET can do some of
these, but I wonder if Emacs should harness the effort put into
these areas by other development teams.

Take a look at the screenshots IdeBridge for example:

http://www.emacswiki.org/emacs/IdeBridge


It uses SharpDevelop libraries to provide completion. I know a
pure elisp solution would be the best, but given the plethora of
languages it's not a realistic goal to provide a comprehensive
Elisp backend solution for everything due to limited developer
resources.

The best approach may be to provide a standard code
completion (refactoring, documentation lookup, etc.) frontend in
Emacs into which any backend implementation can be
plugged. People would write bridge code like in the above example
to handle communication between the frontend and the selected
backend. There are no licensing issues, because it can work
with process communication.

If only Emacs is installed on the machine the default backend
could be CEDET, but if, for example, Eclipse is installed then
the user could configure Java completion to use the Eclipse
backend instead if it provides more complete code analysis than
CEDET. Or .NET libraries for .NET

Why should Emacs reinvent everything in Elisp when it can stand
on the shoulder of other development teams?

Re: Emacs learning curve

[Lennart Borgman]

On Mon, Aug 2, 2010 at 8:39 PM, Tom <levelhalom@gmail.com> wrote:
>
> And why not add these by simply reusing the work of others?
>
> The most requested and popular features are code
> completion, refactoring and such. I know CEDET can do some of
> these, but I wonder if Emacs should harness the effort put into
> these areas by other development teams.
>
> Take a look at the screenshots IdeBridge for example:
>
> http://www.emacswiki.org/emacs/IdeBridge
>
>
> It uses SharpDevelop libraries to provide completion. I know a
> pure elisp solution would be the best, but given the plethora of
> languages it's not a realistic goal to provide a comprehensive
> Elisp backend solution for everything due to limited developer
> resources.
>
> The best approach may be to provide a standard code
> completion (refactoring, documentation lookup, etc.) frontend in
> Emacs into which any backend implementation can be
> plugged. People would write bridge code like in the above example
> to handle communication between the frontend and the selected
> backend. There are no licensing issues, because it can work
> with process communication.


I think that CEDET already makes this possible, but Eric can surely
give a better answer. (Maybe this should be pointed out very clearly
in Emacs doc, at least as a goal?)

Re: Emacs learning curve

[joakim]

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

> On Mon, Aug 2, 2010 at 8:39 PM, Tom <levelhalom@gmail.com> wrote:
>>
>> And why not add these by simply reusing the work of others?
>>
>> The most requested and popular features are code
>> completion, refactoring and such. I know CEDET can do some of
>> these, but I wonder if Emacs should harness the effort put into
>> these areas by other development teams.
>>
>> Take a look at the screenshots IdeBridge for example:
>>
>> http://www.emacswiki.org/emacs/IdeBridge>
>>
>> It uses SharpDevelop libraries to provide completion. I know a
>> pure elisp solution would be the best, but given the plethora of
>> languages it's not a realistic goal to provide a comprehensive
>> Elisp backend solution for everything due to limited developer
>> resources.
>>
>> The best approach may be to provide a standard code
>> completion (refactoring, documentation lookup, etc.) frontend in
>> Emacs into which any backend implementation can be
>> plugged. People would write bridge code like in the above example
>> to handle communication between the frontend and the selected
>> backend. There are no licensing issues, because it can work
>> with process communication.
>
>
> I think that CEDET already makes this possible, but Eric can surely
> give a better answer. (Maybe this should be pointed out very clearly
> in Emacs doc, at least as a goal?)

Just to reiterate, (Eric will surely put it better):
- Cedet is as the name implies "a Collection of Emacs Development Tools"
- One tool is Semantic, which basically is a collection of interfaces
and different implementations of parsers for various languages
- It is possible to implement the semantic interfaces on various
different backends, several such implementations are included in Emacs.

I worked on a couple of such implementations, and while its not always
super obvious how to do it, I think anyone with a genuine interest in
implementing a new backend to Semantic can do it. In fact, not using the
Cedet interfaces is what would be a waste, its the best shot Emacs has
at implementing these modern ide facilities.

-- 
Joakim Verona

Re: Emacs learning curve

[Eric M. Ludlam]

On 08/02/2010 03:53 PM, joakim@verona.se wrote:
> Lennart Borgman<lennart.borgman@gmail.com>  writes:
>
>> On Mon, Aug 2, 2010 at 8:39 PM, Tom<levelhalom@gmail.com>  wrote:
>>>
>>> And why not add these by simply reusing the work of others?
>>>
>>> The most requested and popular features are code
>>> completion, refactoring and such. I know CEDET can do some of
>>> these, but I wonder if Emacs should harness the effort put into
>>> these areas by other development teams.
>>>
>>> Take a look at the screenshots IdeBridge for example:
>>>
>>> http://www.emacswiki.org/emacs/IdeBridge>
>>>
>>> It uses SharpDevelop libraries to provide completion. I know a
>>> pure elisp solution would be the best, but given the plethora of
>>> languages it's not a realistic goal to provide a comprehensive
>>> Elisp backend solution for everything due to limited developer
>>> resources.
>>>
>>> The best approach may be to provide a standard code
>>> completion (refactoring, documentation lookup, etc.) frontend in
>>> Emacs into which any backend implementation can be
>>> plugged. People would write bridge code like in the above example
>>> to handle communication between the frontend and the selected
>>> backend. There are no licensing issues, because it can work
>>> with process communication.
>>
>>
>> I think that CEDET already makes this possible, but Eric can surely
>> give a better answer. (Maybe this should be pointed out very clearly
>> in Emacs doc, at least as a goal?)
>
> Just to reiterate, (Eric will surely put it better):
> - Cedet is as the name implies "a Collection of Emacs Development Tools"
> - One tool is Semantic, which basically is a collection of interfaces
> and different implementations of parsers for various languages
> - It is possible to implement the semantic interfaces on various
> different backends, several such implementations are included in Emacs.
>
> I worked on a couple of such implementations, and while its not always
> super obvious how to do it, I think anyone with a genuine interest in
> implementing a new backend to Semantic can do it. In fact, not using the
> Cedet interfaces is what would be a waste, its the best shot Emacs has
> at implementing these modern ide facilities.

As is suggested above, CEDET is a a bunch of interfaces with default 
back-ends and front ends.  It is similar in nature to GUD or the VC 
stuff, but instead uses different mechanisms to create the abstraction.

A large portion of the miscellaneous tools in CEDET use EIEIO to create 
a series of base classes that define the interface or API that some user 
interface interacts with.  Some examples are:

EDE - This defines some basic concepts of what a project and target are. 
  It then implements project styles for Automake, Make, Emacs, Linux, 
and some others.  On top of these classes is global-ede-mode.  This 
defines a menu and some misc keybindings for compilation or whatever.

In the context of some external tool like SharpDevelop, Visual Studio, 
Eclipse or whatever, if it is possible to read those project files EDE 
can wrap it and the implementation can dispatch back out to that tool to 
do the project management work.  Someone who then learns how to work in 
one kind of project in Emacs (via keybindings or what-not) will know how 
to work in another project even if the back-end is totally different.

Semantic then uses the EDE interfaces to provide project level 
configuration of what files to search or what CPP macros exist.

SemanticDB - The databases used by Semantic to track tag info which is 
used for completion is also based on EIEIO classes.  The default just 
saves stuff to disk, but other back-ends, such as the Emacs backend uses 
Emacs commands to lookup symbols, or the GNU Global backend can query a 
GNU Global database.

The Semantic tools also use mode-local to create an interface boundary. 
  In this case, on a per-mode basis.  Thus the C++ support use the 
parser generator in Semantic to parse the code in a buffer and save off 
the tags.  External parsers can be installed used instead, such as the 
exuberent ctags parser, so on a per-mode basis, you can configure and 
use different backends.

The completion engine is the same.  If there is an alternate 
implementation for creating a list of possible completions for a 
particular mode, you can override the right function to provide the 
output.  Any tool that uses Semantic's smart completion engine would 
then automatically start using the new external tool (such as 
SharpDevelop) instead.

Not yet a part of Emacs, the COGRE UML tool uses the Semantic back end, 
mode-local override features, and EIEIO to generate code from high-level 
concepts such as class diagrams.  COGRE uses EIEIO, and any kind of 
connected graph could be created besides the UML implementation.

I hope this helps answer questions.  I do think that the original 
poster's desire for a place to put a back-end already exists in the 
CEDET infrastructure, and if it doesn't do it perfectly for some case, 
we can certainly tweak the API if needed.

Eric

Re: Emacs learning curve

[David Kastrup]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

[...]

In a rare bout of top posting with fullquote behind, may I kindly
request that the proper place of the following mail content is as an
introductory chapter

"How does the CEDET universe fit together with other tools"

in the CEDET info file?  Barring that, in its documentation "that is to
become info when the stars are right"?

> As is suggested above, CEDET is a a bunch of interfaces with default
> back-ends and front ends.  It is similar in nature to GUD or the VC
> stuff, but instead uses different mechanisms to create the
> abstraction.
>
> A large portion of the miscellaneous tools in CEDET use EIEIO to
> create a series of base classes that define the interface or API that
> some user interface interacts with.  Some examples are:
>
> EDE - This defines some basic concepts of what a project and target
> are. It then implements project styles for Automake, Make, Emacs,
> Linux, and some others.  On top of these classes is global-ede-mode.
> This defines a menu and some misc keybindings for compilation or
> whatever.
>
> In the context of some external tool like SharpDevelop, Visual Studio,
> Eclipse or whatever, if it is possible to read those project files EDE
> can wrap it and the implementation can dispatch back out to that tool
> to do the project management work.  Someone who then learns how to
> work in one kind of project in Emacs (via keybindings or what-not)
> will know how to work in another project even if the back-end is
> totally different.
>
> Semantic then uses the EDE interfaces to provide project level
> configuration of what files to search or what CPP macros exist.
>
> SemanticDB - The databases used by Semantic to track tag info which is
> used for completion is also based on EIEIO classes.  The default just
> saves stuff to disk, but other back-ends, such as the Emacs backend
> uses Emacs commands to lookup symbols, or the GNU Global backend can
> query a GNU Global database.
>
> The Semantic tools also use mode-local to create an interface
> boundary. In this case, on a per-mode basis.  Thus the C++ support use
> the parser generator in Semantic to parse the code in a buffer and
> save off the tags.  External parsers can be installed used instead,
> such as the exuberent ctags parser, so on a per-mode basis, you can
> configure and use different backends.
>
> The completion engine is the same.  If there is an alternate
> implementation for creating a list of possible completions for a
> particular mode, you can override the right function to provide the
> output.  Any tool that uses Semantic's smart completion engine would
> then automatically start using the new external tool (such as
> SharpDevelop) instead.
>
> Not yet a part of Emacs, the COGRE UML tool uses the Semantic back
> end, mode-local override features, and EIEIO to generate code from
> high-level concepts such as class diagrams.  COGRE uses EIEIO, and any
> kind of connected graph could be created besides the UML
> implementation.
>
> I hope this helps answer questions.  I do think that the original
> poster's desire for a place to put a back-end already exists in the
> CEDET infrastructure, and if it doesn't do it perfectly for some case,
> we can certainly tweak the API if needed.
>
> Eric
>
>

-- 
David Kastrup

Re: Emacs learning curve

[Alex Ott]

Re all

David Kastrup  at "Wed, 04 Aug 2010 11:13:00 +0200" wrote:
 DK> "Eric M. Ludlam" <eric@siege-engine.com> writes:

 DK> [...]

 DK> In a rare bout of top posting with fullquote behind, may I kindly
 DK> request that the proper place of the following mail content is as an
 DK> introductory chapter

 DK> "How does the CEDET universe fit together with other tools"

 DK> in the CEDET info file?  Barring that, in its documentation "that is to
 DK> become info when the stars are right"?

I already suggested inclusion (with some changes) of my article about CEDET
(http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html) into official
info - it contain necessary information about CEDET itself (like you cited
from Eric's mail), and provides examples of how to customize Emacs + CEDET
to work with C & C++ code, including name completions, project
customization, etc.

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/           http://alexott.net
http://alexott-ru.blogspot.com/

Re: Emacs learning curve

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Sorry, but I happen to think this would be a waste of our time and
 > energy.

+1

 > to make Emacs more attractive, we need to add to it hot new
 > features that target software developers.

+1

Re: Emacs learning curve

[Andy Wingo]

On Mon 02 Aug 2010 11:19, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> yank=>paste (and kill => cut|copy), and also find new names for
> variables, functions, and commands (which will need aliases so both the
> new and old names work), that would be a good start.

What about the mnemonics? C-y to paste doesn't make much sense. Or would
you entertain keybinding changes as well?

Sounds like a big can of worms :)

Andy
-- 
http://wingolog.org/

Re: Emacs learning curve

[Stefan Monnier]

> Sounds like a big can of worms :)

No doubt.  Which is why I'm not going to write such a patch.  But if
someone sends one, I'm willing to review it and, if it deals with all
the issues in a satisfactory way, I'm open to installing it.

I don't know whether or not it's possible to deal with all the issues
in a satisfactory way, BTW,


        Stefan

Re: Emacs learning curve

[Noah Lavine]

Yes, I didn't say what I meant there, I think. I also meant things
like this: http://sites.google.com/site/steveyegge2/effective-emacs,
which is a combination of a list of useful commands and some advice on
how to configure Emacs.

I must admit that I haven't read the manual all the way through. If I
had, perhaps I would feel differently, but I think I still wouldn't be
able to remember everything in the manual until I had used Emacs for a
while.

Noah

On Sat, Jul 10, 2010 at 2:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noah Lavine <noah549@gmail.com>
>> Date: Fri, 9 Jul 2010 15:12:51 -0400
>> Cc: emacs-devel@gnu.org
>>
>> The big issue, I think, is discovering what Emacs can do. I know that
>> Emacs is *potentially* extremely powerful, but I don't know enough to
>> make use of this power. The Emacs Starter Kit showed me some things, and
>> I found a few more through different web pages, but I think I still
>> don't know very much. I don't know where I would find Emacs features
>> that are useful for me.
>
> Doesn't the manual help discovering what Emacs can do?  Why do you
> need to search the Internet when you have most of the stuff right
> under your fingertips?
>

Re: Efforts to attract more users?

[joakim]

Ken Hori <fplemma@gmail.com> writes:

> I'm not sure if Emacs is attracting new users the way it used to be.
> Certainly search volume has been going downhill for more than several years
> (http://www.google.com/trends?q=emacs), and yet I don't hear this issue being
> addressed here strongly enough.  I hate to ask pedestrian sort of a question
> like this, but are there any efforts specifically to attract more users?
>
> Thanks.

I dont know of any organized effort.

I do try to attract people to Emacs and free software myself.

I mostly work with developers that use a windoze desktop, Eclipse, and
some secondary simpler editor. In recent years getting people interested
in Emacs has been difficult, I can only recall about one or two people I
helped getting started with Emacs the last 3 years.

I also try to help improve technical things developers used to an IDE
find lacking in Emacs. CEDET being included in Emacs was a step in the
right direction.

I think Emacs has a lot of potential to attract new users, especially if
we put more effort into polishing some user interface aspects.

For instance I have observed the following usage pattern with developers
using Eclipse:

"Hmm, I want to diff a file in my project. I don't want to read a boring
manual. Lets fiddle around in the menus until I find a suitable Wizard
that does it for me"

Emacs could quite possibly do the same thing better than Eclipse, but
the same developer trying the same approach in Emacs would probably get
stumped.

I would like to emphasize that I don't think Emacs should do things the
same way Eclipse does them, we need to find Emacsy ways. Perhaps by
improving the Emacs documentation so it is a more obvious entry point
rather than clicking about in menus. Perhaps the info documentation
could be enhanced so it works more like the web, with improved search
facilities, support for Wizards in the info documentation, etc.


-- 
Joakim Verona

Re: Efforts to attract more users?

[Richard Stallman]

The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
them, but maybe we still lack some.

I saw it once, and it used tabs a lot for switching between different views.
We need to be able to do that too.

Also, one advantage of Eclipse's GUI interface is that it shows you a
lot of features when they might be useful.  So you don't have as much
to learn and remember.

Emacs learning curve (was Re: Efforts to attract more users?)

[christian.lynbech]

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

I failed to resist the urge to re-post the below picture on editor
learning curves :-)

I found it at http://unix.rulez.org/~calver/pictures/curves.jpg

                              -- Christian


[-- Attachment #2: curves.jpg --]
[-- Type: image/jpeg, Size: 26488 bytes --]

Re: Emacs learning curve

[Masatake YAMATO]

> I failed to resist the urge to re-post the below picture on editor
> learning curves :-)
> 
> I found it at http://unix.rulez.org/~calver/pictures/curves.jpg

Quite interesting.

I guess the emacs curve is also applicable to "Lisp" in "learning curve for 
some common programming languages."

Masatake YAMATO