Re: Default Emacs keybindings (was: Re: Menu suggestion)

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Lars Hansen]

Maybe one have to make a choice:

1. Emacs should be for "superusers" only.
2. Emacs should be for "ordinary users" *and* "superusers".

If the first choice is made, Emacs code and manuals can continue to 
assume standard Emacs key bindings. This choice is the easy one.

If the second choice is made, Emacs code and manuals probably have to 
support different key binding sets, since the "Emacs standard" and 
"MacOS/MS Windows/Gnome/KDE consensus" are so far apart and conflicting. 
I know it is an enormous task to implement this fully, but I see no real 
choice (apart from 1).

I my dreams Emacs has these menu entries:

   Options->Key bindings->Emacs Classic
                        ->MS Windows
                        ->Modify current bindings

Choosing "Modify current bindings" one is able to move entire trees, 
such as everything prefixed by C-x, to another prefix. Furthermore, one 
can choose to save the current keybindings under a different name.

Although this is hard to implement, it is not impossible. And it must be 
possible to do it in small steps.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Jan D.]

> If the second choice is made, Emacs code and manuals probably have to 
> support different key binding sets, since the "Emacs standard" and 
> "MacOS/MS Windows/Gnome/KDE consensus" are so far apart and 
> conflicting. I know it is an enormous task to implement this fully, 
> but I see no real choice (apart from 1).
>
> I my dreams Emacs has these menu entries:
>
>   Options->Key bindings->Emacs Classic
>                        ->MS Windows
>                        ->Modify current bindings

I would like to add to this menu, "Mac bindings", since 
undo/cut/copy/paste
is not done with C-z/C-x/C-c/C-v, on Max OS X.
The Apple key is used instead of the control key.  The Apple key is now
mapped to Meta in Emacs on Mac OS X, so it is a bit different change 
from
Unix or MS Windows.

Also, many applications on Mac OS X does handle C-a, C-e, C-f, C-p and
so on the way Emacs does.  For example, the mail application on Mac OSX,
where I write this, does scroll forward on C-v and handles movement
the Emacs way (at least C-f, C-b, C-e, C-a, C-p and C-n).  So does the
default text editor.

	Jan D.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Mon, 26 Apr 2004 15:26:44 +0200
> 
> Also, many applications on Mac OS X does handle C-a, C-e, C-f, C-p and
> so on the way Emacs does.

That's because AFAIK Mac OSX is a descendant of the BSD Unix family.
Quite a few Unix programs support Emacs-style key bindings.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Jan D.]

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Mon, 26 Apr 2004 15:26:44 +0200
>>
>> Also, many applications on Mac OS X does handle C-a, C-e, C-f, C-p and
>> so on the way Emacs does.
>
> That's because AFAIK Mac OSX is a descendant of the BSD Unix family.
> Quite a few Unix programs support Emacs-style key bindings.

That is probably one reason.  But the Mail.app and TextEdit.app on Mac 
OSX
are not descendant from any BSD programs, so Apple is extending these
bindings to new programs as well.

My point being, making CUA default on Mac is not going to give
Mac users what they expect.  Mac should not be said to use the same
"agreed" key bindings as Gnome/KDE/MS Windows in this regard.  Now if
CUA mode could use M-x/M-x/M-v on Mac, then we could discuss about
making it the default on Macs also.

	Jan D.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Steven Tamm]

> My point being, making CUA default on Mac is not going to give
> Mac users what they expect.

I'm with you 100%.  The only sensible CUA-mode on the Mac wouldn't 
work; mostly because the default action-modifier is Command and not 
control.   So emacs -nw would never DTRT.   Making CUA the default 
would be counter-productive to me unless it was mapped to 
Command-Z,X,C, and V (in a sense, regardless of the modifier to which 
Command is mapped).    Since Command can be mapped to Control, Meta, or 
Alt; the "Mac bindings" should be able to map to either M- or to A-.

When I started working with Mac OS X, my initial goal was to make GNU 
Emacs basically operate in the same way that it did on UNIX and NT; not 
to quasi-macify parts of it.  So I set about fiddling with key mappings 
so that what my brain thought was C-a was the same on all platforms.   
Consistency of a standard application across platforms is more valuable 
to me than consistency of *all* applications within a platform; but I 
don't think everyone would agree.  Hence, all the Mac modifier options.

-Steven

On Apr 27, 2004, at 12:23 AM, Jan D. wrote:

>>> From: "Jan D." <jan.h.d@swipnet.se>
>>> Date: Mon, 26 Apr 2004 15:26:44 +0200
>>>
>>> Also, many applications on Mac OS X does handle C-a, C-e, C-f, C-p 
>>> and
>>> so on the way Emacs does.
>>
>> That's because AFAIK Mac OSX is a descendant of the BSD Unix family.
>> Quite a few Unix programs support Emacs-style key bindings.
>
> That is probably one reason.  But the Mail.app and TextEdit.app on Mac 
> OSX
> are not descendant from any BSD programs, so Apple is extending these
> bindings to new programs as well.
>
> My point being, making CUA default on Mac is not going to give
> Mac users what they expect.  Mac should not be said to use the same
> "agreed" key bindings as Gnome/KDE/MS Windows in this regard.  Now if
> CUA mode could use M-x/M-x/M-v on Mac, then we could discuss about
> making it the default on Macs also.
>
> 	Jan D.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Kim F. Storm]

