German tutorial fix

German tutorial fix

[Mario Lang]

Hello.

I just looked at `C-h t' in a german language environment and noticed
that the text still states that M-< and Home are equivalent.
AFAIR this behaviour changed in Emacs 21 so that C-a and Home are the same.
This patch corrects this.

Index: etc/TUTORIAL.de
===================================================================
RCS file: /cvsroot/emacs/emacs/etc/TUTORIAL.de,v
retrieving revision 1.5
diff -u -r1.5 TUTORIAL.de
--- etc/TUTORIAL.de	2 Apr 2002 22:32:15 -0000	1.5
+++ etc/TUTORIAL.de	14 May 2002 12:57:00 -0000
@@ -186,11 +186,8 @@
 Textsuche in wissenschaftlichen Texten oft vorteilhaft ist.]
 
 [Anmerkung 2: Die Tasten `Home' (Pos1) und `End' (Ende) verhalten sich
-standardmäßig nicht wie C-a und C-e, wie wohl die meisten Benutzer
-annehmen würden, sondern springen zum Anfang bzw. zum Ende des
-Dokuments!  Lesen Sie in der Emacs-Dokumentation unter dem Stichwort
-`Rebinding Keys in Your Init File' nach, wie Sie die Tastaturbelegung
-ändern können.]
+standardmäßig wie C-a und C-e, wie wohl die meisten Benutzer
+annehmen würden.]
 
 Die aktuelle Position des Cursors wird im Englischen auch `point'
 (Punkt) genannt.  Beachten Sie bitte, daß sich `point' stets
@@ -228,10 +225,7 @@
 Aufwärtspfeil markiert).  Ohne SHIFT-Taste würden Sie M-Komma
 eingeben.
 
-[Standardmäßig sind die Tasten `Pos1' und `Ende' mit M-< bzw. M->
-belegt.]
-
->> Testen Sie nun M-< (bzw. `Pos1'), um an den Anfang der Einführung
+>> Testen Sie nun M-<, um an den Anfang der Einführung
    zu gelangen.  Verwenden Sie dann C-v, um wieder hierher zu kommen.
 
 Ein weiteres, oft benütztes Konzept in Emacs ist die Markierung
@@ -243,7 +237,7 @@
 und M-<) setzen eine Markierung implizit, was in der untersten Zeile
 (dem Echobereich, s.u.) als `Mark set' angezeigt wird.
 
->> Verwenden Sie jetzt M-> (bzw. `Ende'), um zum Ende der Einführung
+>> Verwenden Sie jetzt M->, um zum Ende der Einführung
    zu springen und benützen Sie C-u C-SPC, um hierher zurückzukehren.
 
 Markierungen werden in einem Ring gespeichert (d.h., die zuletzt in

-- 
CYa,
  Mario

Re: German tutorial fix

[Kai Großjohann]

Mario Lang <mlang@delysid.org> writes:

> I just looked at `C-h t' in a german language environment and noticed
> that the text still states that M-< and Home are equivalent.
> AFAIR this behaviour changed in Emacs 21 so that C-a and Home are the same.
> This patch corrects this.

It might be a good idea if the English version of the tutorial also
mentioned <home> and <end>.

kai
-- 
Silence is foo!

Re: German tutorial fix

[Richard Stallman]

    It might be a good idea if the English version of the tutorial also
    mentioned <home> and <end>.

I can't read German and I don't really know what they said.
Can you propose changes for the English etc/TUTORIAL?

Re: German tutorial fix

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     It might be a good idea if the English version of the tutorial also
>     mentioned <home> and <end>.
>
> I can't read German and I don't really know what they said.
> Can you propose changes for the English etc/TUTORIAL?

The German text says that <home> and <end> are bound to beginning/end
of buffer.  Of course, that's wrong.

I only meant: WIBNI the tutorial explained <home> and <end>?  Maybe
it could list the `cursor block' equivalents wherever applicable.  So
<left> could be mentioned as an alternative to C-b, M-<left> and
C-<left> as an alternative to M-b, and so on.

Hm.  Maybe these are all obvious these days and need not be
mentioned?  I vaguely recall this has been discussed before but I
don't remember the outcome.

kai
-- 
Silence is foo!

Re: German tutorial fix

[Eli Zaretskii]

> From: Kai.Grossjohann@CS.Uni-Dortmund.DE
> Date: Thu, 16 May 2002 12:37:46 +0200
> 
> I only meant: WIBNI the tutorial explained <home> and <end>?  Maybe
> it could list the `cursor block' equivalents wherever applicable.  So
> <left> could be mentioned as an alternative to C-b, M-<left> and
> C-<left> as an alternative to M-b, and so on.
> 
> Hm.  Maybe these are all obvious these days and need not be
> mentioned?  I vaguely recall this has been discussed before but I
> don't remember the outcome.

IMHO, the tutorial needs to be reworked, now that basic cursor motion
is no longer a mystery for novices.  So the "BASIC CURSOR CONTROL"
section should be a lot shorter than it is now.  It should just tell
that cursor motion keys ``work as usual'', and show the keyboard
equivalents of the editing keys (C-n for <down>, C-f for <right>,
etc.), telling the new users they are advised to learn them because
those keys allow for faster typing.

This should significantly reduce the 150 lines we devote to something
everybody knows nowadays.  We could then add to the tutorial stuff
that is important, but isn't there, without risking to bloat the file
too much.  Some ideas for things to add:

  - Options menu and Customize
  - Frames
  - Region and the mark
  - Command history in the minibuffer
  - M-x compile and M-x grep

Re: German tutorial fix

[Andreas Fuchs]

Today, Eli Zaretskii <eliz@is.elta.co.il> wrote:
> IMHO, the tutorial needs to be reworked, now that basic cursor motion
> is no longer a mystery for novices.  So the "BASIC CURSOR CONTROL"
> section should be a lot shorter than it is now.  It should just tell
> that cursor motion keys ``work as usual'', and show the keyboard
> equivalents of the editing keys (C-n for <down>, C-f for <right>,
> etc.), telling the new users they are advised to learn them because
> those keys allow for faster typing.

Actually, I think it is a good idea to have newbies use the C-n, C-p
etc. bindings. They reduce hand movements, keep the fingers on the
relevant keys and increase typing speed. Getting used to them is a
little hard, but is essential when it comes to move-by-word,
m-b-paragraph and m-b-sexp navigation, IMHO.

> [...] We could then add to the tutorial stuff that is important, but
> isn't there, without risking to bloat the file too much.  Some ideas
> for things to add:
> 
>   - Options menu and Customize
>   - Frames
>   - Region and the mark
>   - Command history in the minibuffer
>   - M-x compile and M-x grep

I think this is a good idea; Had I signed emacs papers, I would
volunteer to write the necessary sections (at least in german, don't
know how much you like my english (-:).

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: German tutorial fix

[Eli Zaretskii]

> From: Andreas Fuchs <asf@void.at>
> Date: Thu, 16 May 2002 16:10:23 +0200
> 
> Today, Eli Zaretskii <eliz@is.elta.co.il> wrote:
> > IMHO, the tutorial needs to be reworked, now that basic cursor motion
> > is no longer a mystery for novices.  So the "BASIC CURSOR CONTROL"
> > section should be a lot shorter than it is now.  It should just tell
> > that cursor motion keys ``work as usual'', and show the keyboard
> > equivalents of the editing keys (C-n for <down>, C-f for <right>,
> > etc.), telling the new users they are advised to learn them because
> > those keys allow for faster typing.
> 
> Actually, I think it is a good idea to have newbies use the C-n, C-p
> etc. bindings. They reduce hand movements, keep the fingers on the
> relevant keys and increase typing speed. Getting used to them is a
> little hard, but is essential

Sure.  And that's exactly what I tried to say in slightly different
words.

What I think we don't need is to explain, demonstrate, and drill the
user in basic cursor motion.  Just tell them the keyboard
equivalents, explain why they are important, and be done with them.

Re: German tutorial fix

[Richard Stallman]

    IMHO, the tutorial needs to be reworked, now that basic cursor motion
    is no longer a mystery for novices.  So the "BASIC CURSOR CONTROL"
    section should be a lot shorter than it is now.  It should just tell
    that cursor motion keys ``work as usual'', and show the keyboard
    equivalents of the editing keys (C-n for <down>, C-f for <right>,
    etc.), telling the new users they are advised to learn them because
    those keys allow for faster typing.

I have doubts about this change.

    What I think we don't need is to explain, demonstrate, and drill the
    user in basic cursor motion.

Drilling them is what teaches them to use C-f rather than an arrow key.
So maybe it is still worth while to drill them.

    too much.  Some ideas for things to add:

      - Options menu and Customize
      - Frames
      - Region and the mark
      - Command history in the minibuffer
      - M-x compile and M-x grep

The region seems like the most important one to add.
The others don't seem basic enough.

Re: German tutorial fix

[Francesco Potorti`]

       What I think we don't need is to explain, demonstrate, and drill the
       user in basic cursor motion.
   
   Drilling them is what teaches them to use C-f rather than an arrow key.
   So maybe it is still worth while to drill them.

I think that using C-f instead of the arrow key is very advanced usage.
It is only useful for very fast typists or people that routinely use all
sort of keyboards and setups, so they cannot rely on arrows.  In my
opinion, C-f and friends should not even be mentioned in the tutorial.
I agree that motion commands should be just mentioned in one or two
lines of explanation.
   
         - Options menu and Customize
         - Frames
         - Region and the mark
         - Command history in the minibuffer
         - M-x compile and M-x grep

Certainly the region is the most important.  Next comes the
customization.  That one is very important for new users.

Maybe frames could be mentioned, but I think that command history and
compile should not.

Re: German tutorial fix

[Miles Bader]

Francesco Potorti` <pot@gnu.org> writes:
> I think that using C-f instead of the arrow key is very advanced usage.
> It is only useful for very fast typists or people that routinely use all
> sort of keyboards and setups, so they cannot rely on arrows.

That's silly.  C-f &c are much better for _anyone_ who can touch-type,
because the (usually very long) reach for the arrow keys causes a lot of
disruption.

This has _nothing_ to do with being a `very fast typist' or not, it's
simply a much more efficient of working anytime you want to keep your
hands on the keyboard, e.g., when you're actually typing something.

I think the arrow keys are worse than the mouse for this reason, because
people generally use the mouse for `gross editing', where they
conciously _do_ switch modes, and are prepared for the disruption,
whereas cursor-movement keys are very commonly used while actually
typing, for correcting minor mistakes.

So, even if it's not as completely necessary now days to teach the
cursor-movement keys to complete novices (because they'll `get by' using
the arrow keys), banishing them to an appendix or something as `advanced
usage' would be a real disservice to users.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: German tutorial fix

[Andreas Fuchs]

Today, Miles Bader <miles@gnu.org> wrote:
> Francesco Potorti` <pot@gnu.org> writes:
>> I think that using C-f instead of the arrow key is very advanced
>> usage.  It is only useful for very fast typists or people that
>> routinely use all sort of keyboards and setups, so they cannot rely
>> on arrows.
> That's silly.  C-f &c are much better for _anyone_ who can touch-type,
> because the (usually very long) reach for the arrow keys causes a lot
> of disruption.

I agree. Yet, I see Eli's point that cursor keys should at least be
mentioned as working as expected in emacs, maybe by giving the reason
why there are other keys which do the same (easier and faster to type,
consistency with M-p, etc.).


-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: German tutorial fix

[Francesco Potorti`]

   > I think that using C-f instead of the arrow key is very advanced usage.
   > It is only useful for very fast typists or people that routinely use all
   > sort of keyboards and setups, so they cannot rely on arrows.
   
   That's silly.  C-f &c are much better for _anyone_ who can touch-type,
   because the (usually very long) reach for the arrow keys causes a lot of
   disruption.

I teached computer usage more than once to complete beginners and once
to intermediate users.  People understand quickly how to use the cursor
keys.  The mouse is very intuitive, but it needs precision of movement,
so some beginners prefer not to use it.  Any other key combination is
simply out of question.

Those were courses about Windows systems, so I tried to insist on using
at least the copy, cut, paste and undo commands (which on Windows
systems are conveniently bound to C-c, C-x, C-v and C-z, same as on the
Macintosh, where C stands for Command rather than Control).  Those four
commands are easy to remember and very useful.  Yet, users typically
prefer alternative ways for invoking them, using standard or contextual
menus, because they have difficulty memorizing the key bindings.

Even people at the intermediate course did not use key combinations very
much.  Key combinations, in the world outside of Emacs, are typically
seen as hard to remember, hacker-style things.

All the students that I happen to help with Emacs never ever think about
using anything other than the keys to move around.  Why should they
bother, when it is obvious what the arrow keys do?  All they usually
memorize is maybe ten different keybindings, they use the mouse and the
menus for the rest, like they do for almost any other program in the
world.  If this is the memory effort they are willing to concede to
Emacs, it makes no sense to memorize key bindings for a basic feature
that they know how to perform with the arrows or the mouse.

I know and use daily around one hundred different key bindings for
Emacs, I never use the menus and very rarely the mouse.  Obviously,
among all people I know personally (many of them programmers), I am the
Emacs wizard.  Yet, I never use the Ctrl keys for moving the cursor,
unless I am in a situation where the arrow keys do not work well
(terminal emulators and similar things).

I am really convinced that spending words in the tutorial about how one
can move the cursor is a bad idea.  The C-f, C-b, C-n, C-p key bindings
should not even be mentioned.  The normal way of scrolling up and down
should be using the PagUp and PagDn keys.  However, since too often
keyboards are only halfway set up, the C-v and M-v commands should be
mentioned.  

By the way, I seldom use C-v and M-v, I prefer the PagUp and PagDn keys.
Same as for the arrows, the reason is simple.  While I spend most of my
time in Emacs, I use a lot of other programs.  All of them deal with
arrows and scrolling keys in the same way.  I do not want to pollute my
inconscious finger intelligence with other key combination, I want my
fingers to move by themselves, just bringing the cursor where I want,
and doing the same for every program I use.

Re: German tutorial fix

[Miles Bader]

Francesco Potorti` <pot@gnu.org> writes:
> All the students that I happen to help with Emacs never ever think about
> using anything other than the keys to move around.  Why should they
> bother, when it is obvious what the arrow keys do?

Because the control keys are _better_.  You can read my previous
message if you wish to know why.

> All they usually memorize is maybe ten different keybindings, they use
> the mouse and the menus for the rest, like they do for almost any
> other program in the world.

If your students are so fearful, lazy, or busy that they'll only learn
ten different keybindings, then I'd say they're better off just using
the menus, and probably don't even need the tutorial.

> I am the Emacs wizard.  Yet, I never use the Ctrl keys for moving the
> cursor, unless I am in a situation where the arrow keys do not work well.

That's your choice.  Everybody has their preferences, and no one is
going to force you to use keys you don't like.  But by the same token,
you shouldn't try to force your opinion on others -- there _are_
advantages to using the control keys instead of the arrow keys, and we
should give people the chance to see that.  The tutorial is the place
to do that.

Perhaps the existance of arrow keys and the like means that C-f and
friends should be given _less_ precedence in the tutorial, but they
shouldn't be removed.

> I am really convinced that spending words in the tutorial about how one
> can move the cursor is a bad idea.  The C-f, C-b, C-n, C-p key bindings
> should not even be mentioned.

... and I am convinced that you are wrong.

Cheers,

-Miles
-- 
Would you like fries with that?

Re: German tutorial fix

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 18 May 2002 21:12:50 +0900
> 
> > All they usually memorize is maybe ten different keybindings, they use
> > the mouse and the menus for the rest, like they do for almost any
> > other program in the world.
> 
> If your students are so fearful, lazy, or busy that they'll only learn
> ten different keybindings, then I'd say they're better off just using
> the menus, and probably don't even need the tutorial.

The tutorial is the gate to Emacs.  We advertise it and urge the users
to read it before evrything else.  If we want them to become better
users, we should make the tutorial more useful and more appealing to
their ``way cool!'' feelings.

If you agree with the above principles, then you will agree that (a)
even the lazy users should be tutorial's target audience, and (b) we
shouldn't put those users to sleep right away by wasting 150 lines on
basic cursor motion.

Please note that I'm not as extreme as Francesco: I don't think we
should remove the cursor motion discussion altogether, or never
mention C-f and C-b.  I just think we don't need to talk about that
as much as it was necessary in 1990, say.

Re: German tutorial fix

[Andreas Fuchs]

Today, Eli Zaretskii <eliz@is.elta.co.il> wrote:
> The tutorial is the gate to Emacs.  We advertise it and urge the users
> to read it before evrything else.  If we want them to become better
> users, we should make the tutorial more useful and more appealing to
> their ``way cool!'' feelings.

Hm, I might have pondered this before (not here), but what about
splitting the tutorial up in two parts? One for users new to emacs (but
who can edit files already, maybe used vi before), and one for users who
are new to editing with emacs (who have used pico or notepad before).

I guess that would look something like:

basic tutorial:
  * motion commands
  * ...


advanced tutorial:
  * dired
  * customize
  * ...

This is just a rough draft, and I have not yet worked through the
tutorial, looking for things which belong in each part, but I guess
that this should enable more advanced users to plunge into emacs
without having their brains shrivel away, as well as newbies who are
not so sure of their editing powers.

> If you agree with the above principles, then you will agree that (a)
> even the lazy users should be tutorial's target audience, and (b) we
> shouldn't put those users to sleep right away by wasting 150 lines on
> basic cursor motion.

to (b) I agree, but I guess that my suggestion would allow less
advanced users get their feet wet emacs more quickly, the way the
current tutorial does now.

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: German tutorial fix

[Eli Zaretskii]

On Sat, 18 May 2002, Andreas Fuchs wrote:

> Hm, I might have pondered this before (not here), but what about
> splitting the tutorial up in two parts? One for users new to emacs (but
> who can edit files already, maybe used vi before), and one for users who
> are new to editing with emacs (who have used pico or notepad before).

Personally, I don't like splitting documents.  Two documents are harder 
to find than one.

Instead of splitting, we could simply tell near the beginning something 
like ``If you are familiar with the basics of a text editor, we suggest 
to skip to section 7''.

Re: German tutorial fix

[Richard Stallman]

    Hm, I might have pondered this before (not here), but what about
    splitting the tutorial up in two parts? One for users new to emacs (but
    who can edit files already, maybe used vi before), and one for users who
    are new to editing with emacs (who have used pico or notepad before).

It might be useful to have two different tutorials, for users coming
from these two different places, but I don't think this corresponds to
"splitting" the current tutorial.

    advanced tutorial:
      * dired
      * customize
      * ...

We have documentation for these features already, in the Emacs manual.
I don't see any point in redoing all that work.

Re: German tutorial fix

[Kim F. Storm]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: Miles Bader <miles@gnu.org>
> > Date: 18 May 2002 21:12:50 +0900
> > 
> > > All they usually memorize is maybe ten different keybindings, they use
> > > the mouse and the menus for the rest, like they do for almost any
> > > other program in the world.
> > 
> > If your students are so fearful, lazy, or busy that they'll only learn
> > ten different keybindings, then I'd say they're better off just using
> > the menus, and probably don't even need the tutorial.
> 

I don't think it is being lazy or fearful simply wanting to use existing
knowledge -- and getting down to business quickly.  99% of all users which
start using emacs already knows how to navigate using the arrow keys and
pgup/pgdown, so IMO spending one word in the tutorial -- repeat TUTORIAL --
doesn't help the users one iota getting started using emacs.  

Quite contrary it makes emacs stand out as old fashioned, and
difficult to learn!!!

Once a user masters the basic emacs functionality, those interested in
optimizing their typing will learn about the C-f etc bindings -- the
rest will *NEVER* care about them.

It might also be an idea to mention CUA mode in the tutorial -- if
the user is already familiar with C-z C-x C-c and C-v, teaching them
to use a different set of bindings could be delayed...

> 
> Please note that I'm not as extreme as Francesco: I don't think we
> should remove the cursor motion discussion altogether, or never
> mention C-f and C-b.  I just think we don't need to talk about that
> as much as it was necessary in 1990, say.

It could be written in 8 lines:

To move the cursor in emacs, use the arrow, <home>, and <end> keys.
To scroll the window, use the PgDown and PgUp keys, and to move
to the top or bottom of the current buffer, use C-home and C-end.

If you don't like the cursor keys, use the following keys instead:
C-f, C-b, C-n, and C-p moves the cursor, C-a and C-e moves to
beginning or end of the line, C-v and M-v scrolls the window, while
M-< and M-> moves to the top or bottom of the buffer.

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

Re: German tutorial fix

[Francesco Potorti`]

   > using anything other than the keys to move around.  Why should they
   > bother, when it is obvious what the arrow keys do?
   Because the control keys are _better_.  You can read my previous
   message if you wish to know why.

Hey!  I also explained why they are worse!  And I spent more words than
you did, so I win :-)
   
   > I am the Emacs wizard.  Yet, I never use the Ctrl keys for moving the
   > cursor, unless I am in a situation where the arrow keys do not work well.
   That's your choice.  Everybody has their preferences, and no one is
   going to force you to use keys you don't like.  

Thanks god!  That's good to know :-)

Re: German tutorial fix

[Richard Stallman]

Using control characters is more efficient than using the arrow keys,
so I don't think we should stop teaching people to use them.  However,
people are right that users will probably understand what the arrow
keys do, which means we can use them to explain the control
characters.

We also should tell users why we recommend the control characters.

Here's the change I am thinking of making.  Any suggestions?


*** TUTORIAL.~1.49.~	Tue Apr 23 12:14:20 2002
--- TUTORIAL	Sat May 18 21:36:22 2002
***************
*** 50,55 ****
--- 50,59 ----
     Find the cursor again and notice that the same text
     is near the cursor now.
  
+ You can also use the PageUp and PageDn keys to do scrolling, if your
+ terminal has them, but you can edit more efficiently if you use C-v
+ and M-v.
+ 
  
  * BASIC CURSOR CONTROL
  ----------------------
***************
*** 57,67 ****
  Moving from screenful to screenful is useful, but how do you
  move to a specific place within the text on the screen?
  
! There are several ways you can do this.  The most basic way is to use
! the commands C-p, C-b, C-f, and C-n.  Each of these commands moves the
! cursor one row or column in a particular direction on the screen.
! Here is a table showing these four commands and the directions they
! move:
   
  			  Previous line, C-p
  				  :
--- 61,70 ----
  Moving from screenful to screenful is useful, but how do you
  move to a specific place within the text on the screen?
  
! There are several ways you can do this.  You can use the arrow keys,
! but it's more efficient to keep your hands in the standard position
! and use the commands C-p, C-b, C-f, and C-n.  These characters
! are equivalent to the four arrow keys, like this:
   
  			  Previous line, C-p
  				  :
***************
*** 75,84 ****
     using C-n or C-p.  Then type C-l to see the whole diagram
     centered in the screen.
  
! You'll probably find it easy to think of these by letter: P for
! previous, N for next, B for backward and F for forward.  These are the
! basic cursor positioning commands, and you'll be using them ALL the
! time, so it would be of great benefit if you learn them now.
  
  >> Do a few C-n's to bring the cursor down to this line.
  
--- 78,86 ----
     using C-n or C-p.  Then type C-l to see the whole diagram
     centered in the screen.
  
! You'll find it easy to remember these letters by words they stand for:
! P for previous, N for next, B for backward and F for forward.  You
! will be using these basic cursor positioning commands all the time.
  
  >> Do a few C-n's to bring the cursor down to this line.

Re: German tutorial fix

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> + but you can edit more efficiently if

> ! but it's more efficient to keep your hands in the standard position

I don't like this at all.  It seems to be an unsubstantiated claim.
People like Jef Raskin ("The Humane Interface") will argue for
"dedicated keys" such as the arrow keys.  People from the RSI crowd
will argue for hands moving out of the standard position in order to
prevent injuries.  Some will claim this is wrong.  The point is,
nobody knows for sure.

It is much better to use other arguments.  For example:

+ You can also use the PageUp and PageDn keys to do scrolling, if your
+ terminal has them, but you can use C-v and M-v when you are using
  Emacs over a dumb terminal.

...

! There are several ways you can do this.  You can use the arrow keys,
! but sometimes your terminal does not allow this.   In these situations,
  use the commands C-p, C-b, C-f, and C-n.  These characters
! are equivalent to the four arrow keys, like this:

...

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: German tutorial fix

[Miles Bader]

Alex Schroeder <alex@emacswiki.org> writes:
> > + but you can edit more efficiently if
> > ! but it's more efficient to keep your hands in the standard position
> 
> I don't like this at all.  It seems to be an unsubstantiated claim.

It's easily observable by any touch-typist, by (1) taking some time to
get used to the control-keys, and (2) trying both for about 3 seconds
while typing in some text.  It's not a subtle thing.

The arrow keys are better for some things too -- I usually use them when
`browsing,' e.g., reading mail or something, because then I don't keep
my hands on the home row, and in fact usually keep one near the arrow
keys.  But for actually _typing_ text, it's not even a contest.

> People like Jef Raskin ("The Humane Interface") will argue for
> "dedicated keys" such as the arrow keys.

If Jef Raskin has a good reason why the arrow keys should be used to the
exclusions of other cursor movement keys -- in a text editor, even when
they are less efficient -- then by all means, give his arguments.

It's almost certainly the case that the arrow keys are more _obvious_
than the control keys, but the argument that has been made is that the
control-keys are _more efficient for some purposes_.

That's why it's (1) a good thing that emacs can use the arrow keys, and
(2) also a good thing that emacs can use the control keys.

Users presumably can be counted upon to know about the arrow keys
already, but not about the control-keys.

Since the control-keys are _more efficient_ in some very common
situations, and users probably won't learn about them elsewhere (unlike
many commands, which can be learnt by seeing the key-bindings listed in
the menus), we should introduce them in the tutorial -- even if they're
not as crucial as they once were.

The purpose of the tutorial, I would claim, is not to give beginner's
the absolute minimal amount of knowledge required to use emacs (with
today's more menu- and mousified emacs, that's probably very little
knowledge indeed), but to put them on the road to being a proficient
user of emacs -- and part of that is coming to grips with the gestalt of
emacs keybindings.  If a user knows about `C-n' meaning `next-line' it
not only allows them to move to the next line, but provides a point of
reference which makes it easier to remember that for instance that a
plain `n' moves to the next line or next message in many modes.

> People from the RSI crowd will argue for hands moving out of the
> standard position in order to prevent injuries.  Some will claim this
> is wrong.  The point is, nobody knows for sure.

Knows for sure about what?  Which is better for RSI?  Is that even an
issue?

-Miles
-- 
Run away!  Run away!

Re: German tutorial fix

[Stefan Monnier]

> keys.  But for actually _typing_ text, it's not even a contest.
[...]
> Knows for sure about what?  Which is better for RSI?  Is that even an
> issue?

Around here, fast typing seems to be much less of an issue than RSI.


	Stefan "unable to touch-type and rather happy about it"

Re: German tutorial fix

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> It's easily observable by any touch-typist, by (1) taking some time to
> get used to the control-keys, and (2) trying both for about 3 seconds
> while typing in some text.  It's not a subtle thing.

I do not find it easily observable.  I bet it also depends on keyboard
layout and customizations outside of Emacs.  Furthermore, I think the
tutorial should not care about it, even if it were true.

>> People like Jef Raskin ("The Humane Interface") will argue for
>> "dedicated keys" such as the arrow keys.
>
> If Jef Raskin has a good reason why the arrow keys should be used to the
> exclusions of other cursor movement keys -- in a text editor, even when
> they are less efficient -- then by all means, give his arguments.

I also do not thing that the burden of proof is on me.  I do not
believe your claim, so I think the burden of proof is on you (or
Richard, since he said something similar).  Skimming the TOC and
checking some chapters selectively, I think here is what he might say:

1. Habit formation -- sometimes you use the arrow keys, sometimes C-f
   to move point.  That is bad for habit formation.

2. GOMS keystroke level model -- arrow keys might involve hand
   movement similar to moving from the keyboard to the mouse, thus you
   have one H element in the analysis, and a K for the press, and
   mentally preparing M.  C-f has mentally preparing, and two
   keypresses.  The timing he gives for the simplified analysis would
   be M = 1.35s, K = 0.2s, H = 0.2s, thus the two are exactly
   equivalent as far as the GOMS model is concerned.

3. Hick's Law -- since you now have two equivalent methods of moving
   point, this not only hampers habit formation, it also imposes a
   cognitive burden when you have to choose between the two.

Anyway, enough of that.  These points are not even necessarily true.
My claim is just that 1. C-f is not obviously better, and
2. conflicting opinions exist.  So why use it as an argument, if we
have far better arguments at hand?  For example stupid terminals.

> If a user knows about `C-n' meaning `next-line' it not only allows
> them to move to the next line, but provides a point of reference
> which makes it easier to remember that for instance that a plain `n'
> moves to the next line or next message in many modes.

This is a valid argument.  Notice that in my suggestion for a new
text, I did describe the control keys because of the dumb terminals.
This is also a good point to explain the mnemonics, I agree.

> Knows for sure about what?  Which is better for RSI?  Is that even an
> issue?

I have it, RMS had it, iirc, Ben Wing had it, JWZ had it, James
Gosling had it, ... health might be just as important as typing speed.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: German tutorial fix

[Miles Bader]

Alex Schroeder <alex@emacswiki.org> writes:
> I bet it also depends on keyboard layout and customizations outside of
> Emacs.

Well of course, but emacs' entire command set is predicated on certain
constraints, like the control key being easy to type.

> Skimming the TOC and checking some chapters selectively, I think here
> is what he might say:

[I know I shouldn't reply to this, because it's really beside the point,
but well...]

> 1. Habit formation -- sometimes you use the arrow keys, sometimes C-f
>    to move point.  That is bad for habit formation.

That is no doubt true.  However, the claim made was not that the
control-keys are _easier_ to learn (they clearly are not, if the user
already knows about arrow keys), but that they are more efficient to use.

There's also an argument that the habits we want people to form are in
fact the control-key methods of doing stuff.

> 2. GOMS keystroke level model -- arrow keys might involve hand
>    movement similar to moving from the keyboard to the mouse, thus you
>    have one H element in the analysis, and a K for the press, and
>    mentally preparing M.  C-f has mentally preparing, and two
>    keypresses.  The timing he gives for the simplified analysis would
>    be M = 1.35s, K = 0.2s, H = 0.2s, thus the two are exactly
>    equivalent as far as the GOMS model is concerned.

Hmmm, that would be a good clue that the GOMS model (whatever that is)
has a flaw.  Moving your hands from the home row to the arrow keys (and
back again) is _very_ costly on most PC keyboards -- not only is the
actual movement expensive, but (1) quite often you have to adjust your
body position to accomodate the arm movement [they're _that_ far away],
and (2) you screw up the positioning of your hands on the home row
(which doesn't happen at all with the control-key cursor movement keys;
they're in fact almost exactly like typing).

Thus, if I understand what you wrote above, he's seriously underestimating
H.  I would also suggest that he's _overestimating_ M in many cases -- the
sort of simple editing commands that often happen while typing in text are
not the sort of thing you actually think about, they're almost automatic.

I don't doubt that he's based the above numbers on actual measurements,
although such things are almost certainly highly dependendent on who's
being measured.

> 3. Hick's Law -- since you now have two equivalent methods of moving
>    point, this not only hampers habit formation, it also imposes a
>    cognitive burden when you have to choose between the two.

See point 1.

In any case, everything is a tradeoff -- while having many arbitrary and
capricious methods of performing every command is certainly confusing, in
some cases the benefits outweigh the problems.  In the current case, we're
talking about probably the _most used_ commands in emacs (well, actually I
suppose that would be `self-insert-command' :-), which is exactly the case
where one wants to think about efficiency, even if it takes a slight bit
of extra work by the user to remember.

[after all, if we really took this `Law' seriously, we'd have to get rid
of the keybindings, and M-x, and just use the menus for everything...]

> My claim is just that 1. C-f is not obviously better, and 2. conflicting
> opinions exist.  So why use it as an argument, if we have far better
> arguments at hand?  For example stupid terminals.

The danger is that people will read such this and say `I have arrow keys,
so I don't need to bother with all these strange and odd key-bindings --
they're only for sad users stuck on 1970's hardware.'

If we believe (as I obviously do) that the non-arrow-key bindings are
_better_ in some situations, and also offer other less tangible benefits
(such as their integration into the emacs `scheme' for keybindings), then
we really ought to also point out `Hey, these bindings may seem
unnecessary, but really, you ought to try them for a while, you may be
glad you did.'

Even if they later decide that they really rather prefer the arrow keys,
just having some experience with the traditional cursor-movement keys will
probably aid them in understanding other emacs' keybindings, and may make
learning emacs easier in general.

> I have it, RMS had it, iirc, Ben Wing had it, JWZ had it, James
> Gosling had it, ... health might be just as important as typing speed.

Sure, but I suspect that most of the emacs command set is toast if you
really care to avoid RSI (and are arrow keys really any better, other than
by slowing you down?  They require hand movement and keypressing, just
like any other key...).

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: German tutorial fix

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> The danger is that people will read such this and say `I have arrow keys,
> so I don't need to bother with all these strange and odd key-bindings --
> they're only for sad users stuck on 1970's hardware.'

Yes, I think they only *need* this on old terminals.  Perhaps they
might *want* it for various reasons, but I think we should concentrate
on what users need.

> If we believe (as I obviously do) that the non-arrow-key bindings
> are _better_ in some situations, and also offer other less tangible
> benefits (such as their integration into the emacs `scheme' for
> keybindings), then we really ought to also point out `Hey, these
> bindings may seem unnecessary, but really, you ought to try them for
> a while, you may be glad you did.'

I'm not sure this kind of thing belongs into the tutorial.

I think the tutorial ought to be short, and easy to understand.  So
let us not encumber it with too much information.  After all, there is
still the manual.  And even if we do mention the control keys, let us
only give the most obvious arguments for them: mnemonics, and old
terminals.  I think that typing speed is on par with health
considerations: Nobody knows for sure.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: German tutorial fix

[Robert J. Chassell]

   Miles Bader <miles@gnu.org> writes:

   > It's easily observable by any touch-typist, by (1) taking some time to
   > get used to the control-keys, and (2) trying both for about 3 seconds
   > while typing in some text.  It's not a subtle thing.

   I do not find it easily observable.  I bet it also depends on keyboard
   layout and customizations outside of Emacs.  

Do please tell me your keyboard and customizations.  

I just tried Miles' experiment on a QWERTY keyboard, with the arrow
keys to the lower right.  By counting how many I could press in 5 and
10 seconds, I found that I can press C-n or C-p in 200 milliseconds or
so and press an arrow key in 800 milliseconds or so.  (Presumably,
with more practice, I could speed up my arrow key press time, but
still, that action has to take longer than pressing a control key
since it requires moving my right hand two rows down and 3.5 rows to
the right but pressing a control-chord does not require moving my
hands, just my fingers.)

As far as I can see, the arrow keys are as Miles says, *more obvious*.
But in my experience, on the computer keyboards I have been using for
the past generation, they are less efficient than control keys.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: German tutorial fix

[Alex Schroeder]

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

>    I do not find it easily observable.  I bet it also depends on keyboard
>    layout and customizations outside of Emacs.  
>
> Do please tell me your keyboard and customizations.  

I use a German Ergo Elan from Kinesis.

> I just tried Miles' experiment on a QWERTY keyboard...

Well, I just read a book on interface by a self-proclaimed specialist.
I think his ideas are good.  You can read it yourself.  He discusses
pros and cons, limitations and all.  I have no intention to repeat it
all here.  I am also tired of the discussion because I do not want to
*prove* my point, I just want to raise some *doubt* concerning Miles'
and Richards' point.  It seems that I am not succeeding, and really, I
do not care too much anymore.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: German tutorial fix

[Richard Stallman]

    The purpose of the tutorial, I would claim, is not to give beginner's
    the absolute minimal amount of knowledge required to use emacs (with
    today's more menu- and mousified emacs, that's probably very little
    knowledge indeed), but to put them on the road to being a proficient
    user of emacs -- and part of that is coming to grips with the gestalt of
    emacs keybindings.

That is correct.

Re: German tutorial fix

[Alex Schroeder]

I think it makes no sense to argue about the keys used to move point
in any other context than simplicity for newbies.  Thus, I agree with
Francesco.  If we consider such arguemts like "C-f &c are much better
for _anyone_ who can touch-type", our discussion will degrade, because
nobody really *knows*.  This is even worse than Dvorak keyboard.
There, at least we have conflicting *research* -- in this case all we
have is conflicting opinions.

Therefore, let us base our decision on what to include in the tutorial
on what newbies need in order to start using Emacs -- wether fast or
slow, touch-typing or eagle-eyeing.

Alex.



Miles Bader <miles@gnu.org> writes:

> That's silly.  C-f &c are much better for _anyone_ who can touch-type,
> because the (usually very long) reach for the arrow keys causes a lot of
> disruption.
>
> This has _nothing_ to do with being a `very fast typist' or not, it's
> simply a much more efficient of working anytime you want to keep your
> hands on the keyboard, e.g., when you're actually typing something.
>
> I think the arrow keys are worse than the mouse for this reason, because
> people generally use the mouse for `gross editing', where they
> conciously _do_ switch modes, and are prepared for the disruption,
> whereas cursor-movement keys are very commonly used while actually
> typing, for correcting minor mistakes.
>
> So, even if it's not as completely necessary now days to teach the
> cursor-movement keys to complete novices (because they'll `get by' using
> the arrow keys), banishing them to an appendix or something as `advanced
> usage' would be a real disservice to users.

-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: German tutorial fix

[Eli Zaretskii]

> From: Francesco Potorti` <pot@gnu.org>
> Date: 18 May 2002 02:44:46 +0200
> 
> Maybe frames could be mentioned, but I think that command history and
> compile should not.

I added command history to that list because I'm astonished how many
users don't know about it.  Can you imagine using Emacs without
command history (and without completion, for that matter)?  Yet this
is exactly what I see many users do.

Perhaps Emacs should have some visual cue in the minibuffer appearance
that would hint about the history.  But until it does, I think every
novice should be told about it.

Re: German tutorial fix

[Robert J. Chassell]

          What I think we don't need is to explain, demonstrate, and drill the
          user in basic cursor motion.

      Drilling them is what teaches them to use C-f rather than an arrow key.
      So maybe it is still worth while to drill them.

   I think that using C-f instead of the arrow key is very advanced usage.

On the contrary, using C-f is basic and enables a slow and
inexperienced typist to learn to type faster.  

When a novice learns to take his or her hand off the keyboard, he or
she forgoes the chance to advance, since it is impossible to learn to
work well when using arrow keys or the mouse.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: German tutorial fix

[Mario Lang]

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

>           What I think we don't need is to explain, demonstrate, and drill the
>           user in basic cursor motion.
>
>       Drilling them is what teaches them to use C-f rather than an arrow key.
>       So maybe it is still worth while to drill them.
>
>    I think that using C-f instead of the arrow key is very advanced usage.
>
> On the contrary, using C-f is basic and enables a slow and
> inexperienced typist to learn to type faster.  
>
> When a novice learns to take his or her hand off the keyboard, he or
> she forgoes the chance to advance, since it is impossible to learn to
> work well when using arrow keys or the mouse.
Uhm, thats nice. So it's impossible for me to work well. Nice, good that
I now know this.

Please stop this thread, it's extremely pointless. I, for my part, use
cursor keys.  I use a laptop sized keyboard, so I really don't need
to move my hands that far.  And everytime I try to use C-f C-b C-n C-p
it feels like it's much more strain for my left hand. On the other hand,
M-f and M-b and alike are really useful, as they move more than one
char. But having to hit two keys to achieve one movement
feels just wrong to me.  So I think we can conclude that
there are different viewpoints, and that there is no single best
solution.


-- 
CYa,
  Mario

Re: German tutorial fix

[Colin Walters]

On Mon, 2002-05-20 at 10:40, Mario Lang wrote:

> Uhm, thats nice. So it's impossible for me to work well. Nice, good that
> I now know this.
> 
> Please stop this thread, it's extremely pointless. I, for my part, use
> cursor keys.  I use a laptop sized keyboard, so I really don't need
> to move my hands that far.  And everytime I try to use C-f C-b C-n C-p
> it feels like it's much more strain for my left hand. On the other hand,
> M-f and M-b and alike are really useful, as they move more than one
> char. But having to hit two keys to achieve one movement
> feels just wrong to me.  So I think we can conclude that
> there are different viewpoints, and that there is no single best
> solution.

Well said.  I personally use VIPER, but when I'm in a mode which is in
Emacs state, I much prefer using the arrow keys over C-f and friends.

Re: German tutorial fix

[Richard Stallman]

    I only meant: WIBNI the tutorial explained <home> and <end>?  Maybe
    it could list the `cursor block' equivalents wherever applicable.  So
    <left> could be mentioned as an alternative to C-b, M-<left> and
    C-<left> as an alternative to M-b, and so on.

Is it really worth making the tutorial longer to explain that?
I don't see that it is very beneficial to add that material.

Re: German tutorial fix

[Werner LEMBERG]

> I just looked at `C-h t' in a german language environment and
> noticed that the text still states that M-< and Home are equivalent.
> AFAIR this behaviour changed in Emacs 21 so that C-a and Home are
> the same.  This patch corrects this.

Thanks for the report.  I'll fix this soon.  Note that M-< and C-Home
are now the same if used under X.

Am I right that `C-Home' isn't available on non-X terminals?


    Werner

Re: German tutorial fix

[Eli Zaretskii]

On Wed, 15 May 2002, Werner LEMBERG wrote:

> Am I right that `C-Home' isn't available on non-X terminals?

No.  IMHO, it's not a good practice to assume something about which keys 
are supported when writing user documentation: terminals change all the 
time.

So I suggest to say something like ``if your terminal supports it''.