Menu suggestion

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

[Robert J. Chassell]

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

On my PC, I cut and paste using the traditional Emacs bindings, so
the second proposal, "PC-like", is ambiguous.

The first is excellent, since it tells some people they will want to
use those key bindings and tells me what to avoid.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

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

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I guess that must assume that the user is using MS windows or Mac OS
> specific applications. 

Or KDE or Gnome applications.

The consensus is less than a decade old, many applications have roots
older than that.

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

Re: Default Emacs keybindings

[Stefan Daschek]

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

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

I use CUA, however ... my .emacs contains (setq cua-enable-cua-keys
nil). That's because I've been using S-Del, C-Ins and S-Ins for cut,
copy, and paste respectively since the old days of Borland C++ 3.1
running under MS DOS 5. Since those days I'm used to selecting text by
holding the shift key and then using the cursor keys (interestingly
enough even my current mobile phone, a nokia 7650, uses this
convention - holding down a modifier key and moving the cursor - for
selecting text).

Those shortcuts still work in (almost) all applications under Windows
or KDE/Gnome, in my favourite terminal emulator (PuTTY) they are even
the only way to do copy&paste from the keyboard.

Of course there is a drawback: S-Del, C-Ins, and S-Ins, as well as
shifted cursor movement do not work in emacs -nw. That's why I find
myself constantly using Tramp for editing remote files. I do use Emacs
remotely over ssh, but only for quite simple editing tasks.

As far as "learning emacs" is concerned: When I started using Emacs,
among the first things I did was enabling pc-selection-mode, finding
out about CUA, and defining a bunch of keybindings that are common
under standard Windows applications (e.g. C-s for save-buffer, M-F4
for save-buffers-kill-emacs, etc.). I did that not because I wanted
Emacs to be like any other Windows application, but just to make it
possible for me to learn Emacs gradually. After all, I had to get my
work done, and as I had decided that the only way of really learning
Emacs is to really use it, I had to get my work done with Emacs. Even
with all the customizations I did the first weeks of using Emacs were
quite hard and sometimes frustrating for me, many things did not work
as I expected and I felt less productive than before. But as time went
by I gradually learned about "The Emacs Way of doing it" and so I got
rid of many of those "backward-compatibility" customizations -- not
all at once, but bit by bit -- and started using all those great
unique features of Emacs. 

Nowadays I sometimes find myself pressing C-x C-s to save a document
in Powerpoint or Excel ... :)

My point is: I think it's neither possible nor sensible to learn Emacs
from scratch if you have already some experience with other "standard"
applications (and nowadays it could be quite hard to find someone who
hasn't this experiences). In Emacs' default configuration almost
nothing works as one would expect it, and so the possibility of
getting frustrated and never have a look at Emacs again is quite high.
However, what does work quite well is to start using Emacs almost like
a standard Windows/Gnome/KDE/MacOS application and then gradually
learn about the powerful Emacs features.

I think Emacs should encourage new users willing to learn Emacs as
much as possible. Maybe it would be a good idea to implement something
like a "First-time-user's wizard"? This wizard could guide a new user
through several basic (but important) steps of customizing. For
example, it could ask the user something like "Enable C-x/C-c/C-v
shortcuts for copy&paste?" Together with this question Emacs should
display a short explanation that (and how) enabling this option will
interfere with the standard Emacs keybindings and how to turn it off
again etc. 

I'm not sure about what other questions this "wizard" should ask,
maybe it would be necessary to make a survey among Emacs-"newbies" to
find out.

Okay enough for now, any comments appreciated :)

ciao,
noniq

Re: Default Emacs keybindings

[Per Abrahamsen]

Alan Mackenzie <acm@muc.de> writes:

> With all due respect, Emacs is no program for casual users.  

True, today.

Lars Hansen described our choice here pretty well.

And no, I do not agree that the Emacs key bindings are inherently
superior for experienced users.  They just happen to be what we are
used to.

Re: Default Emacs keybindings

[Miles Bader]

On Fri, Apr 30, 2004 at 03:06:00PM +0200, Per Abrahamsen wrote:
> And no, I do not agree that the Emacs key bindings are inherently
> superior for experienced users.  They just happen to be what we are
> used to.

Well it kind of depends on _which_ keybindings you're talking about -- some
emacs keybindings are just familiar, but others are pretty clearly more
better in some cases.  Obviously C-w is basically no better or worse than
C-x, but the emacs-movment vs. arrow keys issue is quite different, the
former being (obviously) far more efficient for a user that meets their
criteria, but the latter being easier for an inexperienced user.

Unfortunately in this limited namespace, it's hard to mix'n'match (despite
Kim's valiant efforts), but luckily we _can_ have both arrow keys and
emacs-movement keys.

Also luckily, emacs is popular enough among developers that a lot of
non-emacs software either understands basic emacs keystrokes (mozilla) or can
be easily configured to do so (gnome).

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Default Emacs keybindings

[Richard Stallman]

    And no, I do not agree that the Emacs key bindings are inherently
    superior for experienced users.  They just happen to be what we are
    used to.

I recall that someone did an experiment around 1980 to compare the
efficiency of editing with arrow keys and with C-f, C-b, etc.  The
result was that the arrow keys were less efficient.

Re: Default Emacs keybindings

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I recall that someone did an experiment around 1980 to compare the
> efficiency of editing with arrow keys and with C-f, C-b, etc.  The
> result was that the arrow keys were less efficient.

Probably he didn't use a keyboard with the control key at the "wrong"
place.  :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Default Emacs keybindings

[Richard Stallman]

    Probably he didn't use a keyboard with the control key at the "wrong"
    place.  :-)

You can get the Happy Hacking keyboard, which has control in the right
place.  Also, Linux has some sort of feature to redefine keys on the
keyboard.  My "caps lock" key is really a control key, and that is
what I normally use for the job.

Re: Default Emacs keybindings

[Miles Bader]

On Sun, May 02, 2004 at 03:52:07PM -0400, Richard Stallman wrote:
>     Probably he didn't use a keyboard with the control key at the "wrong"
>     place.  :-)
> 
> You can get the Happy Hacking keyboard, which has control in the right
> place.

Hey, yeah, I second that -- I've got two HH keyboards!

Besides correct key layout, they're also just nice svelte elegant keyboards,
a great change from the usual `10,000 ton keyboard entry battle-group'
usually included as standard.

The current `HH Lite 2' model even has arrow keys for non-believers like
Stefan and Kim. :-|  [They're like laptop arrow keys -- slightly smaller than
average keys, very close to the main section underneath the right shift key.]

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Default Emacs keybindings

[Lars Brinkhoff]

Miles Bader <miles@gnu.org> writes:
> On Sun, May 02, 2004 at 03:52:07PM -0400, Richard Stallman wrote:
> >     Probably he didn't use a keyboard with the control key at the "wrong"
> >     place.  :-)
> > You can get the Happy Hacking keyboard, which has control in the
> > right place.
> Hey, yeah, I second that -- I've got two HH keyboards!

I third that -- I have three.

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

Re: Default Emacs keybindings

[Kim F. Storm]

Lars Brinkhoff <lars@nocrew.org> writes:

> Miles Bader <miles@gnu.org> writes:
> > On Sun, May 02, 2004 at 03:52:07PM -0400, Richard Stallman wrote:
> > >     Probably he didn't use a keyboard with the control key at the "wrong"
> > >     place.  :-)
> > > You can get the Happy Hacking keyboard, which has control in the
> > > right place.
> > Hey, yeah, I second that -- I've got two HH keyboards!
> 
> I third that -- I have three.
> 


Now I understand -- to use the emacs bindings you have to buy a
special keyboard.  How convenient :-|

Are you serious ?

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

Re: Default Emacs keybindings

[Miles Bader]

On Mon, May 03, 2004 at 07:53:40AM +0200, Kim F. Storm wrote:
> Now I understand -- to use the emacs bindings you have to buy a
> special keyboard.  How convenient :-|

Geez, Kim, it's just a very nice keyboard.

To be honest, a standard keyboard isn't really much good for typing commands
at all -- on a standard keyboard _none_ of the non-shift modifier keys is in
a convenient position for the most efficient use of `modeless' editor like
emacs.

None.

So you really can't blame the emacs command set -- it's simply not possible
to do much better without either remapping something, or buying a better
keyboard.

> Are you serious ?

What about you?

-Miles
-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: Default Emacs keybindings

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Mon, May 03, 2004 at 07:53:40AM +0200, Kim F. Storm wrote:
> > Now I understand -- to use the emacs bindings you have to buy a
> > special keyboard.  How convenient :-|
> 
> Geez, Kim, it's just a very nice keyboard.

I don't doubt that.

> 
> To be honest, a standard keyboard isn't really much good for typing commands
> at all -- on a standard keyboard _none_ of the non-shift modifier keys is in
> a convenient position for the most efficient use of `modeless' editor like
> emacs.
> 
> None.

Well, I get by quite alright.  But they are not in an ideal position.
But reality is that the keys are where they are...