Steven Tamm <steventamm@mac.com> writes:

> > My point being, making CUA default on Mac is not going to give
> > Mac users what they expect.
> 
> I'm with you 100%.  The only sensible CUA-mode on the Mac wouldn't
> work; mostly because the default action-modifier is Command and not
> control.   So emacs -nw would never DTRT.   Making CUA the default
> would be counter-productive to me unless it was mapped to
> Command-Z,X,C, and V (in a sense, regardless of the modifier to which
> Command is mapped).    Since Command can be mapped to Control, Meta,
> or Alt; the "Mac bindings" should be able to map to either M- or to
> A-.

How can I check which alternative to use in lisp ?

Looking at mac-command-key-is-meta and maybe mac-reverse-ctrl-meta is
probably the right thing to do, but I'm not sure I fully understand
the meaning and relationship between those vars.  E.g which setting
corresponds to Command = control ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Steven Tamm]

(if mac-command-key-is-meta
     (if mac-reverse-ctrl-meta 'C 'M)
     'A)

On Apr 27, 2004, at 8:17 AM, Kim F. Storm wrote:

> Steven Tamm <steventamm@mac.com> writes:
>
>>> My point being, making CUA default on Mac is not going to give
>>> Mac users what they expect.
>>
>> I'm with you 100%.  The only sensible CUA-mode on the Mac wouldn't
>> work; mostly because the default action-modifier is Command and not
>> control.   So emacs -nw would never DTRT.   Making CUA the default
>> would be counter-productive to me unless it was mapped to
>> Command-Z,X,C, and V (in a sense, regardless of the modifier to which
>> Command is mapped).    Since Command can be mapped to Control, Meta,
>> or Alt; the "Mac bindings" should be able to map to either M- or to
>> A-.
>
> How can I check which alternative to use in lisp ?
>
> Looking at mac-command-key-is-meta and maybe mac-reverse-ctrl-meta is
> probably the right thing to do, but I'm not sure I fully understand
> the meaning and relationship between those vars.  E.g which setting
> corresponds to Command = control ?
>
> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Piet van Oostrum]

>>>>> "Jan D." <jan.h.d@swipnet.se> (JD) wrote:

>>> From: "Jan D." <jan.h.d@swipnet.se>
>>> Date: Mon, 26 Apr 2004 15:26:44 +0200
>>> 
>>> Also, many applications on Mac OS X does handle C-a, C-e, C-f, C-p and
>>> so on the way Emacs does.
>> 
>> That's because AFAIK Mac OSX is a descendant of the BSD Unix family.
>> Quite a few Unix programs support Emacs-style key bindings.

JD> That is probably one reason.  But the Mail.app and TextEdit.app on Mac OSX
JD> are not descendant from any BSD programs, so Apple is extending these
JD> bindings to new programs as well.

Cocoa applications have these bindings in text fields.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Richard Stallman]

Emacs is primarily for superusers.  In my vision of the GNU system, we
should change GNOME so that it presents Emacs as the editor, and GNOME
programs should offer Emacs key bindings wherever they could be used.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Lars Brinkhoff]

Richard Stallman <rms@gnu.org> writes:
> Emacs is primarily for superusers.  In my vision of the GNU system, we
> should change GNOME so that it presents Emacs as the editor, and GNOME
> programs should offer Emacs key bindings wherever they could be used.

I think it would be nice if every editable text field in GNOME were
actually an Emacs buffer.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Jan Nieuwenhuizen]

Lars Brinkhoff writes:

> I think it would be nice if every editable text field in GNOME were
> actually an Emacs buffer.

That would be so very good.  Doesn't that mean that Emacs should be a
bonobo component.  I seem to remember that some preliminary work has
been done on this but was halted?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Emacs is primarily for superusers.  In my vision of the GNU system,
> we should change GNOME so that it presents Emacs as the editor,

My GNOME uses Emacs as an Editor (actually, mostly emacsclient):
that's easily configurable.

> and GNOME programs should offer Emacs key bindings wherever they
> could be used.

Basic Emacs keybindings are pretty prevalent.

But I would like to stress a point you make: "Emacs is primarily for
superusers".  A superuser will always be required to learn the editors
he has to maintain, support and explain for the users of the systems
he is a superuser of.  As long as the superuser can't with a good
conscience throw Emacs at his users, he is not free to use the editor
he prefers.

If somebody asks me about a text manipulation problem, and I tell him
"just use this one-liner in Emacs" and he says "Forget it.  I don't
have a week to spare.  How do I do this in KEdit?", this ultimately
forces me to acquire skills with inferior tools in order to kludge
along.

And there are quite a few things that can only reasonably be done with
Emacs.  So I have a vested interest in moving Emacs to a state where
one can throw it at a newbie without preconfiguration and can hope for
a tolerable balance of achieved tasks and incited frustration even on
early parts of the learning curve.  The question "is it really worth
it?" should, if possible, not come up again and again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings

[Lars Hansen]

David Kastrup wrote:

>And there are quite a few things that can only reasonably be done with
>Emacs.  So I have a vested interest in moving Emacs to a state where
>one can throw it at a newbie without preconfiguration and can hope for
>a tolerable balance of achieved tasks and incited frustration even on
>early parts of the learning curve.  The question "is it really worth
>it?" should, if possible, not come up again and again.
>  
>
I agree :-)

What I wanted to point out: Emacs can satisfy superusers (maybe the term 
advanced users is more precise) as well as newbies. It is "just" matter 
of an easy way to choose a complete keybinding scheme (in my dreams 
only? ;-)

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Thien-Thi Nguyen]

David Kastrup <dak@gnu.org> writes:

   As long as the superuser can't with a good conscience throw
   Emacs at his users, he is not free to use the editor he
   prefers.

because naked emacs may be seen as an unkindness in some
cultures, the crafty superuser throws instead an emacs wrapped
in session-, site-, or user-specific customizations.

   If somebody asks me about a text manipulation problem, and
   I tell him "just use this one-liner in Emacs" and he says
   "Forget it.  I don't have a week to spare.  How do I do
   this in KEdit?", this ultimately forces me to acquire
   skills with inferior tools in order to kludge along.

or you could write the one-liner into a file, add five lines
of comment and/or docstring, and place the file in some shared
directory where it can be accessed in the future, and studied
and improved as time permits.  this can be done by all users.

   The question "is it really worth it?" should, if possible,
   not come up again and again.

IMHO, that kind of question is always pertinent.  the answer
may gradually shift from no to yes, as the environment (which
includes machines, regular users, and any superusers floating
in the vicinity) changes.  if the answer does not shift and
the superusers floating in the vicinity do not effect change,
that says more about those superusers than the question.  if
the answer shifts from yes to no precisely due to actions of
the superusers floating in the vicinity, the situation has
degraded into the hell of proprietary software, which is in
the case of emacs, ironic, and in any case, sad.

thi

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

Thien-Thi Nguyen <ttn@glug.org> writes:

> David Kastrup <dak@gnu.org> writes:
> 
>    As long as the superuser can't with a good conscience throw
>    Emacs at his users, he is not free to use the editor he
>    prefers.
> 
> because naked emacs may be seen as an unkindness in some cultures,
> the crafty superuser throws instead an emacs wrapped in session-,
> site-, or user-specific customizations.

It is not only in a closed shop that my expertise is appreciated.
For example, I am a frequent poster in comp.text.tex and other Usenet
groups.  I can start advice with "if you use Emacs, it is a matter
of..."  I can't start advice with "if you happen to have a service
contract with me and I installed and maintain your copy of Emacs, you
could..."

It is the difference between "with Emacs, you could" and "with my
Emacs, I can".  The latter is gloating rather than helping.

And I don't think we should strive for superuser lock-in: painful
experiences whenever users switch between administrators.  Emacs
should by and large be delivered in a useful state for everyone
without the need for serious reconfiguration.  The better we can
achieve that goal, the more universal Emacs experience becomes.

>    If somebody asks me about a text manipulation problem, and I tell
>    him "just use this one-liner in Emacs" and he says "Forget it.  I
>    don't have a week to spare.  How do I do this in KEdit?", this
>    ultimately forces me to acquire skills with inferior tools in
>    order to kludge along.
> 
> or you could write the one-liner into a file, add five lines of
> comment and/or docstring, and place the file in some shared
> directory where it can be accessed in the future, and studied and
> improved as time permits.  this can be done by all users.

They will still need to use Emacs.

>    The question "is it really worth it?" should, if possible, not
>    come up again and again.
> 
> IMHO, that kind of question is always pertinent.  the answer
> may gradually shift from no to yes, as the environment (which
> includes machines, regular users, and any superusers floating
> in the vicinity) changes.  if the answer does not shift and
> the superusers floating in the vicinity do not effect change,
> that says more about those superusers than the question.

Superusers stand on the shoulders of developers.  On the shoulder of
giants, even dwarfs can look far.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Thien-Thi Nguyen]

David Kastrup <dak@gnu.org> writes:

   It is the difference between "with Emacs, you could" and "with my
   Emacs, I can".  The latter is gloating rather than helping.

the middle path of the superuser is to find a way to say "with our
Emacs, we can", with "our" being the operative word that implies local
customizations set up by the superuser but (with the right attitudes all
around) maintainable by all the users.

   And I don't think we should strive for superuser lock-in: painful
   experiences whenever users switch between administrators.  Emacs
   should by and large be delivered in a useful state for everyone
   without the need for serious reconfiguration.  The better we can
   achieve that goal, the more universal Emacs experience becomes.

hopefully the crafty superusers are also light-hearted and not prone to
such bouts of insecurity, but in general what superusers do we cannot
control anyway.  i disagree w/ the "by and large" statement on grounds
that it is not feasible to know what is useful for everyone.

   They will still need to use Emacs.

