mlterm-dev-en — mlterm mailing list(English)

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Mike F. <mf...@su...>]

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
睡眠不足はいい仕事の敵だ。

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <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!

Thanks. :-)

Martin

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Araki K. <ara...@us...>]

	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...

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Araki K. <ara...@us...>]

	Hi,

        I could finally fix this problem.
        Please test an attached patch.
        In my environment, it works as expected:)

        Regards,
	
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Araki K. <ara...@us...>]

	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...

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Ambrose Li <a....@ie...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[MINAMI <mi...@ch...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[MINAMI H. <mi...@ch...>]

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 ;
        }

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[MINAMI <mi...@ch...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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 ;
>

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Jari P.T. A. <jar...@he...>]

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

[Mlterm-dev-en] ¯Â°Ó·~¿ì¤½«Ç¥X¯²

[<vcb...@sh...>]

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[MINAMI H. <mi...@ch...>]

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 ;
 }

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[Jari P.T. A. <jar...@he...>]

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

Re: [Mlterm-dev-en] Incorrect reaction to dead keys

[MINAMI H. <mi...@ch...>]

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 ;

[Mlterm-dev-en] Incorrect reaction to dead keys

[Martin H. <hor...@Fr...>]

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

[Mlterm-dev-en] Re: mlterm: GBK parser should not discard both characters when the second is out of range

[Wang W. <wa...@ma...>]

Hi,

After read your email I found the situation in my bugreport is caused by
mistake. In fact my mlterm load the .so library I've compiled before. So
it is my fault. I feel sorry brought you troubles and would be careful
next time. :)

Regards,
Wang WenRui

Araki Ken wrote:

>	Hi,
>
>        I'm the author of mlterm, and always thank for your contributions:)
>        I'm very sorry I didn't respond your mail 'mlterm-2.6.1.cvs20020927.gbk_second_char.patch'
>        is attached to, I was very busy in those days.
>
>        Now, I received your new patch(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169575).
>        But if mkf_parser_reset() is not called before return 0, the second
>        byte is not discarded, on the contrary, if mkf_parser_reset() is called in such
>        a situation, it can fall into infinite loop, though ml_parse_vt100_sequence() in
>        ml_vt100_parser.c contains a hack to avoid it.
>        
>        Actually, in my environment, I tested as follows.
>
>$ echo -e "\xbf\x1b[32m\xbf a"
> a
>$
>
>        If the second byte which is out of range were discarded, '[32m a' should
>        be echoed.
>
>        So, I suspect the second byte is lost in another context.
>
>        Well, will you give me some more hints of this bug, in that, how to
>        reproduce it.
>        Of cource, something like a log file logged by 'screen' command is
>        very welcomed:)
>
>        Regards,
>
>--
>Araki Ken
>ara...@us...
>
>
>  
>

Re: [Mlterm-dev-en] My dead accents are alive!

[MINAMI H. <mi...@ch...>]

On Wed, 30 Oct 2002 01:12:39 -0500
Ambrose Li <a....@ie...> wrote:

> On Wed, Oct 30, 2002 at 01:14:12PM +0900, MINAMI Hirokazu wrote:
> > 
> > What locale are you using?
> > 
> > It seems that XOpenIM() always fails under "xx_XX.UFT8" locale
> > regardless of modifier setting...
> 
> I tried with en_CA.ISO8859-1 and fi_FI.ISO8859-1 on two different
> machines.

In my environment(XF86 4.2.1 + glibc 2.3.1), when mlterm is invoked as
 XMODIFIERS=@im=none LANG=en_CA.ISO-8859-1 mlterm
, X's keypress events seems to be processed using XmbLookupString().

Would you confirm whether x_xic_get_str() returns non-zero
in x_window.c:x_window_get_str()?

Re: [Mlterm-dev-en] My dead accents are alive!

[Ambrose Li <a....@ie...>]

On Wed, Oct 30, 2002 at 01:14:12PM +0900, MINAMI Hirokazu wrote:
> 
> What locale are you using?
> 
> It seems that XOpenIM() always fails under "xx_XX.UFT8" locale
> regardless of modifier setting...

I tried with en_CA.ISO8859-1 and fi_FI.ISO8859-1 on two different
machines.


-- 
Ambrose Li  <a....@ie...>
http://www.netwinder.org/~acli/  http://www.cccgt.org/

DRM is theft - We are the stakeholders

Re: [Mlterm-dev-en] My dead accents are alive!

[MINAMI H. <mi...@ch...>]

On Tue, 29 Oct 2002 11:49:20 -0500
"Ambrose Li [CCCGT]" <ac...@cc...> wrote:

> On Tue, Oct 29, 2002 at 12:12:53AM +0900, MINAMI Hirokazu wrote:
> > 
> > What happens if you do
> >  XMODIFIERS=@im=none mlterm
> > ?
> 
> It doesn't seem to make a difference :-(

What locale are you using?

It seems that XOpenIM() always fails under "xx_XX.UFT8" locale
regardless of modifier setting...

Re: [Mlterm-dev-en] My dead accents are alive!

[Ambrose Li [CCCGT] <ac...@cc...>]

On Tue, Oct 29, 2002 at 12:12:53AM +0900, MINAMI Hirokazu wrote:
> 
> What happens if you do
>  XMODIFIERS=@im=none mlterm
> ?

It doesn't seem to make a difference :-(

-- 
Ambrose Li

``A good style should show no sign of effort;
  what is written should seem a happy accident.'' ~ Somerset Maugham