across terminals

across terminals

[PPAATT]

> Date: 4/20/02 11:28:15 AM MDT
> From: rms@gnu.org (Richard Stallman)
...
> Since such characters are not available
> on all terminals, ...
> People won't want to use these keys
> in major modes or minor modes
> meant for general use.

I remain mystified by this concise statement,
but I've thought up a new way to interpret it ...

A quick glance thru:

        http://www.google.com/search?q=iso+646+vs+ascii

in particular:

        http://www.cs.tut.fi/~jkorpela/chars.html#646
        http://pdc.ro.nu/teletext.html

suggests that keyboards designed by ISO 646 folk
might have keys labelled with the "invariant set" of
printable US Ascii minus the thirteen chars
# $ @ [ \ ] ^ _ ` { | } ~
(i.e.  x  23 24  40  5B 5C 5D 5E 5F 60  7B 7C 7D 7E). 

So across Europe & relations maybe we face
"not available on all terminals" issues
in the default Emacs keymap with the "C-c letter"
concept we have been elucidating in our thread
titled "bindings reserved for users" but then also with:

set-mark-command is on C-@, C-SPC
key ESC is on C-[
abort-recursive-edit is on C-]
toggle-input-method is on C-\
undo C-_, C-/

ispell-word M-$
mark-word is on M-@
delete-horizontal-space is on M-\
delete-indentation is on M-^
tmm-menubar is on M-`
backward-paragraph is on C-up, M-{
shell-command-on-region is on M-|
forward-paragraph is on C-down, M-}
not-modified is on M-~

Fun to see how many of these we have
(and have not) already bound to alternate
key sequences, not to mention mouse actions etc.

I remember in particular that C-h t help-with-tutorial
bemoans the difficulty of finding locally how to undo,
hence we have C-x u advertised-undo (also known as
the undo that C-h w undo does Not advertise).

Pat LaVarre

Re: across terminals

[Richard Stallman]

I have never seen a terminal that did not have these characters:
  # $ @ [ \ ] ^ _ ` { | } ~

If they do exist, they must be rare, so I don't think
they should be a major factor in our decisions.

If a large number of such terminals do exist, please
let me know.

Re: across terminals

[Eli Zaretskii]

On Thu, 25 Apr 2002, Richard Stallman wrote:

> I have never seen a terminal that did not have these characters:
>   # $ @ [ \ ] ^ _ ` { | } ~
> 
> If they do exist, they must be rare

Unfortunately, this isn't true: many national keyboards in Europe don't 
have keys for some of those ( {, |, and } seem to be most prone to 
this).  You need to press some AltGr-key combination to get them.  IIRC,
\ and _ have some issues on Japanese keyboards.

I remember that someone told me SIGQUIT was a pain in some European 
country (Germany?) because you need a combination of keys to produce \.

Re: across terminals

[Stephen J. Turnbull]

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

    Eli> IIRC, \ and _ have some issues on Japanese keyboards.

Yes, although the list is \ (the code point maps to YEN SYMBOL), ~
(OVERBAR), and | (BROKEN BAR = U+00A6).

There's another problem that I've occasionally encountered, is that my
muscle memory knows where "the key that invokes eval-expression" is in
a way that isn't entirely linked to "where : is".  Non-US keyboards
tend to move punctuation around a lot.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Localization: keyboards and messages (Re: across terminals)

[Karl Eichwalder]

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

> I remember that someone told me SIGQUIT was a pain in some European 
> country (Germany?) because you need a combination of keys to produce \.