You and I may know how to make emacs (and other apps) use a better
keyboard layout (or may buy another keyboard), but most users don't
have that option (or don't know that they should even consider this).
They just think that emacs' default bindings are awkward...

> 
> So you really can't blame the emacs command set -- it's simply not possible
> to do much better without either remapping something, or buying a better
> keyboard.

I understand what you are saying, but I also think you contradict yourself.

Why insist on teaching (in the tutorial) new emacs users (which I bet
don't have a HH keyboard) to use bindings which you just admitted are
NOT convenient to use with today's standard keyboard layout.  

If those bindings are only superior in a special setup, why waste time
teaching/learning them?  That time would be better spent on teaching
some of the _useful_ features of emacs.

> 
> > Are you serious ?
> 
> What about you?

I am very serious!

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

Re: Default Emacs keybindings

[Miles Bader]

On Mon, May 03, 2004 at 09:32:47AM +0200, Kim F. Storm wrote:
> Why insist on teaching (in the tutorial) new emacs users (which I bet
> don't have a HH keyboard) to use bindings which you just admitted are
> NOT convenient to use with today's standard keyboard layout.  

It's not a boolean.

emacs-bindings + proper-keyboard  >  emacs-bindings  >  standard-bindings

> If those bindings are only superior in a special setup, why waste time
> teaching/learning them?  That time would be better spent on teaching some
> of the _useful_ features of emacs.

In the case of the particular bindings under discussion -- arrow keys
vs. C-f &c., the emacs keys are better bindings even with a suboptimal
control-key placement, because the arrow keys are enormous lose
efficiency-wise.

Whether they are sufficiently important to discuss first in the tutorial [*],
I have no idea, but those bindings are useful, and I think a good thing to
teach.

[*] Historically they were, because often users didn't have any arrow keys!
    Obviously this is not true anymore.

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

Re: Default Emacs keybindings

[Kai Grossjohann]

Miles Bader <miles@gnu.org> writes:

> To be honest, a standard keyboard isn't really much good for typing commands
> at all -- on a standard keyboard _none_ of the non-shift modifier keys is in
> a convenient position for the most efficient use of `modeless' editor like
> emacs.

The ESC key is also in the wrong position for that popular modeful
editor.  (What's the opposite of modeless?)

HHKL has ESC to the left of 1, which is where it should be.

Kai

Re: Default Emacs keybindings

[Jose E. Marchesi]

    On Mon, May 03, 2004 at 07:53:40AM +0200, Kim F. Storm wrote:
    > Now I understand -- to use the emacs bindings you have to buy a
    > special keyboard.  How convenient :-|
    
    Geez, Kim, it's just a very nice keyboard.
    
    To be honest, a standard keyboard isn't really much good for typing commands
    at all -- on a standard keyboard _none_ of the non-shift modifier keys is in
    a convenient position for the most efficient use of `modeless' editor like
    emacs.
    
    None.

I think the "normal" ctrl key position is ok, as long as there is
another ctrl key on the right of the keyboard. For a C-X keybinding
where X is on the right of the keyboard (such as C-p) i use the left
ctrl key. On the other hand, for a C-X keybinding where X is on the
left of the keyboard (such as C-a) i use the right ctrl key. I find
this way very comfortable.

So i only find advantages in using capslock as a ctrl key if the
right ctrl key is not used (or even not present on the keyboard). 

Unfortunately, not all keyboards has a right ctrl key. Indeed, i
usually use mac machines, so i must remap one of the keys with
extrange symbols located on the right of the spacebar to act as a
ctrl key.

Just my 2 euro cents.


-- 
José E. Marchesi 

<jemarch@gnu.org>         http://www.gnu.org     GNU No es Unix!
<jemarch@es.gnu.org>      http://es.gnu.org      GNU España

.---------------.
|    .-[]--.    |
|   [] `>[]-|   |  BEE GNU/Hurd            http://bee.es.gnu.org
|    `-.[]<-'   |               
._______________.    

Re: Default Emacs keybindings

[Jan Nieuwenhuizen]

Kim F. Storm writes:

> Now I understand -- to use the emacs bindings you have to buy a
> special keyboard.  How convenient :-|

This is what I seemed to notice too.  I do buy special keyboards,
or else do remapping.

> Are you serious ?

I think we may be getting somewhere here.  If the consensus is that
Emacs bindings (which I like, btw) are only convenient with special
keyboards or custom mappings, it might be good to reconsider the
default mapping that is used.  It may be helpful (for new users) if
the default mapping that Emacs uses is actually useful with the type
of keyboard that they are most probable to use.

Btw, Kim, (no offence intended), I think it makes a lot of sense for
people like (you and?) me, who use computers a lot, to look around for
and carefully choose a keyboard (and pointing device) that could make
their `work' more easy or relaxed.  I find the keyboard one of my most
important tools, that I like to pick carefully.

Jan.

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

Re: Default Emacs keybindings

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Kim F. Storm writes:
> 
> > Now I understand -- to use the emacs bindings you have to buy a
> > special keyboard.  How convenient :-|
> 
> This is what I seemed to notice too.  I do buy special keyboards,
> or else do remapping.

Sure.

> 
> > Are you serious ?
> 
> I think we may be getting somewhere here.  If the consensus is that
> Emacs bindings (which I like, btw) are only convenient with special
> keyboards or custom mappings, it might be good to reconsider the
> default mapping that is used.  It may be helpful (for new users) if
> the default mapping that Emacs uses is actually useful with the type
> of keyboard that they are most probable to use.

Exactly my point.  IMO, it is good that some of the developers
actually use the same keyboard (good or bad) as most of our users.

> 
> Btw, Kim, (no offence intended), I think it makes a lot of sense for
> people like (you and?) me, who use computers a lot, to look around for
> and carefully choose a keyboard (and pointing device) that could make
> their `work' more easy or relaxed.  I find the keyboard one of my most
> important tools, that I like to pick carefully.

I really liked my old PC keyboard which had the (10) function keys
to the left of the keyboard, the control key was in the "caps lock"
position, the "alt" key in the "ctrl" key position, and the esc key
to the left of the [1] key (IIRC).

It took some time to get used to the current PC keyboard layout, but
since I use different computers (and keyboards), I think would have a
hard time using them if I had to mentally switch keyboard layout
(ctrl/alt) depending on which PC I was currently using.

Anyway, as long as I can type as fast as my brain can think :-)
does it matter which keyboard I use?

BTW, I do carry a couple of old 3-button logitech mouse around that I
happen to like :-)

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

Re: Default Emacs keybindings

[Jan Nieuwenhuizen]

Kim F. Storm writes:

> Exactly my point.  IMO, it is good that some of the developers
> actually use the same keyboard (good or bad) as most of our users.

Good point.

> Anyway, as long as I can type as fast as my brain can think :-)
> does it matter which keyboard I use?

One of the main reasons for using dvorak-caps mapping or my maltron
keyboard is not so much speed of typing, but rather the more relaxed
feeling, less and smaller movements, with an eye on RSI prevention.

> BTW, I do carry a couple of old 3-button logitech mouse around that I
> happen to like :-)

:-) I think it would be good if we could get more gui app writers (the
gnome people, eg) to think about providing most efficient/convenient
ways to do stuff without having to use the mouse.

Jan.

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

Re: Default Emacs keybindings

