Re: Emacs learning curve

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

Clipboard interactions [was: Re: Emacs learning curve]

[David De La Harpe Golden]

On 11/07/10 19:05, Sebastian Rose wrote:
> 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.
>

[The mouse-drag-copy-region => nil I mentioned elsemail stops that in 
particular]

> Why would I want to have each and every snippet I kill in the clipboard?
>

Buggered if I know, but last time the matter came up Eli in particular 
expressed a desire for that on w32.   I did promise  to allow that with 
a clipboard-active-regions setting by analogy with the existing
select-active-regions.  (I do _not_ want them mixed up!)

Each build under w32 (via WINE, I don't have windows) for me is (or was, 
must try again) quite annoying and painful relative to the couple of 
minutes it takes to bootstrap emacs natively, so I haven't completed 
that work yet.

Re: Clipboard interactions [was: Re: Emacs learning curve]

[David De La Harpe Golden]

On 11/07/10 19:15, David De La Harpe Golden wrote:
> On 11/07/10 19:05, Sebastian Rose wrote:

>> Why would I want to have each and every snippet I kill in the clipboard?
>>
>

ah. misread that (misled by context).  Things you actually _kill_  I 
would expect to be on the clipboard. Things you merely select so that 
they are visibly highlighted, not so much - it's that latter behaviour 
Eli wanted on w32, and what happens if you turn on 
x-select-enable-clipboard on X11 without turning off mouse-drag-copy-region.

> Buggered if I know, but last time the matter came up Eli in particular
> expressed a desire for that on w32. I did promise to allow that with a
> clipboard-active-regions setting by analogy with the existing
> select-active-regions. (I do _not_ want them mixed up!)
>
> Each build under w32 (via WINE, I don't have windows) for me is (or was,
> must try again) quite annoying and painful relative to the couple of
> minutes it takes to bootstrap emacs natively, so I haven't completed
> that work yet.

Clipboard interactions [was: re: Emacs learning curve]

[Juri Linkov]

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

