FW: Emacs non-ascii characters

FW: Emacs non-ascii characters

[Drew Adams]

This makes me wonder if `C-\' isn't a bad binding for such a command. Should
toggling the input method be on a key binding that is easy to hit by
mistake?

I don't use that command, so I don't know if it needs to be on a quickly hit
key. If not, should we perhaps move it to a binding with a prefix (e.g.
C-x)?

 - Drew

-----Original Message-----
From: help-gnu-emacs-bounces+drew.adams=oracle.com@gnu.org
[mailto:help-gnu-emacs-bounces+drew.adams=oracle.com@gnu.org]On Behalf
Of John Russell
Sent: Monday, November 21, 2005 11:20 AM
To: help-gnu-emacs@gnu.org
Subject: Re: Emacs non-ascii characters


Pascal Bourguignon <spam@mouse-potato.com> writes:

> John Russell <jorussel@cisco.com> writes:
>
>> I just compiled emacs from CVS a few weeks ago.  When I enter a
double-quote
>> and then some characters ( usually vowels ) the two characters get
replaced
>> with some other character, like a 'u' with an umlaut or some other accent
>> mark.
>>
>> I have been searching around for it but I don't even know what this
"feature"
>> is called.  I looked in the emacs news ( C-h n ) and found something
about
>> quail which I'm not sure is related.
>>
>> Anyway, how do I turn this off? I want to be able to type strings in code
>> again without accents.  Thanks.
>
> This is a prefix input method.
>
> You can try: C-\
> to toggle-input-method.
>
> Or C-x set-input-method RET
> to select another input method.
>
> Perhaps set the default input method?
> C-h v default-input-method RET
>

Excellent.  Thank you very much.  I must have been fat-fingering
C-\ from time to time and turning that on inadvertantly.  Thanks again. John

Re: FW: Emacs non-ascii characters

[Henrik Enberg]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 21 Nov 2005 11:26:16 -0800
> 
> This makes me wonder if `C-\' isn't a bad binding for such a command. Should
> toggling the input method be on a key binding that is easy to hit by
> mistake?
> 
> I don't use that command, so I don't know if it needs to be on a quickly hit
> key. If not, should we perhaps move it to a binding with a prefix (e.g.
> C-x)?

