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