I meant `C-c' in cua-mode.  It copies the region,
but not to the clipboard as most users expect.

> But other than that, why not just tell them to set
> x-select-enable-clipboard ?

This is the answer that they usually get,
but new users ask the same question again.

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

Re: Clipboard interactions

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> But other than that, why not just tell them to set
>> x-select-enable-clipboard ?
>
> This is the answer that they usually get,
> but new users ask the same question again.

Why not turn it on by default then?

I have the vague impression that traditionally the reason is that it
slows down cut/past operations somewhat, especially in a networked-X
environment, but I dunno if that's really much of an issue with modern
machines / networks.  [I've had x-select-enable-clipboard set to true
for ages, and never noticed any adverse consequences.]

I think having dedicated bindings for interprocess cut/paste is not such
a great idea though -- that seems to confuse the issue further by making
"cut/paste" behavior in emacs even more complex (whereas changing
x-select-enable-clipboard maintains consistent behavior across all
related Emacs commands), and probably discourages people from learning
to use the native Emacs bindings (and even if they like the CUA bindings
for basic cut/past, there are many many useful operations for which
there are no CUA bindings).

-Miles

-- 
Pray, v. To ask that the laws of the universe be annulled in behalf of a
single petitioner confessedly unworthy.

Re: Clipboard interactions

[Stephen J. Turnbull]

Miles Bader writes:

 > Why not turn it on by default then?

XEmacs avoids it in the case of Motif (probably not relevant?) because
the Motif clipboard ownership protocol involves an insane number of
roundtrips if implemented properly, and is noticeably slow over even a
megabit connection due to latency.

There are also some cases for Xt over the network where use of the
clipboard can be very slow.  These are rarer, but the demand for
clipboard-style interaction has never been very high, except on
Windows where it is the default anyway.

So yes, even in a modern network environment clipboard interaction can
be slow.  However, if there's any demand for that style of
interaction, it may be worth making clipboard interaction the default
and telling users who are in environments where they perceive the
interaction to be slow to turn it off.

Re: Clipboard interactions

[Jan Djärv]

If we are talking about copy/paste of text from Emacs, Xt would not enter in 
to it.  AFAIK, the only place where Motif may be involved in Emacs is 
copy/paste in the file dialog.  All selection code in Emacs is plain X.

	Jan D.


Stephen J. Turnbull skrev 2010-07-12 17.57:
> Miles Bader writes:
>
>   >  Why not turn it on by default then?
>
> XEmacs avoids it in the case of Motif (probably not relevant?) because
> the Motif clipboard ownership protocol involves an insane number of
> roundtrips if implemented properly, and is noticeably slow over even a
> megabit connection due to latency.
>
> There are also some cases for Xt over the network where use of the
> clipboard can be very slow.  These are rarer, but the demand for
> clipboard-style interaction has never been very high, except on
> Windows where it is the default anyway.
>
> So yes, even in a modern network environment clipboard interaction can
> be slow.  However, if there's any demand for that style of
> interaction, it may be worth making clipboard interaction the default
> and telling users who are in environments where they perceive the
> interaction to be slow to turn it off.

Re: Clipboard interactions

[Stephen J. Turnbull]

Jan Djärv writes:

 > If we are talking about copy/paste of text from Emacs, Xt would not enter in 
 > to it.  AFAIK, the only place where Motif may be involved in Emacs is 
 > copy/paste in the file dialog.  All selection code in Emacs is plain X.

Don't take the toolkit name too seriously.  What I mean is that there
is a clipboard protocol in the ICCCM, and which does involve some
overhead.  Doesn't Emacs conform to that protocol when copying to/
pasting from the clipboard?  If so, it should suffer from similar
overhead.  Our experience is that the overhead is perceptible in 1
Mbit network environments in some conditions we don't really
understand.  Not frequent, but frequent enough that having the option
to turn off clipboard is useful for users who only need "drag button1
to select, click button2 to copy".

Re: Clipboard interactions

[Jan Djärv]

Stephen J. Turnbull skrev 2010-07-13 04.06:
> Jan Djärv writes:
>
>   >  If we are talking about copy/paste of text from Emacs, Xt would not enter in
>   >  to it.  AFAIK, the only place where Motif may be involved in Emacs is
>   >  copy/paste in the file dialog.  All selection code in Emacs is plain X.
>
> Don't take the toolkit name too seriously.  What I mean is that there
> is a clipboard protocol in the ICCCM, and which does involve some
> overhead.  Doesn't Emacs conform to that protocol when copying to/
> pasting from the clipboard?  If so, it should suffer from similar
> overhead.  Our experience is that the overhead is perceptible in 1
> Mbit network environments in some conditions we don't really
> understand.  Not frequent, but frequent enough that having the option
> to turn off clipboard is useful for users who only need "drag button1
> to select, click button2 to copy".

Maybe you are thinking of the section that talks about a special clipboard 
client that always take a copy of the clipboard and retains it even if the 
program it got it from died, like the KDE Klipper.

The presence of such a client has no impact on the protocol itself, it just 
leads to a lot of transfers of data from Emacs to, for example, Klipper (I use 
Klipper below as an example, but the issues are generic).

We have seen problems with this when copying a whole buffer, i.e. lots of 
data. Klipper may also do a lot of polling to see if the clipboard changed, 
but most X servers now implement XFixes, so polling should be reduced, 
hopefully to 0.

But Klipper and its kind are totally optional (I always turn these IMHO stupid 
things off), and ICCCM says:

"A special CLIPBOARD client is not necessary. The protocol used by the cutting 
client and the pasting client is the same whether the CLIPBOARD client is 
running or not."

and

"The reasons not to run the clipboard client include:

     * Performance - Data is only transferred if it is actually required (that 
is, when some client actually wants the data).
     * Flexibility - The clipboard data may be available as more than one target."

Klipper can also be configured to collect PRIMARY, so restricting clipboard 
may be of no use.

So it should not be up to Emacs to limit itself because some of its users want 
to run a clipboard client.

	Jan D.

Re: Clipboard interactions

[Stephen J. Turnbull]

Jan Djärv writes:

 > So it should not be up to Emacs to limit itself because some of its
 > users want to run a clipboard client.

I'm talking about an option.

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