[Per Abrahamsen]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Btw, Kim, (no offence intended), I think it makes a lot of sense for
> people like (you and?) me, who use computers a lot, to look around for
> and carefully choose a keyboard (and pointing device) that could make
> their `work' more easy or relaxed.

I used to do that.  Back when I was chained to a terminal down in the
cellar, and my only human contact was the supervisor who handed me a
bowel of gruel twice a day.  These days, I tend to move around a bit,
work on different computers, talk to users, and help them on their own
computers.  This has gotten a lot easier after I gave up special
hardware with foot pedals and the like, and instead learned to be
productive with standard tools and minimal customizations.

Re: Default Emacs keybindings

[Kenichi Handa]

In article <87n04paner.fsf@peder.flower>, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> I think we may be getting somewhere here.  If the consensus is that
> Emacs bindings (which I like, btw) are only convenient with special
> keyboards or custom mappings, it might be good to reconsider the
> default mapping that is used.  It may be helpful (for new users) if
> the default mapping that Emacs uses is actually useful with the type
> of keyboard that they are most probable to use.

Isn't it possible to make Emacs custom mappings if
requested, at least on X window?  For instance, M-x
swap-ctrl-capslock RET.

---
Ken'ichi HANDA
handa@m17n.org

Re: Default Emacs keybindings

[Jan Nieuwenhuizen]

Kenichi Handa writes:

> Isn't it possible to make Emacs custom mappings if requested, at
> least on X window?  For instance, M-x swap-ctrl-capslock RET.

Maybe so, but that mostly useless, as it doesn't fix it for other
applications.

Jan.

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

Re: Default Emacs keybindings

[Masatake YAMATO]

> > Isn't it possible to make Emacs custom mappings if requested, at
> > least on X window?  For instance, M-x swap-ctrl-capslock RET.

I like this idea.
 
> Maybe so, but that mostly useless, as it doesn't fix it for other
> applications.

swap-ctrl-capslock may be useful to create .Xmodmap file to swap control 
and capslock for other applications just after installing an Operating 
System to your PC. swap-ctrl-capslock is something like bootstrap code.

Masatake YAMATO

Re: Default Emacs keybindings

[Kenichi Handa]

In article <87zn8p914r.fsf@peder.flower>, Jan Nieuwenhuizen <janneke@gnu.org> writes:
> Kenichi Handa writes:
>>  Isn't it possible to make Emacs custom mappings if requested, at
>>  least on X window?  For instance, M-x swap-ctrl-capslock RET.

> Maybe so, but that mostly useless, as it doesn't fix it for other
> applications.

If we can have something like swap-ctrl-capslock, we can
mention it in TUTORIAL and make at least Emacs users
happier.

And, if we also want Emacs to fix mapping for the other
applications (I'm not sure), we can invoke the shell command
"xmodmap -e ..." which should fix for all applications
running on the same display.

---
Ken'ichi HANDA
handa@m17n.org

Re: Default Emacs keybindings

[Richard Stallman]

I do not want to change the Emacs key bindings drastically for the
usual keyboard mapping.  We already support the keys that beginning
users normally use.  That is enough catering to them.

What we should do is include prominent documentation telling users how
to remap their caps-lock key, with specific recipes.  (I have no idea
where to find this information for GNU/Linux.)

Re: Default Emacs keybindings

[Luc Teirlinck]

Richard Stallman wrote:

   What we should do is include prominent documentation telling users how
   to remap their caps-lock key, with specific recipes.  (I have no idea
   where to find this information for GNU/Linux.)

>From M-x man xmodmap:

       One of the more irritating differences  between  keyboards
       is  the  location  of  the Control and Shift Lock keys.  A
       common use of xmodmap is to swap these two  keys  as  fol-
       lows:

            !
            ! Swap Caps_Lock and Control_L
            !
            remove Lock = Caps_Lock
            remove Control = Control_L
            keysym Control_L = Caps_Lock
            keysym Caps_Lock = Control_L
            add Lock = Caps_Lock
            add Control = Control_L

I would guess that this works not just on GNU/Linux, but also on
various varieties of Unix as well.  I do not know about other
operating systems.

Sincerely,

Luc.

Re: Default Emacs keybindings

[Eli Zaretskii]

> Date: Mon, 3 May 2004 17:59:47 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> Richard Stallman wrote:
> 
>    What we should do is include prominent documentation telling users how
>    to remap their caps-lock key, with specific recipes.  (I have no idea
>    where to find this information for GNU/Linux.)
> 
> >From M-x man xmodmap:

xmodmap is only for working on X, IIRC it doesn't help if one runs
Emacs from a console or logs in remotely via a terminal emulator.  So
this is not a universal solution, not even on a GNU/Linux machine.

Re: Default Emacs keybindings

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> > Date: Mon, 3 May 2004 17:59:47 -0500 (CDT)
> > From: Luc Teirlinck <teirllm@dms.auburn.edu>
> > 
> > Richard Stallman wrote:
> > 
> >    What we should do is include prominent documentation telling users how
> >    to remap their caps-lock key, with specific recipes.  (I have no idea
> >    where to find this information for GNU/Linux.)
> > 
> > >From M-x man xmodmap:
> 
> xmodmap is only for working on X, IIRC it doesn't help if one runs
> Emacs from a console or logs in remotely via a terminal emulator.  So
> this is not a universal solution, not even on a GNU/Linux machine.

Catering for the most common usage is better than catering for none.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Default Emacs keybindings

[Alan Mackenzie]

On 4 May 2004, Eli Zaretskii wrote:

>> Date: Mon, 3 May 2004 17:59:47 -0500 (CDT)
>> From: Luc Teirlinck <teirllm@dms.auburn.edu>

>> Richard Stallman wrote:

>>    What we should do is include prominent documentation telling users
>>    how to remap their caps-lock key, with specific recipes.  (I have
>>    no idea where to find this information for GNU/Linux.)

The relevant man pages are loadkeys(1), dumpkeys(1), showkey(1) and
keytables(5)

>> >From M-x man xmodmap:

>xmodmap is only for working on X, IIRC it doesn't help if one runs Emacs
>from a console or logs in remotely via a terminal emulator.  So this is
>not a universal solution, not even on a GNU/Linux machine.

The Right Way to do this is to modify the Linux keyboard driver.  For
Linux running on an Intel PC, create a two-line file called (say)
/etc/keytab.CoLo with the following contents:

keycode 29 = Caps_Lock
keycode 58 = Control

Then, at a bash prompt (or, eventually, in a start-up script), do:

# loadkeys /etc/keytab.CoLo

[The scan codes of the pertinent keys on different hardware can be found
with showkeys, for example.]

There is a bug in the keyboard driver of my (shamefully out of date)
Linux kernel, in which after running this file, the keyboard is left in
"permanent control" state.  This can be worked around by specifying in
/etc/keytab.CoLo "Caps_Lock" or "Control" individually for each modifier
combination, as follows. 

keycode 29 = Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock
keycode 58 = Control Control Control Control Control Control Control Control Control Control Control

The number of "Caps_Lock"s necessary can be found from "dumpkeys -i".

-- 
Alan Mackenzie (Munich, Germany)

Re: Default Emacs keybindings

[Stefan Monnier]

> The Right Way to do this is to modify the Linux keyboard driver.

Any way which is unavailable to GNU/Linux *users* (as opposed to
administrators) can't be The Right Way.  So editing a /etc/foobar
file is out of the question.


        Stefan

Re: Default Emacs keybindings

[Alan Mackenzie]

On 4 May 2004, Stefan Monnier wrote:

>> The Right Way to do this is to modify the Linux keyboard driver.

>Any way which is unavailable to GNU/Linux *users* (as opposed to
>administrators) can't be The Right Way.  So editing a /etc/foobar
>file is out of the question.

Hmmm.  OK, fair point.  In that case, I'd suggest putting the said file
in one's home directory.  loadkeys doesn't (or, at least, didn't) require
superuser privileges.  I still say configuring the keyboard driver is the
right way to go.

>        Stefan

-- 
Alan Mackenzie (Munich, Germany)

Re: Default Emacs keybindings

[Luc Teirlinck]

Alan Mackenzie wrote:

   Hmmm.  OK, fair point.  In that case, I'd suggest putting the said file
   in one's home directory.  loadkeys doesn't (or, at least, didn't) require
   superuser privileges.  I still say configuring the keyboard driver is the
   right way to go.

Is it really a matter of choosing one or the other?  If I want the
remapping for the console, I need to use loadkeys.  That worked
perfectly for me on the console, with one big caveat to anybody else
who wants to try it out, which you already mentioned:

   There is a bug in the keyboard driver of my (shamefully out of date)
   Linux kernel, in which after running this file, the keyboard is left in
   "permanent control" state.  This can be worked around by specifying in
   /etc/keytab.CoLo "Caps_Lock" or "Control" individually for each modifier
   combination, as follows. 

   keycode 29 = Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock
   keycode 58 = Control Control Control Control Control Control Control Control Control Control Control

   The number of "Caps_Lock"s necessary can be found from "dumpkeys -i".

Yes indeed, and a permanent control state is no fun.

However, unless I did something wrong, this does not seem to work
under X.  Is there a way to make this work under X?  If not, we need
_both_ loadkeys and xmodmap, as, I believe, Robert Chassell already
remarked too.

Sincerely,

Luc.

Re: Default Emacs keybindings

[Luc Teirlinck]

Eli Zaretskii wrote:

   xmodmap is only for working on X, IIRC it doesn't help if one runs
   Emacs from a console or logs in remotely via a terminal emulator.

I indeed forgot about the console.  xmodmap _seems_ to work perfectly
however, when logging in remotely using emacs -nw from a gnome
terminal, which I am doing right now.

Sincerely,

Luc.

Re: Default Emacs keybindings

[Eli Zaretskii]

> Date: Tue, 4 May 2004 16:35:55 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> xmodmap _seems_ to work perfectly however, when logging in remotely
> using emacs -nw from a gnome terminal, which I am doing right now.

It works if the remapping was done on the machine where you run the
terminal emulator (assuming the emulator itself is a windowed
program).  I was talking about logging _into_ a machine where you
remapped the keys.

Re: Default Emacs keybindings

[Luc Teirlinck]

Eli Zaretskii wrote:

   > Date: Tue, 4 May 2004 16:35:55 -0500 (CDT)
   > From: Luc Teirlinck <teirllm@dms.auburn.edu>
   > 
   > xmodmap _seems_ to work perfectly however, when logging in remotely
   > using emacs -nw from a gnome terminal, which I am doing right now.

   It works if the remapping was done on the machine where you run the
   terminal emulator (assuming the emulator itself is a windowed
   program).  I was talking about logging _into_ a machine where you
   remapped the keys.

What I was talking about was: Use xmodmap on your local machine.
Then use ssh to log into a remote machine.  (It does not matter
whether you use or do not use X11 forwarding, ssh -X vs ssh -x for my
version of ssh).  Then you execute emacs -nw on the remote machine.
The xmodmap on the local machine will be in effect.

Sincerely,

Luc.

Re: Default Emacs keybindings

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   Eli Zaretskii wrote:

      I was talking about logging _into_ a machine where you
      remapped the keys.

   What I was talking about was: Use xmodmap on your local machine.

thus, you are talking past each other.  that's ok, too -- friends
share a parallel view of sorts, according to some Writer.

probably if the simple cases can be solved independently, those
more complex cases that combine these simple cases can also be
solved, if not by side-effect, then through complexity reduction.
trying to solve the composed problems is like painting a tree
starting w/ the leaves -- no doubt a skilled painter can make
the result beautiful, but that's a lot of extra work involved!

thi

Re: Default Emacs keybindings

[Luc Teirlinck]

>From my previous message:

    What I was talking about was: Use xmodmap on your local machine.
    Then use ssh to log into a remote machine.

Where the ssh is executed from an xterm.

Sincerely,

Luc.

Re: Default Emacs keybindings

[Richard Stallman]

    >From M-x man xmodmap:

That works under X, and it would be useful to put that info in Emacs;
however, we also should document how to remap the caps lock key on a
Linux console, for those who use GNU/Linux outside X.  if other
systems' consoles have this feature, we could also document how to
remap them.

Re: Default Emacs keybindings

[Robert J. Chassell]

   What we should do is include prominent documentation telling users how
   to remap their caps-lock key, with specific recipes.  (I have no idea
   where to find this information for GNU/Linux.)

I agree.  Here are my notes on installing sensible bindings in plain
text consoles, virtual consoles, using a shell and in X Windows.
These bindings apply to all applications, not just Emacs.

This is just a beginning.  Someone who knows more than I needs to
write the documentation to be more general and to work well.

First, plain text consoles:

The following is easiest for plain text consoles, but may not always
work:

    install-keymap emacs2

This command packages package all the keymaps needed for the complete
emacs2 keymap (i.e. linux-keys-bare.inc.gz,
linux-with-alt-and-altgr.inc.gz, qwerty-layout.inc.gz, and of course,
emacs2.kmap.gz) and puts them all together as:

    /etc/console/boottime.kmap.gz

and loads that file.

If `install-keymap' fails, the following succeeds, also for plain text
consoles:

    loadkeys /usr/share/keymaps/i386/qwerty/emacs2.kmap.gz


