Menu
▾
▴
mlterm-dev-en
|
From: Martin H. <hor...@Fr...> - 2002-11-27 14:44:55
|
Hi, I am experiencing a problem with mlterm - bad reaction to dead keys. I have set up Czech locale and whenever I press the key for accent, mlterm does not wait for the next key saying which character should be accented and prints the accent alone. The same problem I have with aterm and wterm but xterm, rxvt or Eterm works well. Is it a bug in mlterm or rather some failure in my configuration? I am using mlterm-2.6.2, XFree86-4.2.0, FreeBSD 4.6-RELEASE, locale cs_CZ.ISO_8859-2. Please, Cc me to your answers - I am not member of this list. Best regards. Martin |
|
From: MINAMI H. <mi...@ch...> - 2002-11-27 16:23:54
|
Hi,
On Wed, 27 Nov 2002 15:44:32 +0100 (CET)
Martin Horcicka <hor...@Fr...> wrote:
> I am experiencing a problem with mlterm - bad reaction to dead keys. I have
> set up Czech locale and whenever I press the key for accent, mlterm does not
> wait for the next key saying which character should be accented and prints the
> accent alone. The same problem I have with aterm and wterm but xterm, rxvt or
> Eterm works well. Is it a bug in mlterm or rather some failure in my
> configuration?
It's reported in the past and should be a mlterm's problem.
Would you test whether following patch makes some change?
--- x_window.c 21 Nov 2002 14:02:57 -0000 1.29
+++ x_window.c 27 Nov 2002 16:08:20 -0000
@@ -2179,13 +2179,14 @@
)
{
size_t len ;
-
+ static XComposeStatus compose_status = {NULL, 0} ;
+
if( ( len = x_xic_get_str( win , seq , seq_len , parser , keysym , event)) > 0)
{
return len ;
}
- if( ( len = XLookupString( event , seq , seq_len , keysym , NULL)) > 0)
+ if( ( len = XLookupString( event , seq , seq_len , keysym , &compose_status)) > 0)
{
*parser = NULL ;
|
|
From: Jari P.T. A. <jar...@he...> - 2002-11-27 17:46:25
|
MINAMI Hirokazu, Quinta, 28 Nov, 2002; 01:23:50 +0900: > Hi, >=20 > On Wed, 27 Nov 2002 15:44:32 +0100 (CET) > Martin Horcicka <hor...@Fr...> wrote: >=20 > > I am experiencing a problem with mlterm - bad reaction to dead keys. I = have > > set up Czech locale and whenever I press the key for accent, mlterm doe= s not > > wait for the next key saying which character should be accented and pri= nts the > > accent alone. The same problem I have with aterm and wterm but xterm, r= xvt or > It's reported in the past and should be a mlterm's problem. > Would you test whether following patch makes some change?=20 I'm afraid this didn't make any difference. To elaborate on the status quo: =C2=B7=C2=A0if the locale is UTF-8, dead accents are always non-dead, i.e. composing does not work. =C2=B7 if the locale is something else and XMODIFIERS is set to @im=3Dnone,= the dead accents do not appear live but seem to wait as they're supposed to. However, when pressing the character it's supposed to combine to, the character appears without accents, i.e. composing still does not work. This is a major problem for me, since none of the terminals work completely. The accents work fine in uxterm & co, but not if there's an input method set in XMODIFIERS, which I need when I decide to write Chinese. This can be changed on the go with mlterm, but there the accents don't work, so writing Chinese is OK, but can't write European languages (other than those that have been defined a direct key). Unfortunately I have very little time and no knowledge of the workings of these apps, so I'm hoping someone else will fix them. --=20 Jari Alhonen | =E8=B0=B7=E4=BA=9A=E7=91=9E | =EC=95=BC=EB=A6=AC =EC=95=8C= =ED=98=B8=EB=84=A8 | =E3=83=A4=E3=83=AA=E3=83=BB=E3=82=A2=E3=83=AB=E3=83=9B= =E3=83=8D=E3=83=B3 | =E0=A4=AF=E0=A4=BE=E0=A4=B0=E0=A4=BF =E0=A4=86=E0=A4= =B2=E0=A5=8D=E0=A4=B9=E0=A5=8B=E0=A4=A8=E0=A5=87=E0=A4=A8 [=CB=88j=C9=91ri =CB=88=C9=91l=C9=A6=C9=94n=C9=9Bn] | =D0=AF=D1=80=D0=B8 = =D0=90=D0=BB=D1=8C=D1=85=D0=BE=D0=BD=D0=B5=D0=BD | =CE=93=CE=B9=CE=AC=CF=81= =CE=B9 =CE=86=CE=BB=CF=87=CE=BF=CE=BD=CE=B5=CE=BD | =E2=80=AE=D9=8A=D8=A7= =D8=B1=D9=8A =D8=A7=D9=84=D9=87=D9=88=D9=86=D9=8A=D9=86=E2=80=AC |
|
From: MINAMI H. <mi...@ch...> - 2002-11-28 04:10:46
|
On Wed, 27 Nov 2002 19:46:11 +0200
"Jari P.T. Alhonen" <jar...@he...> wrote:
> I'm afraid this didn't make any difference. To elaborate on the status quo:
> composing does not work.
> 揃 if the locale is something else and XMODIFIERS is set to @im=none, the
> dead accents do not appear live but seem to wait as they're supposed to.
> However, when pressing the character it's supposed to combine to, the
> character appears without accents, i.e. composing still does not work.
Hmm, judging from your report, it seems that XmbLookupString()
returns 0 and sets "XLookupNone" as when "dead accent" key is sent.
That may mean Xutf8LookupString() is called subsequently
and win->xic will be sent the same keypress event again and be messed up.
# what happens in xterm if you press "dead accent" key twice?
Please apply following patch and try the half-workng configuration
(LANG=[something else], XMODIFIERS=@im=none)
again.
--- x_window.c 21 Nov 2002 14:02:57 -0000 1.29
+++ x_window.c 28 Nov 2002 03:54:08 -0000
@@ -2191,12 +2191,12 @@
return len ;
}
-
+ /*
if( ( len = x_xic_get_utf8_str( win , seq , seq_len , parser , keysym , event)) > 0)
{
return len ;
}
-
+ */
return 0 ;
}
|
|
From: Jari P.T. A. <jar...@he...> - 2002-11-28 08:19:43
|
MINAMI Hirokazu, Quinta, 28 Nov, 2002; 13:10:43 +0900: >=20 > # what happens in xterm if you press "dead accent" key twice?=20 In a regular xterm it displays the accent alone, in a Unicode xterm some accents aren't displayed alone since several accents can be input to the same character. > Please apply following patch and try the half-workng configuration > (LANG=3D[something else], XMODIFIERS=3D@im=3Dnone) > again. This made no difference. Btw, I just noticed that some dead accents are "alive" even with these settings, ie. greve, circumflex and tilde, while the acute accent and diaresis are seemingly dead while not actually working at all as reported earlier. So I don't know if it is half-working after all. --=20 Jari Alhonen | =E8=B0=B7=E4=BA=9A=E7=91=9E | =EC=95=BC=EB=A6=AC =EC=95=8C= =ED=98=B8=EB=84=A8 | =E3=83=A4=E3=83=AA=E3=83=BB=E3=82=A2=E3=83=AB=E3=83=9B= =E3=83=8D=E3=83=B3 | =E0=A4=AF=E0=A4=BE=E0=A4=B0=E0=A4=BF =E0=A4=86=E0=A4= =B2=E0=A5=8D=E0=A4=B9=E0=A5=8B=E0=A4=A8=E0=A5=87=E0=A4=A8 [=CB=88j=C9=91ri =CB=88=C9=91l=C9=A6=C9=94n=C9=9Bn] | =D0=AF=D1=80=D0=B8 = =D0=90=D0=BB=D1=8C=D1=85=D0=BE=D0=BD=D0=B5=D0=BD | =CE=93=CE=B9=CE=AC=CF=81= =CE=B9 =CE=86=CE=BB=CF=87=CE=BF=CE=BD=CE=B5=CE=BD | =E2=80=AE=D9=8A=D8=A7= =D8=B1=D9=8A =D8=A7=D9=84=D9=87=D9=88=D9=86=D9=8A=D9=86=E2=80=AC |
|
From: Martin H. <hor...@Fr...> - 2002-11-28 10:14:21
|
Hi,
MINAMI Hirokazu (2002-11-28 01:23 +0900):
> On Wed, 27 Nov 2002 15:44:32 +0100 (CET)
> Martin Horcicka <hor...@Fr...> wrote:
>
> > I am experiencing a problem with mlterm - bad reaction to dead keys. I have
> > set up Czech locale and whenever I press the key for accent, mlterm does not
> > wait for the next key saying which character should be accented and prints the
> > accent alone. The same problem I have with aterm and wterm but xterm, rxvt or
> > Eterm works well. Is it a bug in mlterm or rather some failure in my
> > configuration?
>
> It's reported in the past and should be a mlterm's problem.
> Would you test whether following patch makes some change?
no, it does not make any change. I've heard something about using
XmbLookupString rather than XLookupString in relation with this problem but I
am not X programmer. rxvt had this problem in the past and now it has not -
maybe it would be helpful to compare it's older and present sources.
Regards
Martin
> --- x_window.c 21 Nov 2002 14:02:57 -0000 1.29
> +++ x_window.c 27 Nov 2002 16:08:20 -0000
> @@ -2179,13 +2179,14 @@
> )
> {
> size_t len ;
> -
> + static XComposeStatus compose_status = {NULL, 0} ;
> +
> if( ( len = x_xic_get_str( win , seq , seq_len , parser , keysym , event)) > 0)
> {
> return len ;
> }
>
> - if( ( len = XLookupString( event , seq , seq_len , keysym , NULL)) > 0)
> + if( ( len = XLookupString( event , seq , seq_len , keysym , &compose_status)) > 0)
> {
> *parser = NULL ;
>
|
|
From: MINAMI <mi...@ch...> - 2002-12-02 04:30:12
|
Hi,
On Thu, 28 Nov 2002 11:13:59 +0100 (CET)
Martin Horcicka <hor...@Fr...> wrote:
> no, it does not make any change. I've heard something about using
> XmbLookupString rather than XLookupString in relation with this problem but I
> am not X programmer. rxvt had this problem in the past and now it has not -
> maybe it would be helpful to compare it's older and present sources.
Thanks for your suggestion.
The rxvt's cahngelog says
If the user didn't specify an IM then we should still try to
connect with "im=none" in case a base IM service is used for
items like dead keys in single char glyph locales
so it seems for me that all we have to do is to create XIM and use XmbLookupString().
As XmbLookupString() requires a valid XIC to work, please check whether
an mlterm which is configured with an --enable-debug option putputs
"WARN: [create_xic()] XIC activated."
on its startup.
regards,
minami
|
|
From: Martin H. <hor...@Fr...> - 2002-12-02 10:05:13
|
Hi, MINAMI (2002-12-02 13:30 +0900): > The rxvt's cahngelog says > If the user didn't specify an IM then we should still try to > connect with "im=none" in case a base IM service is used for > items like dead keys in single char glyph locales > so it seems for me that all we have to do is to create XIM and use > XmbLookupString(). > > As XmbLookupString() requires a valid XIC to work, please check whether > an mlterm which is configured with an --enable-debug option putputs > "WARN: [create_xic()] XIC activated." > on its startup. I have configured mlterm with --enable-debug - all the options are: running /bin/sh ./configure --with-imagelib=imlib --enable-utmp --enable-debug --enable-anti-alias --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include --prefix=/usr/X11R6 i386-portbld-freebsd4.6 --cache-file=../.././config.cache --srcdir=. When I run mlterm without any options and without ~/.mlterm directory it writes: WARN: [kik_conf_read()] /usr/X11R6/etc/mlterm/core couldn't be opened. WARN: [kik_conf_read()] /home/horcicka/.mlterm/core couldn't be opened. WARN: [kik_conf_read()] /home/horcicka/.mlterm/main couldn't be opened. WARN: [kik_conf_get_value()] no such key[daemon_mode] in conf map. WARN: [kik_conf_get_value()] no such key[use_xim] in conf map. WARN: [kik_conf_get_value()] no such key[font_size_range] in conf map. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/font couldn't be opened. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/vfont couldn't be opened. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/tfont couldn't be opened. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/aafont couldn't be opened. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/vaafont couldn't be opened. WARN: [x_font_custom_read_conf()] /home/horcicka/.mlterm/taafont couldn't be opened. WARN: [kik_conf_get_value()] no such key[compose_dec_special_font] in conf map. WARN: [kik_conf_get_value()] no such key[use_cp932_ucs_for_xft] in conf map. WARN: [x_color_custom_read_conf()] /home/horcicka/.mlterm/color couldn't be opened. WARN: [x_keymap_read_conf()] /home/horcicka/.mlterm/key couldn't be opened. WARN: [x_termcap_read_conf()] /home/horcicka/.mlterm/termcap couldn't be opened. WARN: [kik_conf_get_value()] no such key[ptys] in conf map. WARN: [kik_conf_get_value()] no such key[word_separators] in conf map. WARN: [kik_conf_get_value()] no such key[display] in conf map. WARN: [kik_conf_get_value()] no such key[fontsize] in conf map. WARN: [kik_conf_get_value()] no such key[app_name] in conf map. WARN: [kik_conf_get_value()] no such key[title] in conf map. WARN: [kik_conf_get_value()] no such key[icon_name] in conf map. WARN: [kik_conf_get_value()] no such key[conf_menu_path] in conf map. WARN: [kik_conf_get_value()] no such key[use_combining] in conf map. WARN: [kik_conf_get_value()] no such key[use_dynamic_comb] in conf map. WARN: [kik_conf_get_value()] no such key[use_variable_column_width] in conf map. WARN: [kik_conf_get_value()] no such key[step_in_changing_font_size] in conf map. WARN: [kik_conf_get_value()] no such key[use_anti_alias] in conf map. WARN: [kik_conf_get_value()] no such key[vertical_mode] in conf map. WARN: [kik_conf_get_value()] no such key[fg_color] in conf map. WARN: [kik_conf_get_value()] no such key[bg_color] in conf map. WARN: [kik_conf_get_value()] no such key[sb_fg_color] in conf map. WARN: [kik_conf_get_value()] no such key[sb_bg_color] in conf map. WARN: [kik_conf_get_value()] no such key[termtype] in conf map. WARN: [kik_conf_get_value()] no such key[geometry] in conf map. WARN: [kik_conf_get_value()] no such key[screen_width_ratio] in conf map. WARN: [kik_conf_get_value()] no such key[screen_height_ratio] in conf map. WARN: [kik_conf_get_value()] no such key[use_multi_column_char] in conf map. WARN: [kik_conf_get_value()] no such key[line_space] in conf map. WARN: [kik_conf_get_value()] no such key[logsize] in conf map. WARN: [kik_conf_get_value()] no such key[tabsize] in conf map. WARN: [kik_conf_get_value()] no such key[use_login_shell] in conf map. WARN: [kik_conf_get_value()] no such key[big5_buggy] in conf map. WARN: [kik_conf_get_value()] no such key[use_scrollbar] in conf map. WARN: [kik_conf_get_value()] no such key[scrollbar_mode] in conf map. WARN: [kik_conf_get_value()] no such key[iso88591_font_for_usascii] in conf map. WARN: [kik_conf_get_value()] no such key[not_use_unicode_font] in conf map. WARN: [kik_conf_get_value()] no such key[only_use_unicode_font] in conf map. WARN: [kik_conf_get_value()] no such key[receive_string_via_ucs] in conf map. WARN: [kik_conf_get_value()] no such key[col_size_of_width_a] in conf map. WARN: [kik_conf_get_value()] no such key[wall_picture] in conf map. WARN: [kik_conf_get_value()] no such key[use_transbg] in conf map. WARN: [kik_conf_get_value()] no such key[brightness] in conf map. WARN: [kik_conf_get_value()] no such key[contrast] in conf map. WARN: [kik_conf_get_value()] no such key[gamma] in conf map. WARN: [kik_conf_get_value()] no such key[fade_ratio] in conf map. WARN: [kik_conf_get_value()] no such key[ENCODING] in conf map. WARN: [kik_conf_get_value()] no such key[xim_open_in_startup] in conf map. WARN: [kik_conf_get_value()] no such key[use_bidi] in conf map. WARN: [kik_conf_get_value()] no such key[mod_meta_key] in conf map. WARN: [kik_conf_get_value()] no such key[mod_meta_mode] in conf map. WARN: [kik_conf_get_value()] no such key[bel_mode] in conf map. WARN: [kik_conf_get_value()] no such key[use_vertical_cursor] in conf map. WARN: [kik_conf_get_value()] no such key[iscii_lang] in conf map. WARN: [kik_conf_get_value()] no such key[use_extended_scroll_shortcut] in conf map. WARN: [kik_conf_get_value()] no such key[exec_cmd] in conf map. WARN: [kik_conf_get_value()] no such key[icon_path] in conf map. WARN: [xim_server_instantiated()] new xim server is instantiated. DEBUG: X connection opened. WARN: [get_font()] font for id 62 was cached. Then, when I set "X Input Method" in menu to "none" leaving the "XIM locale" as "cs_CZ.ISO_8859-2" it writes: WARN: [read_conf()] /home/horcicka/.mlterm/xim couldn't be opened. WARN: [x_xim_get_style()] over the spot style not found. DEBUG: [sig_child()] SIG CHILD received. WARN: [create_xic()] XIC activated. Then, when I exit it writes: DEBUG: [sig_child()] SIG CHILD received. WARN: [x_xic_deactivate()] XIC deactivated. DEBUG: X connection closed. But there is no change in relation to dead keys. Martin |
|
From: MINAMI H. <mi...@ch...> - 2002-12-02 13:41:38
|
On Mon, 2 Dec 2002 11:04:51 +0100 (CET)
Martin Horcicka <hor...@Fr...> wrote:
> Then, when I set "X Input Method" in menu to "none" leaving the "XIM locale"
> as "cs_CZ.ISO_8859-2" it writes:
>
> WARN: [read_conf()] /home/horcicka/.mlterm/xim couldn't be opened.
> WARN: [x_xim_get_style()] over the spot style not found.
> DEBUG: [sig_child()] SIG CHILD received.
> WARN: [create_xic()] XIC activated.
Would you apply following patch and seewhat happens when a dead key is pressed
under the configuration?
# I guess the same effect should also be achieved by adding
# none=cs_CZ.ISO-8859-2
# to ~/.mlterm/xim .
regards,
minami
--- x_xic.c 14 May 2002 12:05:27 -0000 1.1
+++ x_xic.c 2 Dec 2002 13:19:23 -0000
@@ -482,6 +482,16 @@
if( ( len = XmbLookupString( win->xic->ic , event , seq , seq_len , keysym , &stat)) == 0)
{
+ switch( stat){
+ case XLookupNone :
+ kik_debug_printf( KIK_DEBUG_TAG "XLookupNone\n");
+ break;
+ case XLookupKeySym:
+ kik_debug_printf( KIK_DEBUG_TAG "XLookupKeysym: %s\n", XKeysymToString(*keysym) );
+ break;
+ default:
+ kik_debug_printf( KIK_DEBUG_TAG "this shouldn't happen\n");
+ }
return 0 ;
}
|
|
From: Martin H. <hor...@Fr...> - 2002-12-02 14:10:01
|
MINAMI Hirokazu (2002-12-02 22:41 +0900):
> Would you apply following patch and seewhat happens when a dead key is
> pressed under the configuration?
> --- x_xic.c 14 May 2002 12:05:27 -0000 1.1
> +++ x_xic.c 2 Dec 2002 13:19:23 -0000
> @@ -482,6 +482,16 @@
>
> if( ( len = XmbLookupString( win->xic->ic , event , seq , seq_len , keysym , &stat)) == 0)
> {
> + switch( stat){
> + case XLookupNone :
> + kik_debug_printf( KIK_DEBUG_TAG "XLookupNone\n");
> + break;
> + case XLookupKeySym:
> + kik_debug_printf( KIK_DEBUG_TAG "XLookupKeysym: %s\n", XKeysymToString(*keysym) );
> + break;
> + default:
> + kik_debug_printf( KIK_DEBUG_TAG "this shouldn't happen\n");
> + }
> return 0 ;
> }
It writes e.g.:
DEBUG: [x_xic_get_str()]XLookupKeysym: dead_acute
DEBUG: [x_xic_get_str()]XLookupKeysym: Shift_L
DEBUG: [x_xic_get_str()]XLookupKeysym: dead_caron
Martin
|
|
From: MINAMI <mi...@ch...> - 2002-12-02 15:11:07
|
On Mon, 2 Dec 2002 15:09:37 +0100 (CET) Martin Horcicka <hor...@Fr...> wrote: > MINAMI Hirokazu (2002-12-02 22:41 +0900): > > > Would you apply following patch and seewhat happens when a dead key is > > pressed under the configuration? > It writes e.g.: > > DEBUG: [x_xic_get_str()]XLookupKeysym: dead_acute > DEBUG: [x_xic_get_str()]XLookupKeysym: Shift_L > DEBUG: [x_xic_get_str()]XLookupKeysym: dead_caron Now I understand what's going on. Thanks a lot. As far as I know, when XmbLookupString returns unknown keysym (in this case "XK_dead_XXX"), mlterm simply ignore the input and I guess that's a problem. However, to handle various accents, mlterm need to know how to compose a accent and a letter into accented letter. The XFree86's xterm seems to contain a large table forconversion from keysym to unicode. But it's a hack and I have to think a bit. There must be some more cleaner approach... regards, minami |
|
From: Martin H. <hor...@Fr...> - 2002-12-02 15:21:56
|
MINAMI (2002-12-03 00:11 +0900): > Now I understand what's going on. Thanks a lot. > > As far as I know, when XmbLookupString returns unknown keysym > (in this case "XK_dead_XXX"), mlterm simply ignore the input > and I guess that's a problem. > > However, to handle various accents, mlterm need to know how to compose > a accent and a letter into accented letter. > > The XFree86's xterm seems to contain a large table forconversion > from keysym to unicode. But it's a hack and I have to think a bit. > There must be some more cleaner approach... OK, I like your effort to keep the code clean. :-) Thanks for your time. Martin |
|
From: Ambrose Li <a....@ie...> - 2002-12-02 19:50:39
|
On Tue, Dec 03, 2002 at 12:11:00AM +0900, MINAMI wrote: > > The XFree86's xterm seems to contain a large table forconversion > from keysym to unicode. But it's a hack and I have to think a bit. > There must be some more cleaner approach... Sorry for not having done anything to debug the problem. In recent versions of X (at least XFree86 3.x/4.x), there are such information in /usr/X11R6/lib/X11/locale/*/Compose. Would there be any X call to get at this information? I suppose xterm uses hard-coded tables to accomodate old versions of X? -- Ambrose Li <a....@ie...> http://ada.dhs.org/~acli/cmcc/ http://www.cccgt.org/ DRM is theft - We are the stakeholders |
|
From: Araki K. <ara...@us...> - 2002-12-03 12:28:44
Attachments:
diff
|
Hi,
I looked over this thread finally:)
Subject: Re: [Mlterm-dev-en] Incorrect reaction to dead keys
From: MINAMI <mi...@ch...>
Message-ID: <200...@ch...>
Date: Tue, 3 Dec 2002 00:11:00 +0900
> As far as I know, when XmbLookupString returns unknown keysym
> (in this case "XK_dead_XXX"), mlterm simply ignore the input
> and I guess that's a problem.
Well, I suspect an attached patch will fix this problem.
Will you apply this patch, start mlterm with -X=false option, and
test if Multi_key or dead_key works fine or not?
Regards,
--
Araki Ken
ara...@us...
|
|
From: Martin H. <hor...@Fr...> - 2002-12-03 14:11:18
|
Araki Ken (2002-12-03 21:26 +0900): > Well, I suspect an attached patch will fix this problem. > > Will you apply this patch, start mlterm with -X=false option, and > test if Multi_key or dead_key works fine or not? No, it does not work. Martin |
|
From: Araki K. <ara...@us...> - 2002-12-06 10:50:18
Attachments:
diff
|
Hi,
I could finally fix this problem.
Please test an attached patch.
In my environment, it works as expected:)
Regards,
--
Araki Ken
ara...@us...
|
|
From: Araki K. <ara...@us...> - 2002-12-06 13:39:34
|
Hi,
Subject: Re: [Mlterm-dev-en] Incorrect reaction to dead keys
From: Araki Ken <ara...@us...>
Message-ID: <200...@pd...>
Date: Fri, 06 Dec 2002 19:48:06 +0900
> I could finally fix this problem.
> Please test an attached patch.
> In my environment, it works as expected:)
Please start mlterm as follows.
$ XMODIFIERS="@im=none" mlterm
Just to be sure...
Regards,
--
Araki Ken
ara...@us...
|
|
From: Martin H. <hor...@Fr...> - 2002-12-06 14:11:58
|
Araki Ken (2002-12-06 22:37 +0900): > > I could finally fix this problem. > > Please test an attached patch. > > In my environment, it works as expected:) > > Please start mlterm as follows. > > $ XMODIFIERS="@im=none" mlterm Yes, it works! Great! Thanks. :-) Martin |
|
From: Mike F. <mf...@su...> - 2002-12-06 17:07:05
|
Martin Horcicka <hor...@Fr...> さんは書きました:
> Araki Ken (2002-12-06 22:37 +0900):
>
>> > I could finally fix this problem.
>> > Please test an attached patch.
>> > In my environment, it works as expected:)
>>
>> Please start mlterm as follows.
>>
>> $ XMODIFIERS="@im=none" mlterm
>
> Yes, it works! Great!
Works for me with
LANG=en_US.UTF-8 XMODIFIERS="@im=none" mlterm
or
LANG=de_US.UTF-8 XMODIFIERS="@im=none" mlterm
but not with
LANG=ja_JP.UTF-8 XMODIFIERS="@im=none" mlterm
Why?
It doesn't seem to make a difference whether kinput2 is running
or not.
The "Compose" file and the XI18N_OBJS file for en_US.UTF-8 and
ja_JP.UTF-8 are identical:
mfabian@magellan:/usr/X11R6/lib/X11/locale$ diff en_US.UTF-8/Compose ja_JP.UTF-8/Compose
mfabian@magellan:/usr/X11R6/lib/X11/locale$ diff en_US.UTF-8/XI18N_OBJS ja_JP.UTF-8/XI18N_OBJS
mfabian@magellan:/usr/X11R6/lib/X11/locale$
de_DE.UTF-8 uses the same "Compose" file, because there is no
/usr/X11R6/lib/X11/locale/de_DE.UTF-8 sub-directory and de_DE.UTF-8
is just using the en_US.UTF-8 sub-directory:
mfabian@magellan:/usr/X11R6/lib/X11/locale$ grep -i de_DE.UTF-8 locale.dir
en_US.UTF-8/XLC_LOCALE de_DE.UTF-8
en_US.UTF-8/XLC_LOCALE: de_DE.UTF-8
You have new mail in /var/spool/mail/mfabian
mfabian@magellan:/usr/X11R6/lib/X11/locale$ grep -i de_DE.UTF-8 locale.alias
mfabian@magellan:/usr/X11R6/lib/X11/locale$
Shouldn't this work for ja_JP.UTF-8 as well when I set
XMODIFIERS="@im=none" and have a valid
/usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose file?
--
Mike Fabian <mf...@su...> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
|
|
From: Mike F. <mf...@su...> - 2003-01-20 17:06:12
Attachments:
mlterm-default-xim.patch
|
MINAMI <mi...@ch...> さんは書きました:
> On Thu, 28 Nov 2002 11:13:59 +0100 (CET)
> Martin Horcicka <hor...@Fr...> wrote:
>
>> no, it does not make any change. I've heard something about using
>> XmbLookupString rather than XLookupString in relation with this problem but I
>> am not X programmer. rxvt had this problem in the past and now it has not -
>> maybe it would be helpful to compare it's older and present sources.
>
> Thanks for your suggestion.
>
> The rxvt's cahngelog says
> If the user didn't specify an IM then we should still try to
> connect with "im=none" in case a base IM service is used for
> items like dead keys in single char glyph locales
I verified that dead keys and compose work fine now in mlterm-2.6.3
if XMODIFIERS="@im=none" or XMODIFIERS="@im=local". For example if
one calls mlterm like this:
LC_ALL=en_US.UTF-8 XMODIFIERS=@im=local mlterm
But if XMODIFIERS is unset, dead keys and compose still doesnt work,
i.e. after
unset XMODIFIERS
C_ALL=en_US.UTF-8 mlterm
dead keys won't work. Shouldn't the use of dead keys and compose be
the default if XMODIFIERS is unset or empty? The above comment from
rxvt's changelog seems to suggest this.
Attached is a small patch to use the input method "local" if
no other input method is specified:
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X