yes (i don't see this as a matter of contention).

   Superusers stand on the shoulders of developers.  On the shoulder of
   giants, even dwarfs can look far.

although we cannot control superusers, they learn from attempts by the
programmers to control users, often by emulation.  if we give superusers
the tools they need to do the "leaf-node programming" that befits their
situation, w/o going overboard and attempting to control them, perhaps
they will in turn treat the users around them w/ similar courtesy.

even more abstractly, it is easier to point out flaws in emulation than
it is to maintain the neutral disenfranchisement of the middle layers in
a relationship.  IMHO, given emacs' maturity and reach, the latter is
not even desirable (although it may have been in the past).

thi

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: 27 Apr 2004 11:54:51 +0200
> 
> So I have a vested interest in moving Emacs to a state where one can
> throw it at a newbie without preconfiguration and can hope for a
> tolerable balance of achieved tasks and incited frustration even on
> early parts of the learning curve.

I'm with you on this one, but this goal cannot be really translated
into practical tasks before we agree on what we want the newbie to be
able to accomplish without spending a weekend learning Emacs.  For
example, the basic editing tasks---cursor motion, text insertion and
deletion, and visiting and saving files---support the standard keys
and menu-bar items that every newbie should be able top find easily,
even without reading the docs.

Menu suggestion

[David Kastrup]

We have the "Options" menu "CUA-style cut and paste"

I think we should rename this to something like

"C-x/C-c/C-v cut and paste"

or "PC-like cut and paste".

Now both names are obviously less complete and accurate as the current
menu.

The problem with the current menu name, however, is that nobody has a
clue what "CUA-style" is.  Or at least: those that _do_ know CUA-style
by name would have no trouble whatsoever to figure out the meaning of
the less precise names.

Whereas the other way round things happen to be different...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Menu suggestion

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> We have the "Options" menu "CUA-style cut and paste"
> 
> I think we should rename this to something like
> 
> "C-x/C-c/C-v cut and paste"
> 
> or "PC-like cut and paste".
> 
> Now both names are obviously less complete and accurate as the current
> menu.

If you hoover the cursor over that menu item, it says:

        Use C-z/C-x/C-c/C-v for undo/cut/copy/paste

I don't mind changing the menu text if people can agree on
something better.

> 
> The problem with the current menu name, however, is that nobody has a
> clue what "CUA-style" is.  Or at least: those that _do_ know CUA-style
> by name would have no trouble whatsoever to figure out the meaning of
> the less precise names.
> 
> Whereas the other way round things happen to be different...

I had a wild idea some time ago --

Let the tutorial start out by telling about the ability to turn on
CUA-mode for the benefit of users who are used to the C-x C-c etc.
And of course how to do it.

Then, if the user actually turns on CUA-mode at this point (or has
done so already), the tutorial should automatically shift to show how
to use emacs with the CUA-style bindings.  

A big advantage of this would be that the tutorial could just skip all
about native navigation --a user who already uses C-x C-c etc before
he starts learning emacs will also be using the cursor keys, pgdn
pgup, etc.  So there's no reason to tell him about C-f C-b etc, or C-v
M-v etc.  (and C-v doesn't work the emacs way anyway...).

This means that the average user will have a faster path to start
using emacs...

I know the keyboard purist elite is very fond of emacs' traditional
bindings, but they do make emacs more difficult to learn than
emacs+CUA.

WDYT about a CUA-aware tutorial.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Menu suggestion

[Richard Stallman]

    If you hoover the cursor over that menu item, it says:

	    Use C-z/C-x/C-c/C-v for undo/cut/copy/paste

There is no need to make the menu item complete
in describing the changes this mode makes.

    C-x/C-c/C-v cut and paste

would be better for the menu item text.
The rest of the info could be in a help string.

    A big advantage of this would be that the tutorial could just skip all
    about native navigation --a user who already uses C-x C-c etc before
    he starts learning emacs will also be using the cursor keys, pgdn
    pgup, etc.  So there's no reason to tell him about C-f C-b etc, or C-v
    M-v etc.  (and C-v doesn't work the emacs way anyway...).

I disagree.  We want users to be offered the chance to learn
the efficient ways to do these things.

Also, this proposal would require two versions of all the translated
tutorials.  That just seems like too much work.

    I know the keyboard purist elite is very fond of emacs' traditional
    bindings, but they do make emacs more difficult to learn than
    emacs+CUA.

Why do you think the traditional Emacs bindings are harder to learn
than these bindings?

Default Emacs keybindings (was: Re: Menu suggestion)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> Why do you think the traditional Emacs bindings are harder to learn
> than these bindings?

The are two possibilities:

1. Emacs is not the first computer program the user learns.

In that case, chances is that the user already know and expects the
CUA bindings. 

2. Emacs *is* the first computer program the user learns.

In that case, learning the next computer program will be harder,
because the next computer program will use CUA bindings.

...

In that last decade, a (rough and partial) consensus on key bindings
has been building.  A user can switch between MacOS, MS Windows,
Gnome, and KDE applications, and still expect a certain level of
consistency between the bindings.

I believe it would be in the best long time interest of our community,
if Emacs joined that consensus.  In practice, the CUA bindings (not
the CUA code) should be default, and the documentation should reflect
that.  A very visible and complete "traditional" mode would be needed
though, at least as good as CUA mode, just doing the opposite.

...

In my day job, I write a text based scientific application.  I use
Emacs to edit the setup files and run the application myself, of
course.  But when I teach people to use the application, I cannot in
good conscience teach them to use it with Emacs.  The course is
"nitrogen dynamics in soil", not "Emacs 101".  Instead I pick a lesser
editor, one they haven't used before, but which they can pickup in no
time because it stays within the consensus UI.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Luc Teirlinck]

Per Abrahamsen wrote:

   2. Emacs *is* the first computer program the user learns.

   In that case, learning the next computer program will be harder,
   because the next computer program will use CUA bindings.

I guess that must assume that the user is using MS windows or Mac OS
specific applications.  Emacs is _not_ the only application I use and
I have never seen C-c used to copy (in nearly all applications I use
C-c is used in the sense of "interrupt"), I have never seen C-x used
to cut, C-z to undo (instead it systematically seems to mean
"suspend") or C-v to paste (instead it seems to have, outside of
Emacs, a meaning of "insert literally").  Nearly all applications I
use, use key bindings that are inspired by Emacs, or let the user
choose between Emacs or VI style bindings

Sincerely,

Luc.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Alan Mackenzie]

On Mon, 26 Apr 2004, Per Abrahamsen wrote:

>Richard Stallman <rms@gnu.org> writes:

>> Why do you think the traditional Emacs bindings are harder to learn
>> than these bindings?

>The are two possibilities:

>1. Emacs is not the first computer program the user learns.

>In that case, chances is that the user already know and expects the
>CUA bindings. 

>2. Emacs *is* the first computer program the user learns.

>In that case, learning the next computer program will be harder,
>because the next computer program will use CUA bindings.

>...

>In that last decade, a (rough and partial) consensus on key bindings has
>been building.  A user can switch between MacOS, MS Windows, Gnome, and
>KDE applications, and still expect a certain level of consistency
>between the bindings.

The point of these bindings is surely ease of learning rather than ease
of use:  "Just hold down the <shift> and move the cursor!"

>I believe it would be in the best long time interest of our community,
>if Emacs joined that consensus.  In practice, the CUA bindings (not the
>CUA code) should be default, and the documentation should reflect that.
>A very visible and complete "traditional" mode would be needed though,
>at least as good as CUA mode, just doing the opposite.

I can't agree there.  Emacs is very solidly in the "easy to use, a pig to
learn" camp.  If you make make CUA bindings default so as to make it
easier to learn superficially, you'll make it harder to learn "properly".
The result will be masses of users learning it only superficially, and
thus not getting the full benefit of Emacs.  We'll have a product which
is still a pig to learn, but no longers has such good reasons to do so.

[I'm taking it for granted here that the Emacs standard bindings are
vastly superior to the CUA bindings.  If anybody disagrees with me on
this point, please don't use this mailing list to try and change my mind.
;-]

>In my day job, I write a text based scientific application.  I use Emacs
>to edit the setup files and run the application myself, of course.  But
>when I teach people to use the application, I cannot in good conscience
>teach them to use it with Emacs.  The course is "nitrogen dynamics in
>soil", not "Emacs 101".  Instead I pick a lesser editor, one they
>haven't used before, but which they can pickup in no time because it
>stays within the consensus UI.

With all due respect, Emacs is no program for casual users.  It's for
serious programmers or other writers, who're going to be spending
thousands of hours writing/hacking, and for whom the ~hundred hours
learning time is a very sound investment.  Even if Emacs was equipped
with CUA bindings, it still wouldn't be a good tool to give nitrogen
hackers.  Something easier to learn, something more NOxious, like
[proprietory product name deleted] is better here.

-- 
Alan Mackenzie (Munich, Germany)

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Mon, 26 Apr 2004, Per Abrahamsen wrote:
> 
> >In that last decade, a (rough and partial) consensus on key bindings has
> >been building.  A user can switch between MacOS, MS Windows, Gnome, and
> >KDE applications, and still expect a certain level of consistency
> >between the bindings.
> 
> The point of these bindings is surely ease of learning rather than ease
> of use:  "Just hold down the <shift> and move the cursor!"
> 
> >I believe it would be in the best long time interest of our
> >community, if Emacs joined that consensus.  In practice, the CUA
> >bindings (not the CUA code) should be default, and the
> >documentation should reflect that.  A very visible and complete
> >"traditional" mode would be needed though, at least as good as CUA
> >mode, just doing the opposite.
> 
> I can't agree there.

Me neither.  If we have a need for a separate significantly different
traditional mode, we lose most of our advantage.  CUA-mode, IIRC,
assigns special meaning to its characters only when there is an active
selection.  It is a compromise, of course.  (I think we still are not
there with regard to consistent selection behavior where we should be,
but that's a somewhat different problem).

If what I think I understood from the CUA descriptions is correct, no
key sequences starting with C-c or C-x can be used with an active
selection.  For example, selecting an active region and using
C-c C-e in AUCTeX (inserts environment around an active region, if
there is one) would not work in CUA mode, ever.  Neither would any of
a number of minor mode bindings designed to also work on active
regions.

> Emacs is very solidly in the "easy to use, a pig to learn" camp.  If
> you make make CUA bindings default so as to make it easier to learn
> superficially, you'll make it harder to learn "properly".  The
> result will be masses of users learning it only superficially, and
> thus not getting the full benefit of Emacs.

Which is their full right to do.  99% of all video recorder owners
learn the operation of their device only superficially, thus not
getting the full benefit of video recorders.

Still, nobody suggests that the "solution" is to make the handling of
a video recorder so obfuscate to the average person familiar with
other devices, that he will be lost without reading through an
instruction booklet.

Who is to decide that somebody being able to utilize a tool without
having full grasp of all its possibilities is a bad thing?

> >In my day job, I write a text based scientific application.  I use
> >Emacs to edit the setup files and run the application myself, of
> >course.  But when I teach people to use the application, I cannot
> >in good conscience teach them to use it with Emacs.  The course is
> >"nitrogen dynamics in soil", not "Emacs 101".  Instead I pick a
> >lesser editor, one they haven't used before, but which they can
> >pickup in no time because it stays within the consensus UI.
> 
> With all due respect, Emacs is no program for casual users.

With all due respect, who are you to decree who should not be using
Emacs?

> It's for serious programmers or other writers, who're going to be
> spending thousands of hours writing/hacking, and for whom the
> ~hundred hours learning time is a very sound investment.

I am a serious programmer and other writer.  And my learning time is
not a sound investment if I can't use Emacs as an application platform
for editing functionality that I can never hope to have customers of
mine wanting to use.

> Even if Emacs was equipped with CUA bindings, it still wouldn't be a
> good tool to give nitrogen hackers.

So we need more changes if we want to have Emacs at one time something
which does not require turning people into hackers before they can
expect to be comfortable using Emacs.

That's ok.  Nobody expects that we will finish this task in a single
step.  And blindly enabling any mode that is supposed to make things
more mainstream-like, without assessing its drawbacks and trying to
remove them where possible, would be insane.

But such modes at least can provide a basis for discussion in what
manner we can accommodate people without a determination to completely
start from scratch before being allowed to start using a good editor.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Me neither.  If we have a need for a separate significantly different
> traditional mode, we lose most of our advantage.  CUA-mode, IIRC,
> assigns special meaning to its characters only when there is an active
> selection.  

Right.

>             It is a compromise, of course.  (I think we still are not
> there with regard to consistent selection behavior where we should be,
> but that's a somewhat different problem).

Can you emphasize on what's missing...


> If what I think I understood from the CUA descriptions is correct, no
> key sequences starting with C-c or C-x can be used with an active
> selection.  For example, selecting an active region and using
> C-c C-e in AUCTeX (inserts environment around an active region, if
> there is one) would not work in CUA mode, ever.  

That's completely untrue!!

There are actually three ways to enter C-c C-e even when the region is
active:

1) Type the C-c C-e very quickly (the quicklyness is configurable).
2) Type C-c C-c quickly, followed by C-e
3) Type S-C-c C-e