On my system, sensible key bindings are loaded at boottime
by   /etc/rcS.d/S05keymap.sh

That file is a link to  /etc/init.d/keymap.sh 
which contains a command to 

    loadkeys /etc/console/boottime.kmap.gz

(Actually, the command is `loadkeys ${CONFFILE}' where
`CONFFILE=${CONFDIR}/${CONFFILEROOT}.${EXT}.gz' and that ends up being
`/etc/console/boottime.kmap.gz'.)


Second, X Windows:

The `loadkeys' and `install-keymap' commands do not work with X
Windows.

Instead, it is necessary to use `xmodmap'.  (Other commands may also
work, but I do not know them.)

You can put the following commands in the global Xmodmap file which is
used by both xdm and xinit (startx) to change the X keymaps for all
users:

    /etc/X11/Xmodmap

Or you can put the commands in various users' ~/.xinitrc files.  When
the commands go into a user's ~/.xinitrc file, the commands are
executed when the user starts X and apply only to that user.

Please note that these keycodes are specific to my keyboard.  I
suspect that the commands suggested in the man page for `xmodmap' are
better than these, but have not tried them.

Alternatively, whoever writes the documentation should describe a
simple way to discover the keybinds.  I use `xev' and `xkeycaps', but
can never remember what is what.  Please describe a fool proof
technique, so people like me do not need to think or know anything.

    xmodmap -e "clear Lock"
    xmodmap -e "add Control = Caps_Lock"

    xmodmap -e "keycode 22 = BackSpace"
    xmodmap -e "keycode 107 = Delete"

The previous commands are different from the commands suggested in the
man page for xmodmap.  I suspect the man page commands are better, but
do not know enough myself to choose:

#             !
#             ! Swap Caps_Lock and Control_L
#             !
#             remove Lock = Caps_Lock
#             remove Control = Control_L
#             keysym Control_L = Caps_Lock
#             keysym Caps_Lock = Control_L
#             add Lock = Caps_Lock
#             add Control = Control_L

In addition, here are commands to set the right ALT and CTL keys to be
Super and Hyper respectively.  These are useful keys, both in Emacs
and in other X applications.  I think we should tell people how to do
this.

Please note the keycode.  Again, whoever writes the final
documentation should offer a better way.


    # Set right ALT key to be Super_R with mod3
    xmodmap  -e "keycode 0x71 = Super_R"
    xmodmap  -e "keysym Super_R = Super_R" \
             -e "add Mod3 = Super_R"     \
             -e "remove Mod1 = Super_R"
    xmodmap  -e "remove Mod2 = Super_R"


    # Set right CTL key to be a Hyper key with mod4
    xmodmap  -e "keycode 0x6d = Hyper_R"
    xmodmap  -e "keysym Hyper_R = Hyper_R" \
             -e "remove Control = Hyper_R"
    xmodmap  -e "remove Mod2 = Hyper_R" \
             -e "add Mod4 = Hyper_R"


Here are my comments on how to set the right ALT key to be a true ALT,
rather than a Meta key.

    # # Set right ALT key to be an ALT with mod3
    # xmodmap  -e "keycode 0x71 = Alt_R"
    # xmodmap  -e "keysym Alt_R = Alt_R" \
    #          -e "add Mod3 = Alt_R"     \
    #          -e "remove Mod1 = Alt_R"
    # xmodmap  -e "remove Mod2 = Alt_R"

In addition, I found that Shift-Tab works when I do the following:

    xmodmap -e 'keysym Tab = Tab'

Emacs should contain default key bindings and menu bindings to run a
shell command that changes the key bindings both for all the virtual
consoles and, if the user is in X Windows, for that session of X.

The command should appear on the Emacs splash page.  

Also, the documentation should explain what to put in both general and
user specific shell scripts that can be run from a shell.  Moreover,
it should tell how how to invoke one or other shell script
automatically at boot.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Default Emacs keybindings

[Richard Stallman]

You are good at writing clear documentation.  With the information
that was posted, can you write clear documentation for this?

You could explain how to construct the key mapping file
if there isn't already one.

Re: Default Emacs keybindings

[Robert J. Chassell]

   You are good at writing clear documentation.  With the information
   that was posted, can you write clear documentation for this?

No, there is not enough info for me.  I do not understand keybindings.
I do not know how to construct key mapping files that work for people
using various GNU systems.

For example, I do not know how to read the full key information
provided by xev or xkeycaps or showkeys, even though I have read the
man pages numerous times.

I grasp enough so that with trial and error, I was able, a long time
ago, to figure out what to do and write notes.

That is all.  I do not know what to read that is at the right level
for me and which will tell me what I need to learn.

On the one hand, I've seen documentation that presumes I know or
remember much more than I do.  I do not understand what it says.  On
the other hand, I'v seen documentation that presumes I know nothing.
This tells me too little.

Documentation that says too little tends to say things like, "run
`install-keymap emacs2'".  That is fine if that works.  But does not
tell what to do when it fails.

Fortunately, I know that when `install-keymap' fails, I should run
`loadkeys /usr/share/keymaps/i386/qwerty/emacs2.kmap.gz'

Unfortunately, but I do not know what to do when that command fails.

What do I do with that command to get a Euro symbol both in an xterm
and in an instance of Emacs -- a symbol that will be readable on a Web
page as well as in Emacs, or that will be readable in an email message
from me if they use some strange non-Emacs email reader?  

I have a note to myself for inserting a Euro symbol into an Emacs
buffer using "rfc1345" but I have no idea whether that is a good
method or not.  My note also says

    ;; Note that there exists
    ;;     ISO 2022 based 8-bit encoding for Latin-5 (MIME:ISO-8859-9).
    ;; but I do not know how to insert a Euro symbol with it.

Since the Euro symbol is not important to me, that is as far as I have
gone.  Obviously, the Euro symbol is important to many other people.


What should I read to learn about keybindings, including new features
like the Euro symbol?  I don't know.

Worse, as I said, I do not know how to construct key mapping files
that work for people using various GNU systems:  some time ago, I
tested the methods I use on the three different keyboards that I use,
and that is all.  (All three systems use a Linux kernel.)

The goal is to suggest one action or several actions that are likely
to work with all GNU systems.  (I have not the foggiest knowledge
about non-GNU systems, nor much interest.)

--
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Default Emacs keybindings

[Andreas Schwab]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I have a note to myself for inserting a Euro symbol into an Emacs
> buffer using "rfc1345" but I have no idea whether that is a good
> method or not.  My note also says
>
>     ;; Note that there exists
>     ;;     ISO 2022 based 8-bit encoding for Latin-5 (MIME:ISO-8859-9).
>     ;; but I do not know how to insert a Euro symbol with it.

Since Latin-5 doesn't contain a Euro sign this is impossible.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Default Emacs keybindings

[Robert J. Chassell]

   >     ;; Note that there exists
   >     ;;     ISO 2022 based 8-bit encoding for Latin-5 (MIME:ISO-8859-9).
   >     ;; but I do not know how to insert a Euro symbol with it.

   Since Latin-5 doesn't contain a Euro sign this is impossible.

I was told that ISO-8859-9 does contain a Euro sign.  Hmm...  there is
a mistake in the note; it should not refer to Latin-5.

Thanks!  I will fix the note.  

What about ISO-8859-9?

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Default Emacs keybindings

[Andreas Schwab]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    >     ;; Note that there exists
>    >     ;;     ISO 2022 based 8-bit encoding for Latin-5 (MIME:ISO-8859-9).
>    >     ;; but I do not know how to insert a Euro symbol with it.
>
>    Since Latin-5 doesn't contain a Euro sign this is impossible.
>
> I was told that ISO-8859-9 does contain a Euro sign.

The only latin character sets that contain a Euro sign are Latin-9
(ISO-8869-15) and Latin-10 (ISO-8859-16).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Default Emacs keybindings

[Richard Stallman]

    No, there is not enough info for me.  I do not understand keybindings.
    I do not know how to construct key mapping files that work for people
    using various GNU systems.

    For example, I do not know how to read the full key information
    provided by xev or xkeycaps or showkeys, even though I have read the
    man pages numerous times.

Can anyone else here explain that to you, so you can write good
documentation for it?

Re: Default Emacs keybindings

[Robert J. Chassell]

       No, there is not enough info for me.  I do not understand keybindings.
       I do not know how to construct key mapping files that work for people
       using various GNU systems.

       For example, I do not know how to read the full key information
       provided by xev or xkeycaps or showkeys, even though I have read the
       man pages numerous times.

   Can anyone else here explain that to you, so you can write good
   documentation for it?

If someone wants to try, that would be nice.  Otherwise, please
suggest documents for me to read.  Best would be documents in Texinfo,
then plain text, then HTML, then GhostScript.  Please, none in PDF.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Default Emacs keybindings

[Robert J. Chassell]

   What we should do is include prominent documentation telling users how
   to remap their caps-lock key, with specific recipes.  (I have no idea
   where to find this information for GNU/Linux.)

[I just sent a set of notes for a QWERTY keyboard.]

Perhaps people who use non-QWERTY keyboards can write notes on what to
do with them -- I don't know how specific my suggestions are to a
layout for a QWERTY layout or to the specific model of keyboard that I
mostly use.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Default Emacs keybindings

[Richard Stallman]

    Now I understand -- to use the emacs bindings you have to buy a
    special keyboard.  How convenient :-|

The happy hacking keyboard is worth the price.  It has keys that are
easy on the fingers.  But you don't need to get a special keyboard to
have a convenient control key.  Remapping does the job.

Re: Default Emacs keybindings

[Jan Nieuwenhuizen]

Lars Brinkhoff writes:

>> > You can get the Happy Hacking keyboard, which has control in the
>> > right place.
>> Hey, yeah, I second that -- I've got two HH keyboards!
> I third that -- I have three.

I see a pattern here.  It looks like a lot of people that like Emacs
bindings (like me) do not use keyboards with the control key at the
wrong place.  Using Emacs bindings on keyboards with pc-style control
key layout make my poor pinky fingers die.

FWIW, on common flat keyboards I use my own dvorak-caps layout, but
mostly I use a maltron keyboard, which has all modifiers convieniently
and symmetrically placed, control and alt/meta on both thumbs.

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

Re: Menu suggestion

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

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

It is not a question of which bindings are harder to learn -- it's a
question of whether it is necessary to learn any bindings at all.

When a new user is trying emacs for the first time, I bet that he
already knows about scrolling using arrow keys, home/end, pgup/pgdn,
and if he is just a little experienced in other applications, there is
also a good chance that he already knows about C-c to copy, C-x to
cut, C-z to undo and C-v to paste.

Since emacs already has the capability to support the bindings that
the user already knows, there is really no need to teach (and confuse)
a new user an alternative way to move the cursor (which is a fairly
large part of the tutorial).

So while your point is that to use emacs, the user must be taught a
non-standard set of cursor movement bindings, my point is that if we
allow a user to build on his current experience gained from other
applications, he can more quickly learn to use emacs as a whole.

Of course, if he later want to learn how to use emacs more efficiently
(and he is a good typist), he can start learning about C-f, C-b, for
cursor motion.


It is true that changing the translations of the tutorials is a big
task, but maybe it would pay off in the end.

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

Re: Menu suggestion

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> So while your point is that to use emacs, the user must be taught a
> non-standard set of cursor movement bindings, my point is that if we
> allow a user to build on his current experience gained from other
> applications, he can more quickly learn to use emacs as a whole.

It seems to me that this is really only true for the arrow keys, not
for the C-x/C-v, etc. -- which are enabled by default anyway.

Given that C-x/C-v _interfere_ with normal emacs usage -- and C-x in a
pretty serious way -- it seems unlikely that they're a good method to
`introduce someone to emacs' (naive users, in my observation, do not use
the keyboard for very much at all, they just use the mouse and menus a
lot).

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Menu suggestion

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > So while your point is that to use emacs, the user must be taught a
> > non-standard set of cursor movement bindings, my point is that if we
> > allow a user to build on his current experience gained from other
> > applications, he can more quickly learn to use emacs as a whole.
> 
> It seems to me that this is really only true for the arrow keys, not
> for the C-x/C-v, etc. -- which are enabled by default anyway.