Yes.  Doing localization (L10N) properly would mean a lot of key
re-assignments (that's why I use US keyboards only).

Before re-mapping keys lets solve the message translation problem first.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Localization: keyboards and messages (Re: across terminals)

[Pavel Janík]

   From: Karl Eichwalder <ke@gnu.franken.de>
   Date: Thu, 25 Apr 2002 17:04:04 +0200

   > Yes.  Doing localization (L10N) properly would mean a lot of key
   > re-assignments (that's why I use US keyboards only).
   > 
   > Before re-mapping keys lets solve the message translation problem first.

Yes, I agree with Karl. Message/text translation is in my opinion the most
wanted feature. We do not have to do the translations, we should only
provide infrastructure. I do not know what is the situation in other
countries, but here in CZ we have many people who are ready to start
translating pieces of texts from Emacs to Czech. They are only waiting to
have the possibility to start...

What other developers think about this? I think we should coordinate the
work on this with people from XEmacs team.
-- 
Pavel Janík

Choose a data representation that makes the program simple.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

Re: across terminals

[Paul Eggert]

> From: Eli Zaretskii <eliz@is.elta.co.il>
> Date: Thu, 25 Apr 2002 14:20:46 +0300 (IDT)
> 
> > I have never seen a terminal that did not have these characters:
> >   # $ @ [ \ ] ^ _ ` { | } ~
> > If they do exist, they must be rare
> 
> Unfortunately, this isn't true: many national keyboards in Europe don't 
> have keys for some of those ( {, |, and } seem to be most prone to 
> this).  You need to press some AltGr-key combination to get them.

Yes.  For example, according to
<http://www.246.ne.jp/~joe/info/latin1.htm>, the only printable
characters common to all the Western European IBM 106 keyboards are
the ASCII letters, digits, and the following:

  ! " % & ' ( ) * + , - . / : ; _

The following printable ASCII characters are absent from at least one
keyboard in that list:

  # $ <= > ? @ [ \ ] ^ ` { | } ~

> IIRC, \ and _ have some issues on Japanese keyboards.

We do have a few Japanese keyboards here, and characters like \ are
not a real problem with them.  Japanese users are well aware that the
Yen-sign character is actually an alias for \, so they know that if
the documentation says "Please type C-\" that they should actually
type Control-(yen-sign).  Some Japanese keyboards have both a yen-sign
and a backslash on the key, to indicate the alias.

> I remember that someone told me SIGQUIT was a pain in some European 
> country (Germany?) because you need a combination of keys to produce \.

Yes, and it works the other way sometimes too.  For example, it's a
pain to type a NUL on Unix US English Sun type 5 keyboard
(Control-Shift-2), but it's easier on a Japanese Information Standard
English IBM 106 keyboard (Control-@).

Re: across terminals

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> There's another problem that I've occasionally encountered, is that my
> muscle memory knows where "the key that invokes eval-expression" is in
> a way that isn't entirely linked to "where : is".

For eval-expression at least, the answer is obvious:  rebind it to
M-ESC, where god intended that it be.  :-|

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: across terminals

[Richard Stallman]

    > I have never seen a terminal that did not have these characters:
    >   # $ @ [ \ ] ^ _ ` { | } ~

    Unfortunately, this isn't true: many national keyboards in Europe don't 
    have keys for some of those ( {, |, and } seem to be most prone to 
    this).  You need to press some AltGr-key combination to get them.

I thought the issue was whether the terminal has these characters.
Whether they use AltGr is another question (not particularly relevant
here, I think).

I stand by what I said.  Let's consider this issue closed
and NOT SPEND MORE TIME on it, OK?

Re: Localization: keyboards and messages (Re: across terminals)

[Stephen J. Turnbull]

>>>>> "Pavel" == Pavel Jan <Pavel@Janik.cz> writes:

    Pavel> What other developers think about this? I think we should
    Pavel> coordinate the work on this with people from XEmacs team.

Please do talk to XEmacs people about this.  There _is_ some ancient
code aiming toward gettextizing XEmacs, but it's so bitrotted puffs of
dust blow out of the PC every time I compile XEmacs.  (And Ben said
something about clearing it out of the devel branch to make room for
another try, it's so bad.)

I know that Ben would "like to do it right someday", and so would I, FWIW.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: across terminals

[PPAATT]

> From: rms@gnu.org (Richard Stallman)
> Let's consider this issue closed
> and NOT SPEND MORE TIME on it, OK?

This we could do by fiat, sure boss.

> I stand by what I said.

I'm new here I know, but certainly I am
as yet failing to make sense of what you said.

Do you mean to withdraw or otherwise modify
what you did not repeat?  That is ...

> Date: 4/20/02 11:28:15 AM MDT
> From: rms@gnu.org (Richard Stallman)
...
> Since such characters are not available on all terminals, ...
> People won't want to use these keys in major modes
> or minor modes meant for general use.

Looks to me like Emacs folk actually do
commonly bind rare keys for general use?

Agreed?  No?  Yes?  Not exactly?

Are we just now telling me now this was inadvertent?

When we say "available on all terminals"
we mean the only terminals that count
are those designed for the people of Massachusetts?

> # $ @ [ \ ] ^ _ ` { | } ~
...
> I thought the issue was
> whether the terminal has these characters.
...
> Whether they use AltGr ... not ... relevant ...

This English I still think I don't understand,
sorry.  The non-US keyboards I see don't have
these labels on keys.

Saying that these terminals have these
chars is as silly as saying a US IBM PC
keyboard has all of the chars coded 0 to 255
because "everyone knows" you can hold down
the Alt key and type out the code in decimal
on the numeric keypad.

By that theory, the US IBM PC keyboard has
the letter ñ on it, perhaps at Alt 1 6 4,
so C-c ñ should count among the C-c letter keys.

But this you began by explicitly denying.

> > The non-US keyboards I see
> > don't have these labels on keys.

Is my (sharply limited) sample not representative?

> Since such characters are not available on all terminals, ...
> People won't want to use these keys in major modes
> or minor modes meant for general use.

What can this mean ... presuming you maintain it is true?

(((This would matter less, except that RMS said it, so maybe
here lies a key to understanding why Emacs can say
things like "overwrite-mode is on insert" and "C-c C-h is
undefined" while meaning something rather different than the
newbie might think.)))

Pat LaVarre



Subj:    Re: across terminals
Date:   4/25/02 9:18:55 PM Mountain Daylight Time
From:   rms@gnu.org (Richard Stallman)
Reply-to:   rms@gnu.org
To: eliz@is.elta.co.il
CC: PPAATT@aol.com, emacs-devel@gnu.org, Kai.Grossjohann@CS.Uni-Dortmund.DE

> > I have never seen a terminal that did not have
> > these characters:
> >   # $ @ [ \ ] ^ _ ` { | } ~

> Unfortunately, this isn't true: many national
> keyboards in Europe don't have keys for some
> of those ( {, |, and } seem to be most prone
> to this).  You need to press some AltGr-key
> combination to get them.

I thought the issue was whether the terminal
has these characters.  Whether they use AltGr
is another question (not particularly
relevant here, I think).

I stand by what I said.  Let's consider this
issue closed and NOT SPEND MORE TIME on it, OK?

Re: across terminals

[Stefan Monnier]

> > From: rms@gnu.org (Richard Stallman)
> > Let's consider this issue closed
> > and NOT SPEND MORE TIME on it, OK?
> 
> This we could do by fiat, sure boss.
> 
> > I stand by what I said.
> 
> I'm new here I know, but certainly I am
> as yet failing to make sense of what you said.
> 
> Do you mean to withdraw or otherwise modify
> what you did not repeat?  That is ...
> 
> > Date: 4/20/02 11:28:15 AM MDT
> > From: rms@gnu.org (Richard Stallman)
> ...
> > Since such characters are not available on all terminals, ...
> > People won't want to use these keys in major modes
> > or minor modes meant for general use.
> 
> Looks to me like Emacs folk actually do
> commonly bind rare keys for general use?

The experience until now is that non-ASCII letters are never used
by major modes or minor modes, so we don't need to decide whether they
should be reserved for the user or not.

And note that we are talking about letters, not about characters.
`e' with an acute accent is a letter, `]' is not.

I think the only problem with the manual's description is that
the casual reader might confuse the notion of letter and character.


	Stefan

Re: across terminals

[Kai Großjohann]

PPAATT@aol.com writes:

>> From: rms@gnu.org (Richard Stallman)
>> Let's consider this issue closed
>> and NOT SPEND MORE TIME on it, OK?
>
> This we could do by fiat, sure boss.

If I were you, I'd just bind C-c <X> where <X> is a non-ascii
character.  Then you read the NEWS files for each new Emacs, in the
unlikely event that future versions will bind such keys.

kai
-- 
Silence is foo!

Re: across terminals

[PPAATT]

> Subj:  Re: across terminals
> Date: 4/26/02 8:26:19 AM Mountain Daylight Time
> From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)
...
> If I were you, I'd just bind C-c <X> where <X> is a non-ascii
> character.  Then [ perhaps via C-h n view-emacs-news]
> you read the NEWS files for each new Emacs, in the
> unlikely event that future versions will bind such keys.

Eh?

If the GNU Emacs developers do mean to support binding shifted uses of keys 
that conventionally self-insert chars outside of US-Ascii ... then I should 
consider all of those key sequences reserved for the user?  Not just C-c x 
but also C-x, where by x we mean the unshifted but not-US-Ascii key?

Or I should consider all of these keys reserved for Emacs?

Or else by "what occurs commonly works well; what occurs less commonly works 
less well", when I see the doc not discuss this issue I should clue in and 
work harder to imitate an American at the keyboard?

Pat LaVarre

Re: across terminals

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> Date: Fri, 26 Apr 2002 10:18:55 -0400
> 
> I think the only problem with the manual's description is that
> the casual reader might confuse the notion of letter and character.

Indeed.  So perhaps we should add a sentence or a footnote there to
prevent this confusion.

Re: across terminals

[Eli Zaretskii]

> From: PPAATT@aol.com
> Date: Fri, 26 Apr 2002 11:44:16 EDT
> 
> If the GNU Emacs developers do mean to support binding shifted uses of keys 
> that conventionally self-insert chars outside of US-Ascii ... then I should 
> consider all of those key sequences reserved for the user?  Not just C-c x 
> but also C-x, where by x we mean the unshifted but not-US-Ascii key?
> 
> Or I should consider all of these keys reserved for Emacs?
> 
> Or else by "what occurs commonly works well; what occurs less commonly works 
> less well", when I see the doc not discuss this issue I should clue in and 
> work harder to imitate an American at the keyboard?

None of the above.  Just find the keys that aren't bound in any of the
modes you frequently use, and use them for your own bindings.  As
Stefan told you, users do that all the time.  I'm quite sure most of
the developers do that as well; I certainly do.  If later you bump
into some feature that conflicts with one of your bindings, change it.
That's all there is to it, really.

Re: Localization: keyboards and messages (Re: across terminals)

[Richard Stallman]

Working on message translation is important.  There are important design
questions that were never resolved, such as, what domains should there be
and what parts of Emacs should correspond to them, and what interface
should specify the language (I think a variable should specify this).

Re: Localization: keyboards and messages (Re: across terminals)

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> [...], what domains should there be and what parts of Emacs should
> correspond to them,

Every mode should have its own domain and the rest should go in 'emacs'
or 'emacs-base'; using gettext tools it is possible to move texts from
one domain (catalog) to the other easily, in case it is necessary.

> and what interface should specify the language (I think a variable
> should specify this).

Initialize the language from the environment if the variable isn't set.


-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Localization: keyboards and messages (Re: across terminals)

[Eli Zaretskii]

> From: Karl Eichwalder <ke@gnu.franken.de>
> Date: Fri, 26 Apr 2002 20:06:02 +0200
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > [...], what domains should there be and what parts of Emacs should
> > correspond to them,
> 
> Every mode should have its own domain and the rest should go in 'emacs'
> or 'emacs-base'; using gettext tools it is possible to move texts from
> one domain (catalog) to the other easily, in case it is necessary.
> 
> > and what interface should specify the language (I think a variable
> > should specify this).
> 
> Initialize the language from the environment if the variable isn't set.

The discussion we had about related problems several months ago
unearthed quite a few issues.  I'd expect any design to somehow
address those issues, before practical work begins.

Interested readers can find the discussions I mentioned in the
emacs-devel archives; start here:

  http://mail.gnu.org/pipermail/emacs-devel/2001-December/003666.html