1 can be used for a sequence of control characters (i.e. where you hold
  down CTRL during the whole sequence).

2 can be used generally, typing C-c C-c (or C-x C-x) very quickly is
  trivial, then you can complete the rest of the sequence at your own pace.

3 can be used generally, at any pace.

Which method to prefer is a personal choice.  I use all of them, but
in reality, I use them VERY rarely -- and I have cua mode turned on
permanently, and have been using it (in many versions) since 1997.

One reason I don't need them is that cua has integrated register and
rectangle support in the normal C-c and C-x bindings, i.e. I never
use any of the standard register or rectangle commands.

Example:  Mark a rectangle, copy it to a register, move to another
place and insert the rectangle from that register:

S-RET (start marking of rectangle)

move the cursor to extend the rectangle (notice that with cua you
can extend the rectangle beyond the end of the current line).

M-2 C-c  => copy rectangle to register 2

.. move somewhere else

M-2 C-v  => insert rectangle from register 2


It's just so simple, that I don't need the "efficient" emacs
bindings (that I never manage to remember anyway).

So for me, this is practically a non-problem.

> > Emacs is very solidly in the "easy to use, a pig to learn" camp.  If
> > you make make CUA bindings default so as to make it easier to learn
> > superficially, you'll make it harder to learn "properly". 