Yes, the arrow keys (which the user already knows how to operate) are
supported, so why waste time on learning the user something in the
tutorial which he will - at best - just find obscure, and - at worst -
turn him off from learning emacs at all.

> 
> Given that C-x/C-v _interfere_ with normal emacs usage -- and C-x in a
> pretty serious way -- it seems unlikely that they're a good method to
> `introduce someone to emacs' (naive users, in my observation, do not use
> the keyboard for very much at all, they just use the mouse and menus a
> lot).

What serious way does C-x interfere with normal emacs use ?

Ah, yes, you will have problems exiting emacs or opening a file when
the region is active, but those are minor problems IMHO -- not severe.

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

Re: Menu suggestion

[Richard Stallman]

    Yes, the arrow keys (which the user already knows how to operate) are
    supported, so why waste time on learning the user something in the
    tutorial which he will - at best - just find obscure, and - at worst -
    turn him off from learning emacs at all.

The Emacs cursor motion keys are essential to efficient editing.
People who use the arrow keys will never get good at it.

Re: Menu suggestion

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Yes, the arrow keys (which the user already knows how to operate) are
>     supported, so why waste time on learning the user something in the
>     tutorial which he will - at best - just find obscure, and - at worst -
>     turn him off from learning emacs at all.
> 
> The Emacs cursor motion keys are essential to efficient editing.
> People who use the arrow keys will never get good at it.

You may be right, but I have managed using emacs quite efficiently
without using those bindings for 20 years...  And I use CUA mode too.

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

Re: Menu suggestion

[Jan Nieuwenhuizen]

Kim F. Storm writes:

> but I have managed using emacs quite efficiently without using those
> bindings for 20 years...  And I use CUA mode too.

No offence intended, but did you try the emacs cursor motion bindings?
I think it is well worth the effort to invest a bit of time to learn
them.  FWIW, it took me several tries, (ie, in my case several
summers, and viper mode) to eventually switch to Emacs.

Jan.

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

Re: Menu suggestion

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Kim F. Storm writes:
> 
> > but I have managed using emacs quite efficiently without using those
> > bindings for 20 years...  And I use CUA mode too.
> 
> No offence intended, but did you try the emacs cursor motion bindings?

Of course I did -- I really tried for a while, but never found it to
be efficient having to press two keys (ctrl + letter) just to move the
cursor, especially when those keys are FAR away from the control key.

Before switching to emacs, I used vi, and I think the HJKL navigation
in vi is vastly superior to emacs' native cursor movement.  I also
used another popular editor at the time (can't recall its name) which
used something like C-s C-d C-e and C-x to move the cursor; that was
also much easier to use, as it could be done with one hand only.

I also worked on a classic MAC for 6 months which had no cursor keys
-- the only way to move the cursor (even a single character) was with
the mouse -- now, that was INEFFICIENT (but very smart and modern).

Besides, using C-v/M-v to scroll up and down (forcing me to change
modifier keys) is just so much less efficient than using the
pgup/pgdown keys IMO.

BTW, I also play the piano, and it may be more efficient to just let
your hands stay within one octave all the time, but the music gets
rather dull after a while :-)


> I think it is well worth the effort to invest a bit of time to learn
> them.  FWIW, it took me several tries, (ie, in my case several
> summers, and viper mode) to eventually switch to Emacs.

It didn't take me that long to switch, a few days I guess -- the only
thing which was hard to get used to was the cursor motion commands; as
soon as I managed to reprogram emacs to recognize the relevant arrow
keys (that was in the good old serial terminal days), I was up to
speed, and have been a happy emacs user since.

In any case, this is the beauty of emacs -- you can configure it
to suit your personal preferences.

I like the arrow keys, I like CUA mode, but I would never claim that
my preferences are better than yours.

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

Re: Menu suggestion

[Per Abrahamsen]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> No offence intended, but did you try the emacs cursor motion bindings?

I used to use them exclusively, because the arrow keys were poorly
supported and inconsitently located on the terminals back then.

Today I mostly use the arrow keys.  I suspect moving the hand is
intutively less "work" than using a modifier key, but it is not a
conscious decision.  I guess I started with page up/down, which are
way easier to use than C-v/M-v, and even than space/del in view mode.

Re: Menu suggestion

[Stefan Monnier]

> Today I mostly use the arrow keys.

I started with arrow keys and nowadays I still mostly use arrow keys.  I do
use C-n, or C-p every once in a while (tho mostly when doing repetitive
operations which would be better performed with keyboard macros) and once
every blue moon C-f, or C-b which are really cumbersome (or rather
counterintuitive since the C-f on to the right of C-b).


        Stefan

Re: Menu suggestion

[Kim F. Storm]

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

> > Today I mostly use the arrow keys.
>
> I started with arrow keys and nowadays I still mostly use arrow keys.

I use them too -- and I even have alternate bindings on C-f and C-b
to commands which do the same as vi's f and b commands  *), and
CUA-mode remaps C-v and M-v.

But I do use C-n and C-p (quite often), but mostly to scroll through
minibuffer history...

It seems that a good part of the emacs developers don't actually use
the emacs bindings -- so how can we expect our users to learn them ?


*) Here is my find-char functions:

;;; find-char.el --- find character forward/backward

;; Copyright (C) 1998, 2004 Free Software Foundation, Inc.

;; Author: Kim F. Storm <storm@cua.dk>
;; Keywords: keyboard navigation
;; Revision: 1.2

;; This file is [not yet] part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Commentary:

;; This is the find-char package which allow fast movement to a specific
;; character in the text, similar to the 'f' and 'b' commands in vi.
;;
;; Since the forward and backward char commands are bound to the right
;; and left arrow keys, the C-f and C-b keys are readily available for
;; binding these commands:
;;
;;	(global-set-key "\C-b" 'find-char-backward)
;;	(global-set-key "\C-f" 'find-char-forward)
;;
;; If the C-f or C-b is repeated immediately after the previous C-f or C-b
;; command, the command moves point to the next/prev occurrence of the same
;; character.
;;
;; For example, to move point to the third next 'x' in the text, simply
;; enter C-f x C-f C-f  (or M-3 C-f x)

(provide 'find-char)

(defvar find-char-last-ok nil)
(defvar find-char-last-char ? )

;;;###autoload
(defun find-char-forward (count &optional backward)
 "Find COUNT'th forward occurrence of character read from minibuffer.
If command is repeated immediately, move to next occurrence of same
character."
 (interactive "p")
 (let ((case-fold-search nil)
       (char
	(if (and (> count 0)
		 (or (and find-char-last-ok (eq last-command this-command))
		     (eq last-command (if backward 'find-char-forward 'find-char-backward))))
	    find-char-last-char
	  (message "Find character %sward (%c): " (if backward "back" "for") find-char-last-char)
	  (read-char))))
   (if (/= char last-command-char)	; C-f C-f repeats last search.
       (setq find-char-last-char char))
   (setq count
	 (if (> 0 count) (- count)
	   (if (= 0 count) 1 count)))
   (if (setq find-char-last-ok
      (if backward
	  (progn
	    (backward-char)
	    (or (eq (char-after (point)) find-char-last-char)
		(search-backward (char-to-string find-char-last-char) nil t count)
		(forward-char)))
	(forward-char)
	(or (eq (char-after (point)) find-char-last-char)
	    (if (search-forward (char-to-string find-char-last-char) nil t count)
		(progn (backward-char) t))
	    (backward-char))))
       t
     (ding)
     (message "%c not found" find-char-last-char))
))

;;;###autoload
(defun find-char-backward (count)
 "Find COUNT'th backward occurrence of character read from minibuffer.
If command is repeated immediately, move to previous occurrence of same
character."
 (interactive "p")
 (find-char-forward count t))

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

Re: Menu suggestion

[Stefan Monnier]

> But I do use C-n and C-p (quite often), but mostly to scroll through
> minibuffer history...

Why not M-p, M-n ?


        Stefan

Re: Menu suggestion

[Kim F. Storm]

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

> > But I do use C-n and C-p (quite often), but mostly to scroll through
> > minibuffer history...
> 
> Why not M-p, M-n ?

You are right -- so basically, I never use C-n or C-p either...

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

Re: Menu suggestion

[Juanma Barranquero]

On 30 Apr 2004 19:30:46 +0200
storm@cua.dk (Kim F. Storm) wrote:

> It seems that a good part of the emacs developers don't actually use
> the emacs bindings --

I've been using Emacs daily for the past seven years, and I hardly use
C-f, C-b, etc.

Yeah, they're faster than arrow keys if you're used to them, but perhaps
I don't usually need the raw typing speed, and I find them extremely
non-intuitive... (now, if we were talking of vi/nethack cursor motion
commands... :)

                                                                Juanma

Re: Menu suggestion

[Kim F. Storm]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 30 Apr 2004 19:30:46 +0200
> storm@cua.dk (Kim F. Storm) wrote:
> 
> > It seems that a good part of the emacs developers don't actually use
> > the emacs bindings --
> 
> I've been using Emacs daily for the past seven years, and I hardly use
> C-f, C-b, etc.
> 
> Yeah, they're faster than arrow keys if you're used to them, but perhaps
> I don't usually need the raw typing speed, and I find them extremely
> non-intuitive... (now, if we were talking of vi/nethack cursor motion
> commands... :)

So the tutorial could start by asking the user a number of quiestions:

1) Do you have a Happy Hacker keyboard ?
2) Do you use C-z, C-x, C-c, C-v for undo, cut, copy, and paste ?

..

and then omit/include the relevant parts in the tutorial...

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

Re: Menu suggestion

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> Juanma Barranquero <jmbarranquero@wke.es> writes:
> 
> > On 30 Apr 2004 19:30:46 +0200
> > storm@cua.dk (Kim F. Storm) wrote:
> > 
> > > It seems that a good part of the emacs developers don't actually
> > > use the emacs bindings --
> > 
> > I've been using Emacs daily for the past seven years, and I hardly
> > use C-f, C-b, etc.
> > 
> > Yeah, they're faster than arrow keys if you're used to them, but
> > perhaps I don't usually need the raw typing speed, and I find them
> > extremely non-intuitive... (now, if we were talking of vi/nethack
> > cursor motion commands... :)
> 
> So the tutorial could start by asking the user a number of
> quiestions:
> 
> 1) Do you have a Happy Hacker keyboard ?
> 2) Do you use C-z, C-x, C-c, C-v for undo, cut, copy, and paste ?
>
> and then omit/include the relevant parts in the tutorial...

That's not fair because it tries to make the user's choice for him.
An experienced user exposed to other programs will _of_ _course_ be
using C-z C-x C-c C-v.  That does not mean that he is unable to learn
other bindings if he knows the drawbacks associated with CUA
bindings, and it would be unfair to be silent about them.

Actually, this question need not get asked but can be figured out
from the current settings.  You would then get something like

   This is the tutorial for CUA-mode.  CUA-mode offers keybindings for
   C-z, C-x, C-c and C-v as well as several others that are customary
   among applications different from Emacs.  Since those bindings
   clash with several important ones from Emacs, CUA-mode has to do
   some circumventions in order not to have them shadowed
   irretrievably.  This makes some operations somewhat tricky.
   CUA-mode is therefore not the default in Emacs and you might
   consider learning the native bindings by using the Options menu to
   switch off CUA-mode and selecting the tutorial again.

or

   This is the tutorial for Emacs' normal keybindings.  A different
   tutorial is available for CUA-mode.  CUA-mode offers keybindings
   for C-z, C-x, C-c and C-v as well as several others that are
   customary among applications different from Emacs.  Since those
   bindings clash with several important ones from Emacs, CUA-mode has
   to do some circumventions in order not to have them shadowed
   irretrievably.  This makes some operations somewhat tricky.
   CUA-mode is therefore not the default in Emacs.  If you still
   rather want the more widespread bindings of CUA-mode, use the
   Options menu to switch on CUA-mode and select the tutorial again.

Anyway, unless I am mistaken, CUA-mode consists of more than C-c C-x
C-v C-z bindings.  There are some parts of it unless I am mistaken
that don't interfere with standard keybindings and selections, or at
least not to a large degree.  Maybe it would be possible to adapt all
those parts of CUA-mode that don't clash with existing bindings too
badly.

For example, C-z would probably not be too horrible to give up to CUA
bindings, at least under Window systems.  And the same probably goes
for some key sequences for selections apart from the above ones.

If we can get most of CUA in, and just customize the more controversal
items to off, maybe a separate tutorial would not be needed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Menu suggestion

[Stefan Monnier]

>     Yes, the arrow keys (which the user already knows how to operate) are
>     supported, so why waste time on learning the user something in the
>     tutorial which he will - at best - just find obscure, and - at worst -
>     turn him off from learning emacs at all.

> The Emacs cursor motion keys are essential to efficient editing.

C-f, C-b, and friends (just like touch-typing) are like micro-optimizations
that allow you to go faster by a given constant.  Emacs makes things
efficient via higher-level commands which are like
algorithmic optimizations.  I don't touch type and only occasionally use
C-f and C-n.

> People who use the arrow keys will never get good at it.

Thanks for your encouragement.
You seem to assume that the tutorial has something to do with efficiently
using Emacs.  If so, I think it should spend more time explaining C-M-f and
C-M-u (random examples) then C-f and C-n.


        Stefan

Re: Menu suggestion

[Richard Stallman]

    You seem to assume that the tutorial has something to do with efficiently
    using Emacs.  If so, I think it should spend more time explaining C-M-f and
    C-M-u (random examples) then C-f and C-n.

The tutorial's job is to get people started on the path.  The tutorial
is already rather long, and if we added the many other commands that
are useful to various classes of users, it would be far too long.
The idea is that the tutorial gets people started, and they learn
the rest from the Emacs manual.

Re: Menu suggestion

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> The Emacs cursor motion keys are essential to efficient editing.
> People who use the arrow keys will never get good at it.

I am eager to achieve maximum efficiency in Emacs editing,
but I don't see how an asymmetrical layout of C-f C-b C-n C-p
C-a C-e C-v M-v is better for cursor motion than logically placed
arrow keys:

home  up  pgup
left      right
 end down pgdn

And typing arrow keys is faster because they require less key presses.

One possible argument for using letters as cursor motion keys is that
they have different modifiers (C-f M-f C-M-f), but arrow keys have
the same modifiers as well: right, M-right and C-M-right.

Oops, I noticed now that Emacs has no corresponding bindings yet for
C-M- modifiers of arrow keys!  They could be added to bindings.el:

(define-key global-map [(control meta left)]  'backward-sexp)
(define-key global-map [(control meta right)] 'forward-sexp)
(define-key global-map [(control meta up)]    'backward-list)
(define-key global-map [(control meta down)]  'forward-list)
(define-key global-map [(control meta home)]  'beginning-of-defun)
(define-key global-map [(control meta end)]   'end-of-defun)

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

Re: Menu suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 28 Apr 2004 08:09:32 +0300
> 
> And typing arrow keys is faster because they require less key presses.

Not if you consider the time needed to move your hand to the editing
keypad.

Re: Menu suggestion

[Juri Linkov]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Juri Linkov <juri@jurta.org>
>> Date: Wed, 28 Apr 2004 08:09:32 +0300
>> 
>> And typing arrow keys is faster because they require less key presses.
>
> Not if you consider the time needed to move your hand to the editing
> keypad.

It seems you assume those monstrous 101-key PC keyboards.
But that assumption doesn't hold for laptops where arrow keys
are located very close to letter keys, and even on them when
using a special key.

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

Re: Menu suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 28 Apr 2004 08:55:29 +0300
> 
> >
> > Not if you consider the time needed to move your hand to the editing
> > keypad.
> 
> It seems you assume those monstrous 101-key PC keyboards.
> But that assumption doesn't hold for laptops

I despise laptops: their keys are too small and too densely packed.

But even there, I find that I agree with Miles: the arrows are too far
aside.

Re: Menu suggestion

[Robert J. Chassell]

    > Not if you consider the time needed to move your hand to the editing
    > keypad.

    It seems you assume those monstrous 101-key PC keyboards.
    But that assumption doesn't hold for laptops where arrow keys
    are located very close to letter keys, and even on them when
    using a special key.

I am writing this on a laptop.  Even though the arrow keys are loced
close to the letter keys, I still have to move my hand noticeably
further than if I use Emacs keybindings.

To use an arrow key to move one character right, I have to move my
hand so that none of my fingers comfortably lie over any printable
characters.  To use `C-f', I move only my left little finger, and
leave the rest of my hand where it is.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Menu suggestion

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I am eager to achieve maximum efficiency in Emacs editing, but I don't
> see how an asymmetrical layout of C-f C-b C-n C-p C-a C-e C-v M-v is
> better for cursor motion than logically placed arrow keys:

