Cedilla input in UTF-8 locale with dead keys.

Cedilla input in UTF-8 locale with dead keys.

[Kenichi Handa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO-2022-JP-2, Size: 1603 bytes --]

Attached is a report about the inconsistency of dead key
handling on Emacs with the other applications.  I confirmed
the reported behaviour with the trunk code by starting the X
session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
inserts ^[$(D+.^[(B (c-cedilla) in gnome-terminal, but it inserts ^[$(D++^[(B
(c-acute) in Emacs.

But, it seems that inserting c-cedilla is the behaviour only
with GNOME/GTK applications (and OpenOffice, Mozilla).  For
instance, xev reports "RightAlt-' c" as c-acute, any KDE
applications (e.g. kedit) insert c-acute.  Gustavo, could
you also try them?

I'm not sure what we should do.  Emacs is not a GTK
application even if it is configured with --with-gtk.  But,
from the user point of view, I think it is better that it
insert c-cedilla as well as the other GNOME applications.

But, as I'm not that familiar with GTK programming, I don't
know how to do that.

---
Kenichi Handa
handa@m17n.org

------- Start of forwarded message -------
From: Gustavo Maciel Dias Vieira <gustavo@sagui.org>
To: bug-gnu-emacs@gnu.org
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Date: Wed,  3 Oct 2007 14:00:55 -0300 (BRT)
Subject: Cedilla input in UTF-8 locale with dead keys.


If you use the combination of Emacs 22, a US keyboard and dead
keys in a UTF-8 locale, the combination of '+c will give you
^[$(D++^[(B (accented-c) instead of ^[$(D+.^[(B (cedilla). Granted, not everyone will want
a cedilla, but some people will do. Brazilians for example. GTK2 had
the same issue some time ago and they created an input method called
"cedilla" that is activated based on locale.

Re: Cedilla input in UTF-8 locale with dead keys.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> Attached is a report about the inconsistency of dead key
> handling on Emacs with the other applications.  I confirmed
> the reported behaviour with the trunk code by starting the X
> session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
> inserts ç (c-cedilla) in gnome-terminal, but it inserts ć
> (c-acute) in Emacs.

Which keysym is on RightAlt-'?

Andreas.

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

Re: Cedilla input in UTF-8 locale with dead keys.

[Kenichi Handa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO-2022-JP-2, Size: 599 bytes --]

In article <jemyukr1tv.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > Attached is a report about the inconsistency of dead key
> > handling on Emacs with the other applications.  I confirmed
> > the reported behaviour with the trunk code by starting the X
> > session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
> > inserts ^[$(D+.^[(B (c-cedilla) in gnome-terminal, but it inserts ^[$(D++^[(B
> > (c-acute) in Emacs.

> Which keysym is on RightAlt-'?

0x1000107; i.e. U+0107 LATIN SMALL LETTER C WITH ACUTE

---
Kenichi Handa
handa@m17n.org

Re: Cedilla input in UTF-8 locale with dead keys.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> In article <jemyukr1tv.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
>
>> Kenichi Handa <handa@m17n.org> writes:
>> > Attached is a report about the inconsistency of dead key
>> > handling on Emacs with the other applications.  I confirmed
>> > the reported behaviour with the trunk code by starting the X
>> > session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
>> > inserts ç (c-cedilla) in gnome-terminal, but it inserts ć
>> > (c-acute) in Emacs.
>
>> Which keysym is on RightAlt-'?
>
> 0x1000107; i.e. U+0107 LATIN SMALL LETTER C WITH ACUTE

Where does the c key come into play then?

Andreas.

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

Re: Cedilla input in UTF-8 locale with dead keys.

[Kenichi Handa]

In article <jeir58qytk.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > In article <jemyukr1tv.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
> >
>>> Kenichi Handa <handa@m17n.org> writes:
>>> > Attached is a report about the inconsistency of dead key
>>> > handling on Emacs with the other applications.  I confirmed
>>> > the reported behaviour with the trunk code by starting the X
>>> > session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
>>> > inserts ç (c-cedilla) in gnome-terminal, but it inserts ć
>>> > (c-acute) in Emacs.
> >
>>> Which keysym is on RightAlt-'?
> >
> > 0x1000107; i.e. U+0107 LATIN SMALL LETTER C WITH ACUTE

> Where does the c key come into play then?

Oops, my fault.  The above keysym is returned by typing
"RightAlt-' c".   With just "RightAlt-'", xev reports these
keysyms (the first one by RightAlt, the second by ':

KeyPress event, serial 29, synthetic NO, window 0x3200001,
    root 0x4d, subw 0x3200002, time 2805295975, (32,34), root:(1428,80),
    state 0x0, keycode 113 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: True

KeyPress event, serial 29, synthetic NO, window 0x3200001,
    root 0x4d, subw 0x3200002, time 2805299769, (32,34), root:(1428,80),
    state 0x80, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
    XLookupString gives 1 bytes: (27) "'"
    XmbLookupString gives 1 bytes: (27) "'"
    XFilterEvent returns: True

Please note that XFilterEvent is True in both cases.  Thus
some input method has filtered them.

---
Kenichi Handa
handa@m17n.org

Re: Cedilla input in UTF-8 locale with dead keys.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> Oops, my fault.  The above keysym is returned by typing
> "RightAlt-' c".   With just "RightAlt-'", xev reports these
> keysyms (the first one by RightAlt, the second by ':

Since RightAlt is not a modifier you need to type it separately.  If you
write RightAlt-' it looks like RightAlt modifies the ' key, and I was
assuming that produces <dead_acute>.

> KeyPress event, serial 29, synthetic NO, window 0x3200001,
>     root 0x4d, subw 0x3200002, time 2805295975, (32,34), root:(1428,80),
>     state 0x0, keycode 113 (keysym 0xff20, Multi_key), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: True
>
> KeyPress event, serial 29, synthetic NO, window 0x3200001,
>     root 0x4d, subw 0x3200002, time 2805299769, (32,34), root:(1428,80),
>     state 0x80, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
>     XLookupString gives 1 bytes: (27) "'"
>     XmbLookupString gives 1 bytes: (27) "'"
>     XFilterEvent returns: True

That explains it.  pt_BR.UTF-8/Compose says that <Multi_key> <acute> <C>
produces "Ć" (unlike <dead_acute> <C>, which is supposed to produce
"Ç").

Andreas.

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

Re: Cedilla input in UTF-8 locale with dead keys.

[Stefan Monnier]

>> Oops, my fault.  The above keysym is returned by typing
>> "RightAlt-' c".   With just "RightAlt-'", xev reports these
>> keysyms (the first one by RightAlt, the second by ':

> Since RightAlt is not a modifier you need to type it separately.  If you
> write RightAlt-' it looks like RightAlt modifies the ' key, and I was
> assuming that produces <dead_acute>.

Actually, I believe as long as you press RightAlt before pressing ' it'll
work, even if you don't release RightAlt before pressing '.
So even though it's not a modifier, you can almost use it like one.


        Stefan

Re: Cedilla input in UTF-8 locale with dead keys.

[Jan Djärv]

FWIW, Gtk+ has a special handling of this.  Gtk+ also processes all compose 
itself, rather than using X.  See Gtk+ sources, modules/input/imcedilla.c:

/* The difference between this and the default input method is the handling
  * of C+acute - this method produces C WITH CEDILLA rather than C WITH ACUTE.
  * For languages that use CCedilla and not acute, this is the preferred mapping,
  * and is particularly important for pt_BR, where the us-intl keyboard is
  * used extensively.
  */

Since Emacs does not use Gtk+ for character input, we don't get that mapping.

	Jan D.


Kenichi Handa skrev:
> Attached is a report about the inconsistency of dead key
> handling on Emacs with the other applications.  I confirmed
> the reported behaviour with the trunk code by starting the X
> session in pt_BR.UTF-8 locale.  Typing "RightAlt-' c"
> inserts ç (c-cedilla) in gnome-terminal, but it inserts ć
> (c-acute) in Emacs.
> 
> But, it seems that inserting c-cedilla is the behaviour only
> with GNOME/GTK applications (and OpenOffice, Mozilla).  For
> instance, xev reports "RightAlt-' c" as c-acute, any KDE
> applications (e.g. kedit) insert c-acute.  Gustavo, could
> you also try them?
> 
> I'm not sure what we should do.  Emacs is not a GTK
> application even if it is configured with --with-gtk.  But,
> from the user point of view, I think it is better that it
> insert c-cedilla as well as the other GNOME applications.
> 
> But, as I'm not that familiar with GTK programming, I don't
> know how to do that.
> 
> ---
> Kenichi Handa
> handa@m17n.org
> 
> ------- Start of forwarded message -------
> From: Gustavo Maciel Dias Vieira <gustavo@sagui.org>
> To: bug-gnu-emacs@gnu.org
> MIME-version: 1.0
> Content-type: text/plain; charset=utf-8
> Date: Wed,  3 Oct 2007 14:00:55 -0300 (BRT)
> Subject: Cedilla input in UTF-8 locale with dead keys.
> 
> 
> If you use the combination of Emacs 22, a US keyboard and dead
> keys in a UTF-8 locale, the combination of '+c will give you
> ć (accented-c) instead of ç (cedilla). Granted, not everyone will want
> a cedilla, but some people will do. Brazilians for example. GTK2 had
> the same issue some time ago and they created an input method called
> "cedilla" that is activated based on locale.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Cedilla input in UTF-8 locale with dead keys.

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> FWIW, Gtk+ has a special handling of this.  Gtk+ also processes all
> compose itself, rather than using X.  See Gtk+ sources,
> modules/input/imcedilla.c:
>
> /* The difference between this and the default input method is the handling
>  * of C+acute - this method produces C WITH CEDILLA rather than C WITH ACUTE.
>  * For languages that use CCedilla and not acute, this is the preferred mapping,
>  * and is particularly important for pt_BR, where the us-intl keyboard is
>  * used extensively.
>  */
>
> Since Emacs does not use Gtk+ for character input, we don't get that mapping.

According to /usr/share/X11/locale/pt_BR.UTF-8/Compose, <dead_acute> <C>
produces "Ç", not "Ć".

Andreas.

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

Re: Cedilla input in UTF-8 locale with dead keys.

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> FWIW, Gtk+ has a special handling of this.  Gtk+ also processes all
>> compose itself, rather than using X.  See Gtk+ sources,
>> modules/input/imcedilla.c:
>>
>> /* The difference between this and the default input method is the handling
>>  * of C+acute - this method produces C WITH CEDILLA rather than C WITH ACUTE.
>>  * For languages that use CCedilla and not acute, this is the preferred mapping,
>>  * and is particularly important for pt_BR, where the us-intl keyboard is
>>  * used extensively.
>>  */
>>
>> Since Emacs does not use Gtk+ for character input, we don't get that mapping.
> 
> According to /usr/share/X11/locale/pt_BR.UTF-8/Compose, <dead_acute> <C>
> produces "Ç", not "Ć".
> 

I can see that this file gets read by for example xterm, but it doesn't seem 
to have any effect.  Strange.

	Jan D.

Re: Cedilla input in UTF-8 locale with dead keys.

[Stefan Monnier]

> FWIW, Gtk+ has a special handling of this.  Gtk+ also processes all compose
> itself, rather than using X.  See Gtk+ sources, modules/input/imcedilla.c:

> /* The difference between this and the default input method is the handling
>  * of C+acute - this method produces C WITH CEDILLA rather than C WITH ACUTE.
>  * For languages that use CCedilla and not acute, this is the preferred mapping,
>  * and is particularly important for pt_BR, where the us-intl keyboard is
>  * used extensively.
>  */

> Since Emacs does not use Gtk+ for character input, we don't get that mapping.

Looks like brain-damage on the part of the Gtk guys: if there's a problem in
this area, it should be fixed in Xlib, not in Gtk.
I'd rather follow the standard X behavior (and maybe lobby for its change),
than use some ad-hoc workaround.


        Stefan

Re: Cedilla input in UTF-8 locale with dead keys.

[Kenichi Handa]

In article <jwv1wbwfpaa.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > FWIW, Gtk+ has a special handling of this.  Gtk+ also processes all compose
> > itself, rather than using X.  See Gtk+ sources, modules/input/imcedilla.c:

> > /* The difference between this and the default input method is the handling
> >  * of C+acute - this method produces C WITH CEDILLA rather than C WITH ACUTE.
> >  * For languages that use CCedilla and not acute, this is the preferred mapping,
> >  * and is particularly important for pt_BR, where the us-intl keyboard is
> >  * used extensively.
> >  */

Ah!  It is done by Gtk's input method.

> > Since Emacs does not use Gtk+ for character input, we don't get that mapping.

I see.

> Looks like brain-damage on the part of the Gtk guys: if there's a problem in
> this area, it should be fixed in Xlib, not in Gtk.
> I'd rather follow the standard X behavior (and maybe lobby for its change),
> than use some ad-hoc workaround.

I fully agree.  By the way, I found that c-cedilla can be
input by typing "RightAlt-, c" with all applications
(including Emacs) in pt_BR.UTF-8 locale.

---
Kenichi Handa
handa@m17n.org

Cedilla input in UTF-8 locale with dead keys.

[Gustavo Maciel Dias Vieira]

If you use the combination of Emacs 22, a US keyboard and dead
keys in a UTF-8 locale, the combination of '+c will give you
ć (accented-c) instead of ç (cedilla). Granted, not everyone will want
a cedilla, but some people will do. Brazilians for example. GTK2 had
the same issue some time ago and they created an input method called
"cedilla" that is activated based on locale.


In GNU Emacs 22.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.10.13)
 of 2007-06-26 on xenbuilder2.fedora.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: pt_BR.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/preview-latex.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/python-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el (source)...done
For information about the GNU Project and its goals, type C-h C-p. [2 times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done