I don't see how C-x r r 2 is "easier to use" than M-2 C-c -- but I
agree that it is "a pig to learn" :-)

> > Even if Emacs was equipped with CUA bindings, it still wouldn't be a
> > good tool to give nitrogen hackers.
> 
> So we need more changes if we want to have Emacs at one time something
> which does not require turning people into hackers before they can
> expect to be comfortable using Emacs.

Could we have some comments from users of CUA, please!

The current thread of emacs users who have never used CUA discuss
whether it is useful or not seems like a waste of time...

> 
> That's ok.  Nobody expects that we will finish this task in a single
> step.  And blindly enabling any mode that is supposed to make things
> more mainstream-like, without assessing its drawbacks and trying to
> remove them where possible, would be insane.

Please list those drawbacks -- so I can fix them.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Me neither.  If we have a need for a separate significantly different
> > traditional mode, we lose most of our advantage.  CUA-mode, IIRC,
> > assigns special meaning to its characters only when there is an active
> > selection.  
> 
> Right.
> 
> >             It is a compromise, of course.  (I think we still are
> > not there with regard to consistent selection behavior where we
> > should be, but that's a somewhat different problem).
> 
> Can you emphasize on what's missing...

If transient-mark-mode is active, the region lights up at
inconvenient times.  Also there are moments when the region becomes
inactive at inconvenient times, and having to reactivate it with C-x
C-x based on the presence or absence of visual feedback is a nuisance.

Temporary transient mark mode (C-SPC C-SPC or C-u C-x C-x) is a real
life-saver, but the choice of keybindings for it clearly indicates
that we are talking about a kludge for experts here instead of
functionality intended for "ordinary" users, and I don't think that
the tutorial even mentions it or its obtuse keybindings.

Also when explicitly marking a region with the mouse (dragging mouse-1
or clicking mouse-3), temporary transient mark mode should be enabled:
it is a safe bet that if the user marks out a _region_ for a command,
that he wants the command to be applied to the region instead of just
operating at point.  _If_ the command has special behavior for active
regions.

For the ordinary user that likes marking out stuff with a mouse, this
would go a lot towards making Emacs behave in a rational manner even
without one of the half-dozen modes fiddling around with various
amounts of transientness of the mark.

> > If what I think I understood from the CUA descriptions is correct,
> > no key sequences starting with C-c or C-x can be used with an
> > active selection.  For example, selecting an active region and
> > using C-c C-e in AUCTeX (inserts environment around an active
> > region, if there is one) would not work in CUA mode, ever.
> 
> That's completely untrue!!
> 
> There are actually three ways to enter C-c C-e even when the region is
> active:
> 
> 1) Type the C-c C-e very quickly (the quicklyness is configurable).
> 2) Type C-c C-c quickly, followed by C-e
> 3) Type S-C-c C-e
> 
> 1 can be used for a sequence of control characters (i.e. where you hold
>   down CTRL during the whole sequence).
> 
> 2 can be used generally, typing C-c C-c (or C-x C-x) very quickly is
>   trivial,