(global-set-key (kbd "C-\\")
		(lambda ()
		  (interactive)
		  (when (y-or-n-p "Really toggle input method? ")
		    (call-interactively 'toggle-input-method))))

Re: FW: Emacs non-ascii characters

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 21 Nov 2005 11:26:16 -0800
> Cc: John Russell <jorussel@cisco.com>
> 
> This makes me wonder if `C-\' isn't a bad binding for such a command. Should
> toggling the input method be on a key binding that is easy to hit by
> mistake?

``Easy to hit by mistake''?  IMHO, no key combination is so _hard_ to
hit by mistake as C-\.  On some non-US keyboards it's almost
impossible to hit by mistake, since it requires to use the AltGr key.

I do use input methods a lot, and yet I have never hit that key combo
by mistake until now.

RE: FW: Emacs non-ascii characters

[Drew Adams]

    > This makes me wonder if `C-\' isn't a bad binding for such a
    command. Should
    > toggling the input method be on a key binding that is easy to hit by
    > mistake?

    ``Easy to hit by mistake''?  IMHO, no key combination is so _hard_ to
    hit by mistake as C-\.  On some non-US keyboards it's almost
    impossible to hit by mistake, since it requires to use the AltGr key.

    I do use input methods a lot, and yet I have never hit that key combo
    by mistake until now.

Well, I won't argue about it much - it's not a problem I've run into; I'm
just the messenger.

WRT the difficulty of accidentally hitting `C-\' -

I have only standard, US PC keyboards, probably the most common keyboards
there are currently. `C-\' is very easy to hit by mistake: `\' is just above
the Enter key and just to the right of `]'. There is nothing hard about
hitting `\', and one could easily hit `C-\' when trying to hit `C-]'
(abort-recursive-edit).

`C-\' could also be hit easily by mistake using Shift instead of Control:
`|' is the shifted version of `\' and `}' is the shifted version of `]'.

Re: FW: Emacs non-ascii characters

[Paul Pogonyshev]

Eli Zaretskii wrote:
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Date: Mon, 21 Nov 2005 11:26:16 -0800
> > Cc: John Russell <jorussel@cisco.com>
> > 
> > This makes me wonder if `C-\' isn't a bad binding for such a command. Should
> > toggling the input method be on a key binding that is easy to hit by
> > mistake?
> 
> ``Easy to hit by mistake''?  IMHO, no key combination is so _hard_ to
> hit by mistake as C-\.  On some non-US keyboards it's almost
> impossible to hit by mistake, since it requires to use the AltGr key.
> 
> I do use input methods a lot, and yet I have never hit that key combo
> by mistake until now.

On some keyboards (like mine) the `\' key is right next to the Backspace
key, which makes `C-\' very close to `C-Backspace'.  That said, I always
use `M-Backspace' and I don't think it is a good idea to change such a
commonly-used shortcut as `C-\' at all.

Paul

RE: FW: Emacs non-ascii characters

[Drew Adams]

    On some keyboards (like mine) the `\' key is right next to the Backspace
    key, which makes `C-\' very close to `C-Backspace'.  

Right. I forgot about that one. I'd say, in sum, that with lots of common keyboards it is quite easy to hit `C-\' by mistake.

    That said, I always
    use `M-Backspace' and I don't think it is a good idea to change such a
    commonly-used shortcut as `C-\' at all.

That was my question: whether "it needs to be on a quickly hit key."  If it is quick and handy for those who use it, then fine.

Re: FW: Emacs non-ascii characters

[Paul Pogonyshev]

Drew Adams wrote:
>     On some keyboards (like mine) the `\' key is right next to the Backspace
>     key, which makes `C-\' very close to `C-Backspace'.  
> 
> Right. I forgot about that one. I'd say, in sum, that with lots of common keyboards it is quite easy to hit `C-\' by mistake.
> 
>     That said, I always
>     use `M-Backspace' and I don't think it is a good idea to change such a
>     commonly-used shortcut as `C-\' at all.
> 
> That was my question: whether "it needs to be on a quickly hit key."  If it is quick and handy for those who use it, then fine.

I'd say that it is just not worth the problems of all the users out
there to change an established shortcut.  Even if you hit it by
accident, that's not a major problem.  It's not like `C-M-Backspace'
that restarts the X server.

Paul

Re: FW: Emacs non-ascii characters

[Jason Rumney]

Drew Adams wrote:

>This makes me wonder if `C-\' isn't a bad binding for such a command. Should
>toggling the input method be on a key binding that is easy to hit by
>mistake?
>
>I don't use that command, so I don't know if it needs to be on a quickly hit
>key.
>
IMHO it does. If you are writing multilingual text (eg a programming 
language with comments in your native language), then you need to switch 
between input methods very frequently.

Re: FW: Emacs non-ascii characters

[Jason Rumney]

Drew Adams wrote:

>I have only standard, US PC keyboards, probably the most common keyboards
>there are currently. `C-\' is very easy to hit by mistake: `\' is just above
>the Enter key and just to the right of `]'. There is nothing hard about
>hitting `\', and one could easily hit `C-\' when trying to hit `C-]'
>(abort-recursive-edit).
>  
>
Perhaps if the current locale is en_US (and other en variants, since 
many use the US layout and have little need for input methods), then C-\ 
should not automatically select an input method the first time it is 
hit. Then the user will be prompted and can hit C-g. This will overcome 
the problem that if it is hit by accident by someone who knows nothing 
about input methods, they have no way of knowing what has gone wrong.

RE: FW: Emacs non-ascii characters

[Drew Adams]

    Perhaps if the current locale is en_US (and other en variants, since
    many use the US layout and have little need for input methods),
    then C-\
    should not automatically select an input method the first time it is
    hit. Then the user will be prompted and can hit C-g. This will overcome
    the problem that if it is hit by accident by someone who knows nothing
    about input methods, they have no way of knowing what has gone wrong.

That sounds like a good approach, provided the initial prompt were only
asked the first time (and the setting remembered persistently, via
Customize).

But again, I can't speak for people who use this. Would en_US users who use
`C-\' be bothered by an initial prompt?

RE: FW: Emacs non-ascii characters

[John Russell (jorussel)]

[-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --]

I have to say, now that I know what happened this will never really bug me again, but sweet Jahosafat it was annoying for a long time until I asked the list.  I think that that this could be handled like set-goal-column or downcase-region or upcase-region or narrow-to-region all of which need to be manually disabled once.  They all fit the same mold.  Some really useful and seemingly innocuous feature that could confuse the smack out of some poor unsuspecting user.  
 
John
 

________________________________

From: Drew Adams [mailto:drew.adams@oracle.com]
Sent: Mon 2005-11-21 18:27
To: emacs-devel@gnu.org
Cc: John Russell (jorussel)
Subject: RE: FW: Emacs non-ascii characters



    Perhaps if the current locale is en_US (and other en variants, since
    many use the US layout and have little need for input methods),
    then C-\
    should not automatically select an input method the first time it is
    hit. Then the user will be prompted and can hit C-g. This will overcome
    the problem that if it is hit by accident by someone who knows nothing
    about input methods, they have no way of knowing what has gone wrong.

That sounds like a good approach, provided the initial prompt were only
asked the first time (and the setting remembered persistently, via
Customize).

But again, I can't speak for people who use this. Would en_US users who use
`C-\' be bothered by an initial prompt?



[-- Attachment #1.2: Type: text/html, Size: 2336 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

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

Re: FW: Emacs non-ascii characters

[David Kastrup]

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

>     Perhaps if the current locale is en_US (and other en variants, since
>     many use the US layout and have little need for input methods),
>     then C-\
>     should not automatically select an input method the first time it is
>     hit. Then the user will be prompted and can hit C-g. This will overcome
>     the problem that if it is hit by accident by someone who knows nothing
>     about input methods, they have no way of knowing what has gone wrong.
>
> That sounds like a good approach, provided the initial prompt were
> only asked the first time (and the setting remembered persistently,
> via Customize).
>
> But again, I can't speak for people who use this. Would en_US users
> who use `C-\' be bothered by an initial prompt?

Yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: FW: Emacs non-ascii characters

[Richard M. Stallman]

    This makes me wonder if `C-\' isn't a bad binding for such a command. Should
    toggling the input method be on a key binding that is easy to hit by
    mistake?

Please don't suggest changes in features that were in Emacs 21.
It is a distraction from the bug-fixing we need to do.

Re: FW: Emacs non-ascii characters

[Kenichi Handa]

In article <43825633.5040403@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Perhaps if the current locale is en_US (and other en variants, since 
> many use the US layout and have little need for input methods), then C-\ 
> should not automatically select an input method the first time it is 
> hit. Then the user will be prompted and can hit C-g. This will overcome 
> the problem that if it is hit by accident by someone who knows nothing 
> about input methods, they have no way of knowing what has gone wrong.

If the current locale is not set or "C", emacs starts with
"English" lang. env., default-input-method is not set, thus
C-\ prompts you to specify an input method.  But if the
locale is "en_US", emacs starts with "Latin-1" lang. env. because
of this entry.

(defconst locale-language-names
[...]
    ;; Users who specify "en" explicitly typically want Latin-1, not ASCII.
    ;; That's actually what the GNU locales define, modulo things like
    ;; en_IN -- fx.
    ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
    ("en" . "Latin-1") ; English

And, in this lang. env., default-input-method is set to
latin-1-prefix, thus C-\ automatically activates it.

If this situation is not good, have about this change.

***************
*** 2129,2135 ****
      ;; That's actually what the GNU locales define, modulo things like
      ;; en_IN -- fx.
      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
!     ("en" . "Latin-1") ; English
      ("eo" . "Latin-3") ; Esperanto
      ("es" "Spanish" iso-8859-1)
      ("et" . "Latin-1") ; Estonian
--- 2138,2144 ----
      ;; That's actually what the GNU locales define, modulo things like
      ;; en_IN -- fx.
      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
!     ("en" "English" iso-8859-1) ; English
      ("eo" . "Latin-3") ; Esperanto
      ("es" "Spanish" iso-8859-1)
      ("et" . "Latin-1") ; Estonian

Then, emacs starts with English lang. env. but the default
coding systems are set to iso-8859-1.

Shall I install this change?

---
Kenichi Handa
handa@m17n.org

Re: FW: Emacs non-ascii characters

[Miles Bader]

2005/11/22, Jason Rumney <jasonr@gnu.org>:
> >I don't use that command, so I don't know if it needs to be on a quickly hit
> >key.
>
> IMHO it does. If you are writing multilingual text (eg a programming
> language with comments in your native language), then you need to switch
> between input methods very frequently.

Yes, you are right.  This command needs to be very easy to type.  The
binding should definitely not be changed!

-Miles
--
Do not taunt Happy Fun Ball.

Re: FW: Emacs non-ascii characters

[Jason Rumney]

Kenichi Handa wrote:

>If this situation is not good, have about this change.
>
>***************
>*** 2129,2135 ****
>      ;; That's actually what the GNU locales define, modulo things like
>      ;; en_IN -- fx.
>      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
>!     ("en" . "Latin-1") ; English
>      ("eo" . "Latin-3") ; Esperanto
>      ("es" "Spanish" iso-8859-1)
>      ("et" . "Latin-1") ; Estonian
>--- 2138,2144 ----
>      ;; That's actually what the GNU locales define, modulo things like
>      ;; en_IN -- fx.
>      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
>!     ("en" "English" iso-8859-1) ; English
>      ("eo" . "Latin-3") ; Esperanto
>      ("es" "Spanish" iso-8859-1)
>      ("et" . "Latin-1") ; Estonian
>
>  
>
en_GB at least needs to default to Latin-1 because of the pound sign.

Re: FW: Emacs non-ascii characters

[Aidan Kehoe]

 Ar an cúigiú lá is fiche de mí na Samhain, scríobh Jason Rumney: 

 > Kenichi Handa wrote:
 > 
 > >If this situation is not good, have about this change.
 > >
 > >***************
 > >*** 2129,2135 ****
 > >      ;; That's actually what the GNU locales define, modulo things like
 > >      ;; en_IN -- fx.
 > >      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
 > >!     ("en" . "Latin-1") ; English
 > >      ("eo" . "Latin-3") ; Esperanto
 > >      ("es" "Spanish" iso-8859-1)
 > >      ("et" . "Latin-1") ; Estonian
 > >--- 2138,2144 ----
 > >      ;; That's actually what the GNU locales define, modulo things like
 > >      ;; en_IN -- fx.
 > >      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
 > >!     ("en" "English" iso-8859-1) ; English
 > >      ("eo" . "Latin-3") ; Esperanto
 > >      ("es" "Spanish" iso-8859-1)
 > >      ("et" . "Latin-1") ; Estonian
 > >
 > >  
 > >
 > en_GB at least needs to default to Latin-1 because of the pound sign.

That’s a non-sequitur. en_GB environments typically have the pound sign
available on the keyboard, and don’t need an input method for it.

Latin-1 is a sane default for English, because of words like café, façade,
naïve that orthographically need it, even if this need has been ignored. 

-- 
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.

Re: FW: Emacs non-ascii characters

[Jason Rumney]

Aidan Kehoe wrote:

> > en_GB at least needs to default to Latin-1 because of the pound sign.
>
>That’s a non-sequitur. en_GB environments typically have the pound sign
>available on the keyboard, and don’t need an input method for it.
>  
>
Right, but the variable in question sets up a Language Environment, 
which is a lot more than just input-method.

Re: FW: Emacs non-ascii characters

[Aidan Kehoe]

 Ar an cúigiú lá is fiche de mí na Samhain, scríobh Jason Rumney: 

 > > > en_GB at least needs to default to Latin-1 because of the pound sign.
 > >
 > >That’s a non-sequitur. en_GB environments typically have the pound sign
 > >available on the keyboard, and don’t need an input method for it.
 >
 > Right, but the variable in question sets up a Language Environment, 
 > which is a lot more than just input-method.

Yeah, but the “lot more” doesn’t matter for en_GB English versus US English.
If a character isn’t in US-ASCII, the “English” environment goes for ISO
8859-1, which eliminates any incompatibilities with the Latin-1 environment,
_except for_ the input method. 

-- 
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.

Re: FW: Emacs non-ascii characters

[Richard M. Stallman]

      But if the
    locale is "en_US", emacs starts with "Latin-1" lang. env. because
    of this entry.

I don't understand why that was done,
since this comment is not very clear.

	;; Users who specify "en" explicitly typically want Latin-1, not ASCII.
	;; That's actually what the GNU locales define, modulo things like
	;; en_IN -- fx.

but I also don't see why we would want to change it.

Re: FW: Emacs non-ascii characters

[Kenichi Handa]

In article <E1EfrbE-0003zu-R7@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> writes:

>       But if the
>     locale is "en_US", emacs starts with "Latin-1" lang. env. because
>     of this entry.

> I don't understand why that was done,
> since this comment is not very clear.

> 	;; Users who specify "en" explicitly typically want Latin-1, not ASCII.
> 	;; That's actually what the GNU locales define, modulo things like
> 	;; en_IN -- fx.

I don't the wording "modulo things like en_IN".  But, I
think he wanted to indicate this data in
/usr/share/i18n/SUPPORTED.

en_US ISO-8859-1
en_US.UTF-8 UTF-8
en_IN UTF-8

It says that in en_US locale, the encoding iso-8859-1 is
supported, but, in en_US.UTF-8 and en_IN, the encoding UTF-8
is supported.

So, I think, in en_US locale, setting the default coding
system to iso-8859-1 is the right thing.  Currently, we do
that by setting "Latin-1" lang. env.  But that sets
default-input-method to latin-1-prefix, thus C-\
automatically activates it.

> but I also don't see why we would want to change it.

By the change, emacs started under en_US locale is put in
"English" lang. env. (thus default-input-method is not set)
but the default conding systems are still set to iso-8859-1.

---
Kenichi Handa
handa@m17n.org

Re: FW: Emacs non-ascii characters

[Kenichi Handa]

In article <E1Efulh-0000h9-00@etlken>, Kenichi Handa <handa@m17n.org> writes:

> I don't the wording "modulo things like en_IN".  But, I

Oops, I mean:

> I don't understand the wording "modulo things like en_IN".  But, I

---
Kenichi Handa
handa@m17n.org

Re: FW: Emacs non-ascii characters

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Sat, 26 Nov 2005 16:46:45 +0900
> Cc: jorussel@cisco.com, emacs-devel@gnu.org, drew.adams@oracle.com,
> 	jasonr@gnu.org
> 
> > 	;; Users who specify "en" explicitly typically want Latin-1, not ASCII.
> > 	;; That's actually what the GNU locales define, modulo things like
> > 	;; en_IN -- fx.
> 
> I don't the wording "modulo things like en_IN".

It means that en_IN is excluded from whatever the preceding text
described.

Re: FW: Emacs non-ascii characters

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <E1Efulh-0000h9-00@etlken>, Kenichi Handa <handa@m17n.org> writes:
>
>> I don't the wording "modulo things like en_IN".  But, I
>
> Oops, I mean:
>
>> I don't understand the wording "modulo things like en_IN".  But, I

It is sort of a lame mathematical joke.  Replace "modulo" with "not
considering".

5 = 13 (modulo 8) (namely when 8 and its multiples are considered
                   equivalent to 0)

Typical use in colloquial speech:

I feel fine modulo a slight headache.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: FW: Emacs non-ascii characters

[Richard M. Stallman]

    So, I think, in en_US locale, setting the default coding
    system to iso-8859-1 is the right thing.  Currently, we do
    that by setting "Latin-1" lang. env.  But that sets
    default-input-method to latin-1-prefix, thus C-\
    automatically activates it.

I see the issue.  I agree that it should not set default-input-method.

Thanks for dealing with this.

Re: FW: Emacs non-ascii characters

[Kenichi Handa]

In article <E1EgASJ-0000HI-7q@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> writes:

>     So, I think, in en_US locale, setting the default coding
>     system to iso-8859-1 is the right thing.  Currently, we do
>     that by setting "Latin-1" lang. env.  But that sets
>     default-input-method to latin-1-prefix, thus C-\
>     automatically activates it.

> I see the issue.  I agree that it should not set default-input-method.

> Thanks for dealing with this.

I've just installed the change I proposed.

---
Kenichi Handa
handa@m17n.org