I guess you probably don't touch-type then, right?

When touch-typing, it's far more important that the movement keys be
easy to reach without moving your hand excessively, than for them to be
a pattern that's nice to look it.  If you're _just_ moving the cursor
around, then you can keep your hand over the arrow keys, and you'll do
alright -- but if you're typing _and_ moving, the cursor keys suck,
because they're way off in the middle of nowhere (yes, even on a
laptop).  The emacs movement keys, OTOH, are quite convenient for use
when typing.

[This is slightly less true for `new style' keyboards with the control
key way down in the left bottom corner, but then anyone with any sense
remaps it to the proper position to the left of the A key anyway.]

-Miles
-- 
I'd rather be consing.

Re: Menu suggestion

[Robert J. Chassell]

   I am eager to achieve maximum efficiency in Emacs editing,
   but I don't see how an asymmetrical layout of C-f C-b C-n C-p
   C-a C-e C-v M-v is better for cursor motion than logically placed
   arrow keys...

You have to move your hand further to reach the arrow keys than the
control or meta keys.  This is the big factor.  

(And this, by the way, is why some people prefer the VI movement
bindings.  So long as you do not edit, you do not even have to move
your little finger to the left of your `A' key or your left thumb down
below your `X' key.

(However, I found that I edit and type at the same time, so using VI
bindings meant I had to change mode at almost every word, which was
less efficient than the Emacs bindings.  As far as I can see, the VI
keybindings are fine for people who separate editing and typing.  In
generations past, many secretaries were trained not to edit by
themselves so typing and editing were separate.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Menu suggestion

[Richard Stallman]

    I am eager to achieve maximum efficiency in Emacs editing,
    but I don't see how an asymmetrical layout of C-f C-b C-n C-p
    C-a C-e C-v M-v is better for cursor motion than logically placed
    arrow keys:

    home  up  pgup
    left      right
     end down pgdn

The arrow keys are perfectly logical, but efficiency is a different
question.  They are less efficient because they require you to move
your hand to another position.

On laptops the hand movement is smaller, but it is still significant.

For occasional users, the logical nature of the arrow keys makes them
better.  For peoplw who use Emacs for hours a day, it is worth
learning the old Emacs bindings.

Re: Menu suggestion

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> The arrow keys are perfectly logical, but efficiency is a different
> question.  They are less efficient because they require you to move
> your hand to another position.
>
> On laptops the hand movement is smaller, but it is still significant.
>
> For occasional users, the logical nature of the arrow keys makes them
> better.  For peoplw who use Emacs for hours a day, it is worth
> learning the old Emacs bindings.

Thanks.  Now I'm completely convinced in efficiency of old Emacs bindings.

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

Re: Menu suggestion

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 26 Apr 2004 11:56:24 +0200
> 
> When a new user is trying emacs for the first time, I bet that he
> already knows about scrolling using arrow keys, home/end, pgup/pgdn,

IIRC, once upon a time, I suggested to say in the tutorial, right at
its beginning, that if the reader already knows how to move around,
she could skip the first N sections.  (We could even make those parts
disappear, i.e. not be displayed, if the user doesn't want to read
them.)  I think Richard agreed, but requested that this be accompanied
by an advice to read those sections anyway, since they teach Emacs
bindings for cursor motion commands, which in our opinion are handier
for fast typists than the arrow keys and their ilk.

Given that some of the more boring sections of the tutorial are
skipped, we could add to it a few new sections describing features
that users generally want but cannot find and/or figure out easily.

Unfortunately, I never had time to rework the tutorial along these
lines.  Perhaps someone would consider doing that now.

Alternatively, some kind of ``guided tour'' thru Emacs for beginners
(which could use the tutorial as the starting point), would IMHO be a
very useful addition to Emacs.  Such a document could overcome the
greatest disadvantage of the tutorial: that it's a linear document
that is quite large, so it's inconvenient to read it in parts.

jargon translation up-front in doc (was: Menu suggestion)

[Drew Adams]

Apologies if the latest tutorial & Emacs manual already take care of this.

Proposal - Add a *brief* jargon translation near the beginning of the
tutorial and the Emacs manual, such as that at
http://www.emacswiki.org/cgi-bin/wiki/EmacsNewbie, "Fundamental Concepts" >
"Emacs-Speak (Jargon)".

The 5-line table there can help newbies digest the systematic presentations
of Emacs concepts that follow in the manual:

Common Term          Emacs Term
-----------          ----------
selection            region
cut                  kill
paste                yank
window               frame
shortcut             key sequence

The two columns don't present exact synonyms, but that can be detailed at
the appropriate places. This would at least give new users a head start in
understanding the doc (and doc strings).

 - Drew



-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Eli Zaretskii
Sent: Monday, April 26, 2004 3:36 AM
To: Kim F. Storm
Cc: emacs-devel@gnu.org
Subject: Re: Menu suggestion


> From: storm@cua.dk (Kim F. Storm)
> Date: 26 Apr 2004 11:56:24 +0200
>
> When a new user is trying emacs for the first time, I bet that he
> already knows about scrolling using arrow keys, home/end, pgup/pgdn,

IIRC, once upon a time, I suggested to say in the tutorial, right at
its beginning, that if the reader already knows how to move around,
she could skip the first N sections.  (We could even make those parts
disappear, i.e. not be displayed, if the user doesn't want to read
them.)  I think Richard agreed, but requested that this be accompanied
by an advice to read those sections anyway, since they teach Emacs
bindings for cursor motion commands, which in our opinion are handier
for fast typists than the arrow keys and their ilk.

Given that some of the more boring sections of the tutorial are
skipped, we could add to it a few new sections describing features
that users generally want but cannot find and/or figure out easily.

Unfortunately, I never had time to rework the tutorial along these
lines.  Perhaps someone would consider doing that now.

Alternatively, some kind of ``guided tour'' thru Emacs for beginners
(which could use the tutorial as the starting point), would IMHO be a
very useful addition to Emacs.  Such a document could overcome the
greatest disadvantage of the tutorial: that it's a linear document
that is quite large, so it's inconvenient to read it in parts.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jargon translation up-front in doc (was: Menu suggestion)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 26 Apr 2004 09:36:55 -0700
> 
> Proposal - Add a *brief* jargon translation near the beginning of the
> tutorial and the Emacs manual, such as that at
> http://www.emacswiki.org/cgi-bin/wiki/EmacsNewbie, "Fundamental Concepts" >
> "Emacs-Speak (Jargon)".

I think the tutorial should explain each term before it uses it for
the first time, rather than have a translation table.  If this is not
so, please point out the places that need to ve fixed.

For the manual, we already have all the terms, including the 5 you
mentioned, explained in the Glossary node.  Perhaps all we need to do
is add a reference to that node near the manual's beginning.  I'm not
sure how much it will help, since I don't think many people read the
manual from its beginning, but it surely cannot hurt, I think.

RE: jargon translation up-front in doc (was: Menu suggestion)

[Drew Adams]

Two suggestions in the same spirit that was behind naming the Edit menu
items "Cut", "Copy", and "Paste" (rather than something like "Kill", "Copy
As Kill", and "Yank").


Suggestion #1: a doc table translating five Emacs-speak terms (restated)

My point was not to *replace* anything in the tutorial or anything in the
manual. I too assume that all Emacs terms are defined there before they are
used.

My point was this:

1) In the world outside Emacs (yes, Virginia...) many people are already
familiar with similar (though not identical) concepts under very different
names.

2) So, it can help them to learn Emacs - and to understand its doc - if we
give them a simple, if inexact, translation table for these few terms (five
terms, unless you see others) - *up front*, before any systematic
explanation or tutorial of anything.

Common Term          Emacs Term
-----------          ----------
selection            region
cut                  kill
paste                yank
window               frame
shortcut             key sequence

If they are familiar with these common terms, then this table can help a
lot; if not, they can ignore it.

That's all.

The usefulness of such a simple table is *not* achieved by any up-front
reference to "go read the glossary". And it is not replaced by making sure
that each new term is defined in the doc before it is used.

And yes, there is no guarantee that a user will see such an up-front table.
But it cannot hurt to add it, and it can help.


Suggestion #2: Mention such common terms in doc strings, parenthetically,
for a touchstone.

Since some new users are likely to see `C-h k' help for commonly used keys
before they read the doc or run through the tutorial, it wouldn't hurt to
add the associated "common" term(s) somewhere in the doc strings of a
**few** important, common commands - in parentheses or as added explanation.
Example commands: `kill-region', `clipboard-kill-region', `yank',
`clipboard-yank', `kill-ring-save', `clipboard-kill-ring-save'.

This would also help with finding relevant commands using `command-apropos'.
And it would help them learn the associated Emacs terminology that they will
need in order to understand other concepts.

Again, ignore this suggestion if the Emacs 21 doc strings for these commands
already refer to "cut", "paste", and "copy" - I have only Emacs 20. The
menubar command names "Cut", "Paste", and "Copy" are helpful to newbies, but
the doc strings are not correspondingly clear (in Emacs 20, at least). It
wouldn't take much to add a simple explanation that provides a bridge to
familiar concepts (added text: <<>>):

`kill-region' - "Kill between point and mark.
<<Cuts the selected text to the clipboard for subsequent pasting.>>" (The
complete doc string in Emacs 20 is 14 lines long, without once using the
word "cut", the word "paste", or the word "selected".)