Unless you happen to be handicapped and use something like sticky key
modifiers to enter such sequences.

>   then you can complete the rest of the sequence at your own pace.
> 
> 3 can be used generally, at any pace.

So if I have a busy computer or a slow connection or accessibility
problems or slow typing, the only way to reliably compile a document
in AUCTeX (C-c C-c) is to use

  S-C-c C-c

which is not the most friendly keysequence to type.  Also, the meaning
and/or naming of commands changes depending on whether the region is
active or not.

The total behavior is much more complex than I'd care to explain
within the scope of a tutorial.

It's a rather expensive compromise, I feel.

> The current thread of emacs users who have never used CUA discuss
> whether it is useful or not seems like a waste of time...

Why?  All will be concerned with changes.  And CUA mode is an expert
mode to enable "conventional" bindings.  It changes the behavior of
standard commands in undocumented ways with regard to Emacs'
self-documentation commands (commands like C-h w, C-h k, menus and so
on all talk about one set of keybindings that silently is replaced by
something different when a region is active).

Explaining Emacs' behavior with CUA-mode is quite more complicated
than it is without it.

So there is a non-zero cost associated with CUA-mode.  One way to
make it less costly would be to change all keybindings involving C-c
and C-x.  Another would be to offer a pseudo-CUA mode where instead
s-c, s-x, s-v and s-z would be affected: most PC-keyboards nowadays
offer a "Windows" key, not unrarely mapped to the Super modifier.  As
those bindings are on the "Apple" key on Macs, this would not be as
wildly crazy as it may sound.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Luc Teirlinck]

David Kastrup <dak@gnu.org> wrote:

   So if I have a busy computer or a slow connection or accessibility
   problems or slow typing, the only way to reliably compile a document
   in AUCTeX (C-c C-c) is to use

     S-C-c C-c

   which is not the most friendly keysequence to type.  Also, the meaning
   and/or naming of commands changes depending on whether the region is
   active or not.

Actually, if your connection would be as slow as mine you would be
forced to run emacs -nw and there would be no difference between 
S-C-c C-c and C-c C-c.

Per and others have suggested making the CUA bindings the _default_.
Bindings that do not work on text only terminals, such as shifted
arrow keys and shifted control characters, are unacceptable for
important _default_ bindings, unless they have well-documented
alternatives.  But then the user has to learn _two_ sets of bindings.
This applies not just to CUA.  I believe that, whenever _any_ changes
to default bindings or manuals descriptions are discussed, text only
terminals, and, in particular, emacs -nw, should not be ignored.

Sincerely,