`clipboard-kill-ring-save' - "Copy region to kill ring, and save in the X
clipboard.
<<Copies the selected text to the clipboard for subsequent pasting.>>"

`yank' - "Reinsert the last stretch of killed text.
<<Pastes the clipboard text at the cursor (point). This is the text last
copied or cut.>>" (BTW, the doc string currently says nothing about *where*
the text is inserted.)

`kill-ring-save' is already an example of applying suggestion #2: Among six
lines of arcane stuff about transient mark mode and mark deactivation, we do
mention "cut" and "paste" - that's the kind of additional help I'm
suggesting Emacs should offer.

Yes, I realize that the Emacs functions do not map 1-1 to the common
operations, and it can be misleading to suggest otherwise. Nonetheless, as
long as the "real" explanation is present and precise, it can help if we add
some perhaps imprecise but very familiar terminology in a few key places.

I would further suggest that the *first* doc-string line be the
perhaps-imprecise explanation using familiar terms (that is, reverse the
order shown above). The rest of the doc-string can be as arcane as is needed
to explain the concepts precisely.

 - Drew



-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Eli Zaretskii
Sent: Monday, April 26, 2004 11:44 PM
To: Drew Adams
Cc: emacs-devel@gnu.org
Subject: Re: jargon translation up-front in doc (was: Menu suggestion)


> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 26 Apr 2004 09:36:55 -0700
>
> Proposal - Add a *brief* jargon translation near the beginning of the
> tutorial and the Emacs manual, such as that at
> http://www.emacswiki.org/cgi-bin/wiki/EmacsNewbie, "Fundamental Concepts"
>
> "Emacs-Speak (Jargon)".

I think the tutorial should explain each term before it uses it for
the first time, rather than have a translation table.  If this is not
so, please point out the places that need to ve fixed.

For the manual, we already have all the terms, including the 5 you
mentioned, explained in the Glossary node.  Perhaps all we need to do
is add a reference to that node near the manual's beginning.  I'm not
sure how much it will help, since I don't think many people read the
manual from its beginning, but it surely cannot hurt, I think.

Re: jargon translation up-front in doc (was: Menu suggestion)

[Kevin Rodgers]

Drew Adams wrote:
 > Suggestion #2: Mention such common terms in doc strings, parenthetically,
 > for a touchstone.
 >
 > Since some new users are likely to see `C-h k' help for commonly used keys
 > before they read the doc or run through the tutorial, it wouldn't hurt to
 > add the associated "common" term(s) somewhere in the doc strings of a
 > **few** important, common commands - in parentheses or as added explanation.
 > Example commands: `kill-region', `clipboard-kill-region', `yank',
 > `clipboard-yank', `kill-ring-save', `clipboard-kill-ring-save'.
 >
 > This would also help with finding relevant commands using `command-apropos'.
 > And it would help them learn the associated Emacs terminology that they will
 > need in order to understand other concepts.
 >
 > Again, ignore this suggestion if the Emacs 21 doc strings for these commands
 > already refer to "cut", "paste", and "copy" - I have only Emacs 20. The
 > menubar command names "Cut", "Paste", and "Copy" are helpful to newbies, but
 > the doc strings are not correspondingly clear (in Emacs 20, at least). It
 > wouldn't take much to add a simple explanation that provides a bridge to
 > familiar concepts (added text: <<>>):
 >
 > `kill-region' - "Kill between point and mark.
 > <<Cuts the selected text to the clipboard for subsequent pasting.>>" (The
 > complete doc string in Emacs 20 is 14 lines long, without once using the
 > word "cut", the word "paste", or the word "selected".)

How about automatically highlighting and hyperlinking glossary terms in
doc strings to the corresponding entry in the Glossary info node?

-- 
Kevin Rodgers

RE: jargon translation up-front in doc (was: Menu suggestion)

[Drew Adams]

That might be good (though excessive hyperlinking can be obfuscating, so
occurrences should *not* all become hyperlinks automatically). If we
provided such hyperlinking, programmers should have a way to explicitly,
selectively apply it (just as they can selectively expand command names in
doc strings to provide key bindings: \\[foobar]).

However, that does *not* address the main issue I raised. (Eli also missed
it, so I must not be making myself clear.)

Explaining our jargon is one thing. Come across "yank" somewhere, don't know
what it means, click it, get the definition - great.

What's missing is the set of common terms as user **entry points**. We
should *mention* those terms, and then provide a bridge to our similar
terms. Just defining our own terms doesn't provide this learning bridge.

A user should be able to do `M-x command-apropos paste' and come up with the
*few, common* commands that involve pasting. A user should be able to see
"paste" prominently in the user interface. Today, "Paste" is available in
the Edit menu - that's great. Let's also make it available in the first line
of (a few) appropriate doc strings. (I just tried `M-x command-apropos
paste' and came up with only dv-paste-to-temp: Load clipboard in buffer
`TEMP' - gnuserv.)

  - Drew


-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Kevin Rodgers
Sent: Thursday, April 29, 2004 8:44 AM
To: emacs-devel@gnu.org
Subject: Re: jargon translation up-front in doc (was: Menu suggestion)


Drew Adams wrote:
 > Suggestion #2: Mention such common terms in doc strings, parenthetically,
 > for a touchstone.
 >
 > Since some new users are likely to see `C-h k' help for commonly used
keys
 > before they read the doc or run through the tutorial, it wouldn't hurt to
 > add the associated "common" term(s) somewhere in the doc strings of a
 > **few** important, common commands - in parentheses or as added
explanation.
 > Example commands: `kill-region', `clipboard-kill-region', `yank',
 > `clipboard-yank', `kill-ring-save', `clipboard-kill-ring-save'.
 >
 > This would also help with finding relevant commands using
`command-apropos'.
 > And it would help them learn the associated Emacs terminology that they
will
 > need in order to understand other concepts.
 >
 > Again, ignore this suggestion if the Emacs 21 doc strings for these
commands
 > already refer to "cut", "paste", and "copy" - I have only Emacs 20. The
 > menubar command names "Cut", "Paste", and "Copy" are helpful to newbies,
but
 > the doc strings are not correspondingly clear (in Emacs 20, at least). It
 > wouldn't take much to add a simple explanation that provides a bridge to
 > familiar concepts (added text: <<>>):
 >
 > `kill-region' - "Kill between point and mark.
 > <<Cuts the selected text to the clipboard for subsequent pasting.>>" (The
 > complete doc string in Emacs 20 is 14 lines long, without once using the
 > word "cut", the word "paste", or the word "selected".)

How about automatically highlighting and hyperlinking glossary terms in
doc strings to the corresponding entry in the Glossary info node?

Re: jargon translation up-front in doc (was: Menu suggestion)

[Kim F. Storm]

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

> That might be good (though excessive hyperlinking can be obfuscating, so
> occurrences should *not* all become hyperlinks automatically). If we
> provided such hyperlinking, programmers should have a way to explicitly,
> selectively apply it (just as they can selectively expand command names in
> doc strings to provide key bindings: \\[foobar]).
> 
> However, that does *not* address the main issue I raised. (Eli also missed
> it, so I must not be making myself clear.)
> 
> Explaining our jargon is one thing. Come across "yank" somewhere, don't know
> what it means, click it, get the definition - great.
> 
> What's missing is the set of common terms as user **entry points**. We
> should *mention* those terms, and then provide a bridge to our similar
> terms. Just defining our own terms doesn't provide this learning bridge.

I think a very brief "emacs terms" section at the start of the tutorial would
be ok.

> 
> A user should be able to do `M-x command-apropos paste' and come up with the
> *few, common* commands that involve pasting.

Did you actually try C-h a paste RET ?

(clue: apropos already knows that paste is synonymous with yank)


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

RE: jargon translation up-front in doc (was: Menu suggestion)

[Drew Adams]

Yes, I said that I tried it:

> "I just tried `M-x command-apropos paste' and came up with only
dv-paste-to-temp:
> Load clipboard in buffer `TEMP' - gnuserv."


I also said (in two mails) that I have only Emacs 20, so my suggestion might
no longer be pertinent:

> "Again, ignore this suggestion if the Emacs 21 doc strings for these
commands
> already refer to "cut", "paste", and "copy" - I have only Emacs 20."


If Emacs 21 already satisfies this need, great.

 - Drew


-----Original Message-----
From: Kim F. Storm
Subject: Re: jargon translation up-front in doc (was: Menu suggestion)

> A user should be able to do `M-x command-apropos paste' and come up with
the
> *few, common* commands that involve pasting.

Did you actually try C-h a paste RET ?

(clue: apropos already knows that paste is synonymous with yank)

Re: jargon translation up-front in doc (was: Menu suggestion)

[Richard Stallman]

    Common Term          Emacs Term
    -----------          ----------
    selection            region
    cut                  kill
    paste                yank
    window               frame
    shortcut             key sequence

I would not mind installing such a table in the tutorial
at a suitable place.  (It can't be the first page!)

Re: Menu suggestion

[Richard Stallman]

    The problem with the current menu name, however, is that nobody has a
    clue what "CUA-style" is.

I think you are right.  I have no idea what "CUA" refers to, other
than this mode.  Whatever it may be, I suspect that most beginning
users won't have heard of it either.