Luc.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Stefan Monnier]

> Also when explicitly marking a region with the mouse (dragging mouse-1
> or clicking mouse-3), temporary transient mark mode should be enabled:

Funny you should mention that: I thought about it two days ago and was
about to propose it.

> it is a safe bet that if the user marks out a _region_ for a command,
> that he wants the command to be applied to the region instead of just
> operating at point.  _If_ the command has special behavior for active
> regions.

Obviously I completely agree.

>> 1) Type the C-c C-e very quickly (the quicklyness is configurable).
>> 2) Type C-c C-c quickly, followed by C-e
>> 3) Type S-C-c C-e

CUA-mode is a really neat mode, but I think it will have to stay as
a "compatibility tool" at least for the forseeable future.  Too many of its
features have as sole purpose to work around the presence of
old-style bindings.  Great for CUA-mode's purpose, but not so convincing
for a default mode of operation.

What I'd like to see is a move to discourage the use of hardcoded "C-c",
"C-x" and such in bindings setup by packages.  Instead we should provide
ctl-x-prefix and major-mode-prefix as aliases for C-x and C-c and
make packages use those.  Then we can hope to later change the bindings
(either by default or just in CUA-mode) in a more robust way.


        Stefan

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Also when explicitly marking a region with the mouse (dragging mouse-1
> > or clicking mouse-3), temporary transient mark mode should be enabled:
> 
> Funny you should mention that: I thought about it two days ago and was
> about to propose it.
> 
> > it is a safe bet that if the user marks out a _region_ for a command,
> > that he wants the command to be applied to the region instead of just
> > operating at point.  _If_ the command has special behavior for active
> > regions.
> 
> Obviously I completely agree.

While we are in agreement: the visual indication of
transient-mark-mode and of marking with the mouse is the same.  Yet
if I type DEL after marking a region with the mouse, the region is
killed, but with transient-mark-mode, only a single character gets
killed.

I think it appropriate to unify the behavior in that respect as well.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Stefan Monnier]

> Also when explicitly marking a region with the mouse (dragging mouse-1
> or clicking mouse-3), temporary transient mark mode should be enabled:

I had actually completely forgotten that I had already implemented it in my
local hacks.
What do people say about the following little patch?


        Stefan


--- mouse.el	29 Apr 2004 12:26:26 -0400	1.245
+++ mouse.el	29 Apr 2004 15:27:48 -0400	
@@ -617,6 +617,8 @@
     (mouse-set-region-1)))
 
 (defun mouse-set-region-1 ()
+  ;; Set transient-mark-mode for a little while.
+  (setq transient-mark-mode (or transient-mark-mode 'lambda))
   (setq mouse-last-region-beg (region-beginning))
   (setq mouse-last-region-end (region-end))
   (setq mouse-last-region-tick (buffer-modified-tick)))

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Richard Stallman]

    Also when explicitly marking a region with the mouse (dragging mouse-1
    or clicking mouse-3), temporary transient mark mode should be enabled:
    it is a safe bet that if the user marks out a _region_ for a command,
    that he wants the command to be applied to the region instead of just
    operating at point.  _If_ the command has special behavior for active
    regions.

Did this change get made?

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Stefan Monnier]

>     Also when explicitly marking a region with the mouse (dragging mouse-1
>     or clicking mouse-3), temporary transient mark mode should be enabled:
>     it is a safe bet that if the user marks out a _region_ for a command,
>     that he wants the command to be applied to the region instead of just
>     operating at point.  _If_ the command has special behavior for active
>     regions.

> Did this change get made?

Do you mean the one I suggested (see below)?
If so, no.  Should I?


        Stefan


--- mouse.el	29 Apr 2004 12:26:26 -0400	1.245
+++ mouse.el	29 Apr 2004 15:27:48 -0400	
@@ -617,6 +617,8 @@
     (mouse-set-region-1)))
 
 (defun mouse-set-region-1 ()
+  ;; Set transient-mark-mode for a little while.
+  (setq transient-mark-mode (or transient-mark-mode 'lambda))
   (setq mouse-last-region-beg (region-beginning))
   (setq mouse-last-region-end (region-end))
   (setq mouse-last-region-tick (buffer-modified-tick)))

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >     Also when explicitly marking a region with the mouse (dragging mouse-1
> >     or clicking mouse-3), temporary transient mark mode should be enabled:
> >     it is a safe bet that if the user marks out a _region_ for a command,
> >     that he wants the command to be applied to the region instead of just
> >     operating at point.  _If_ the command has special behavior for active
> >     regions.
> 
> > Did this change get made?
> 
> Do you mean the one I suggested (see below)?
> If so, no.  Should I?

You got my vote for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Richard Stallman]

Please install the change; we will see if anyone complains.

Re: Default Emacs keybindings (was: Re: Menu suggestion)

[Stefan Monnier]

>  (defun mouse-set-region-1 ()
> +  ;; Set transient-mark-mode for a little while.
> +  (setq transient-mark-mode (or transient-mark-mode 'lambda))
>    (setq mouse-last-region-beg (region-beginning))

Installed,


        Stefan