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

[Mlterm-dev-en] Re: mlterm will freeze if I switch scim-m17n engines

[Seiichi S. <ss...@sh...>]

On Wed, Jan 05, 2005 at 12:59:47AM +0900,
 UTUMI Hirosi wrote:

> SATO-san, Minami-san, what do you think about it?

I think that the problem happens in the event dispatcher
in scim_x11_frontend.cpp.
Could anybody try the attached patch?

--
Seiichi

Re: [Mlterm-dev-en] mlconfig crashes with current CVS head

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

MINAMI Hirokazu <mi...@mi...> さんは書きました:

> On Wed, 2005-01-05 at 19:28 +0100, Mike FABIAN wrote:
>> 1st crash:
>> ==========
>> 
>> If the plugin directory contains
>> 
>>     libim-kbd.so
>>     libim-kbd.a
>>     libim-kbd.la
>>     libim-uim.so
>>     libim-uim.a
>>     libim-uim.la
>> 
>> and not only the .so files, mlconfig will think the keyboard and uim
>> plugins exist 3 times and will paint 3 buttons for each. See this
>> screen shot:
>
> Please try the attached patch.
>
> #some explanations for it will follow if time permits, sorry...

Your patch seems to work fine. Thank you!

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: [Mlterm-dev-en] mlconfig crashes with current CVS head

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

On Wed, 2005-01-05 at 19:28 +0100, Mike FABIAN wrote:
> 1st crash:
> ==========
> 
> If the plugin directory contains
> 
>     libim-kbd.so
>     libim-kbd.a
>     libim-kbd.la
>     libim-uim.so
>     libim-uim.a
>     libim-uim.la
> 
> and not only the .so files, mlconfig will think the keyboard and uim
> plugins exist 3 times and will paint 3 buttons for each. See this
> screen shot:

Please try the attached patch.

#some explanations for it will follow if time permits, sorry...

--
minami

Re: [Mlterm-dev-en] mlconfig crashes with current CVS head

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

Mike FABIAN <mf...@su...> さんは書きました:

> 2nd crash:
> ==========
>
> If mlterm is started in de_DE.UTF-8 or en_US.UTF-8 locale and one
> tries to start mlconfig (Controll+RightMouse), mlconfig crashes.
>
> It works in ja_JP.UTF-8, zh_CN.UTF-8, ko_KR.UTF-8.
>
> I don't know for sure but I guess it crashes when no input plugins can
> be found for the language in the locale.

This appears to be an uim problem:

mfabian@magellan:~$ LANG=de_DE.UTF-8 uim-xim
UIM-XIM bridge. Now supporting multiple locales.
Using full-synchronous XIM event flow
Supported conversion engines:
  py (zh_CN)
  pyunihan (zh_CN)
  pinyin-big5 (zh_TW:zh_HK)
  anthy (ja)
  canna (ja)
  prime (ja)
  skk (ja)
  tcode (ja)
  tutcode (ja)
  hangul2 (ko)
  hangul3 (ko)
  romaja (ko)
  viqr (vi)
  ipa ()
  latin ()
  direct ()
セグメンテーション違反です (core dumped)
mfabian@magellan:~$ rpm -q uim
uim-0.4.5svn1650-4
mfabian@magellan:~$

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

[Mlterm-dev-en] mlconfig crashes with current CVS head

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

1st crash:
==========

If the plugin directory contains

    libim-kbd.so
    libim-kbd.a
    libim-kbd.la
    libim-uim.so
    libim-uim.a
    libim-uim.la

and not only the .so files, mlconfig will think the keyboard and uim
plugins exist 3 times and will paint 3 buttons for each. See this
screen shot:

http://www.suse.de/~mfabian/misc/mlterm-20050105/duplicated-radio-buttons.png

Because of 

    #define MAX_IM_INFO 5

    [...]

    static im_info_t *im_info_table[MAX_IM_INFO];

in mc_im.c, the im_info_table will be to short in that case
and mlconfig will crash if the rightmost of the 6 buttons is clicked.

One should probably not install the .a and .la files for the plugins
anyway, therefore I worked around this problem by deleting them in my
mlterm.spec file.

Nevertheless it would probably be a good idea to skip the .la and .a
files in function get_im_info() in mc_im.c.

2nd crash:
==========

If mlterm is started in de_DE.UTF-8 or en_US.UTF-8 locale and one
tries to start mlconfig (Controll+RightMouse), mlconfig crashes.

It works in ja_JP.UTF-8, zh_CN.UTF-8, ko_KR.UTF-8.

I don't know for sure but I guess it crashes when no input plugins can
be found for the language in the locale.

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

[Mlterm-dev-en] Re: mlterm will freeze if I switch scim-m17n engines

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

Zhe Su <jam...@gm...> さんは書きました:

>   I can not reproduct such freezing issue in SL9.2 & KDE. Could you
> please tell me how to reproduct it?

Actually I don't have to do anything special. Just switch input
methods a few times and it should happen. For me it happens almost
always when switching to another input method and I have to unfreeze
mlterm by clicking on an xterm. But there are rare cases when mlterm
does *not* freeze for some reason. So please try to switch the input
methods several times.

At first I thought it happens only with focus follows mouse. But that
is not the case, it happens with all focus policies. And it doesn't
seem to depend on the window manager either. Currently I am using fvwm
but it happens as well when I use KDE.

Then I suspected that it depends on the speed of the machine but that
doesn't seem to be right either. It happens on my fastest and on my
slowest machine equally often.

And it happens on i386 as well as on x86_64 (and most likely on all
other platforms as well).

I use ja_JP.UTF-8, but that doesn't seem to matter either, it happens
in other UTF-8 locales as well.

> On Tue, 04 Jan 2005 17:21:45 +0100, Mike FABIAN <mf...@su...> wrote:
>> UTUMI Hirosi <utu...@ya...> さんは書きました:
>> 
>> > Hi Mike,
>> >
>> > I found it in November 2004, but I'm using many unstable packages,
>> > so I couldn't believe it.
>> > Now I can believe it. :-)
>> >
>> > SATO-san, Minami-san, what do you think about it?
>> 
>> Maybe it is an SCIM bug.
>> 
>> But it could also be an mlterm bug because I don't know any other
>> application which shows this behavior when using SCIM.
>> 
>> > Thank you so much.
>> > Hirosi
>> >
>> > -------
>> > http://lists.freedesktop.org/pipermail/scim/2005-January/001408.html
>> > UTUMI Hirosi <utu...@ya...> さんは書きました:
>> >
>> >> If I switch scim-m17n engines on mlterm, mlterm will freeze.
>> >> $ mlterm
>> >> // in mlterm
>> >> Press Ctrl+space
>> >> Choose M17N-ja-anthy
>> >> Type some words => You can type them
>> >> Choose M17N-zh-py
>> >> Type some words => You can't type any words
>> >>
>> >> Does it work for you?
>> >
>> > I have the same problem already since spring 2004.  This is
>> > *extremely* annoying because I use mlterm all the time.
>> >
>> > As a workaround I found that I can "unfreeze" mlterm again by focusing
>> > another application using SCIM via XIM, for example xterm and moving
>> > the focus back to mlterm.
>> >
>> >> I can switch them if I use UIM.
>> >> scim-m17n works fine with other XIM apps.
>> >>
>> >> I'm using them:
>> >> mlterm-cvs-20041229
>> >> scim-cvs20050103
>> >> scim-m17n-cvs20050103
>> >> anthy-6024
>> >> libgtk+-2.6.0
>> >
>> > I am currently using
>> >
>> > mlterm-cvs-20040906 (a lot older then your version) and
>> > scim-1.0.2.
>> >
>> > I don't think the versions of the other packages like scim-m17n and
>> > anthy matter because this problem happens with all input methods
>> > supported by SCIM.
>> >
>> >
>> > __________________________________
>> > Do You Yahoo!?
>> > Upgrade Your Life
>> > http://bb.yahoo.co.jp/
>> >
>> 
>> --
>> Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
>> 睡眠不足はいい仕事の敵だ。
>> _______________________________________________
>> scim mailing list
>> sc...@li...
>> http://lists.freedesktop.org/mailman/listinfo/scim
>>
> _______________________________________________
> scim mailing list
> sc...@li...
> http://lists.freedesktop.org/mailman/listinfo/scim
>

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

[Mlterm-dev-en] Re: [SCIM] Re: mlterm will freeze if I switch scim-m17n engines

[UTUMI H. <utu...@ya...>]

Hi,

--- Zhe Su <jam...@gm...> wrote:
>  I can not reproduct such freezing issue in SL9.2 & KDE. Could you
> please tell me how to reproduct it?

It happens at random.
Choose M17N-zh-py and type "nihaoma" => choose scim-anthy and type "konnichiha" =>
choose M17N-zh-py and type "nihaoma" => choose M17N-ja-anthy and type "konnichiha" =>
choose scim-anthy and type "konnichiha" => ...

I'm using pekwm. Also I tested it on KDE-3.3.2 but still it freezes.

Thanks.
Hirosi


__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/

[Mlterm-dev-en] Re: [SCIM] Re: mlterm will freeze if I switch scim-m17n engines

[Zhe Su <jam...@gm...>]

Hi,
  I can not reproduct such freezing issue in SL9.2 & KDE. Could you
please tell me how to reproduct it?

Regards
James Su


On Tue, 04 Jan 2005 17:21:45 +0100, Mike FABIAN <mf...@su...> wrote:
> UTUMI Hirosi <utu...@ya...> =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=
=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:
>=20
> > Hi Mike,
> >
> > I found it in November 2004, but I'm using many unstable packages,
> > so I couldn't believe it.
> > Now I can believe it. :-)
> >
> > SATO-san, Minami-san, what do you think about it?
>=20
> Maybe it is an SCIM bug.
>=20
> But it could also be an mlterm bug because I don't know any other
> application which shows this behavior when using SCIM.
>=20
> > Thank you so much.
> > Hirosi
> >
> > -------
> > http://lists.freedesktop.org/pipermail/scim/2005-January/001408.html
> > UTUMI Hirosi <utu...@ya...> =E3=81=95=E3=82=93=E3=81=AF=E6=9B=
=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:
> >
> >> If I switch scim-m17n engines on mlterm, mlterm will freeze.
> >> $ mlterm
> >> // in mlterm
> >> Press Ctrl+space
> >> Choose M17N-ja-anthy
> >> Type some words =3D> You can type them
> >> Choose M17N-zh-py
> >> Type some words =3D> You can't type any words
> >>
> >> Does it work for you?
> >
> > I have the same problem already since spring 2004.  This is
> > *extremely* annoying because I use mlterm all the time.
> >
> > As a workaround I found that I can "unfreeze" mlterm again by focusing
> > another application using SCIM via XIM, for example xterm and moving
> > the focus back to mlterm.
> >
> >> I can switch them if I use UIM.
> >> scim-m17n works fine with other XIM apps.
> >>
> >> I'm using them:
> >> mlterm-cvs-20041229
> >> scim-cvs20050103
> >> scim-m17n-cvs20050103
> >> anthy-6024
> >> libgtk+-2.6.0
> >
> > I am currently using
> >
> > mlterm-cvs-20040906 (a lot older then your version) and
> > scim-1.0.2.
> >
> > I don't think the versions of the other packages like scim-m17n and
> > anthy matter because this problem happens with all input methods
> > supported by SCIM.
> >
> >
> > __________________________________
> > Do You Yahoo!?
> > Upgrade Your Life
> > http://bb.yahoo.co.jp/
> >
>=20
> --
> Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
> =E7=9D=A1=E7=9C=A0=E4=B8=8D=E8=B6=B3=E3=81=AF=E3=81=84=E3=81=84=E4=BB=95=
=E4=BA=8B=E3=81=AE=E6=95=B5=E3=81=A0=E3=80=82
> _______________________________________________
> scim mailing list
> sc...@li...
> http://lists.freedesktop.org/mailman/listinfo/scim
>

[Mlterm-dev-en] Re: mlterm will freeze if I switch scim-m17n engines

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

UTUMI Hirosi <utu...@ya...> さんは書きました:

> Hi Mike,
>
> I found it in November 2004, but I'm using many unstable packages,
> so I couldn't believe it.
> Now I can believe it. :-)
>
> SATO-san, Minami-san, what do you think about it?

Maybe it is an SCIM bug.

But it could also be an mlterm bug because I don't know any other
application which shows this behavior when using SCIM.

> Thank you so much.
> Hirosi
>
> -------
> http://lists.freedesktop.org/pipermail/scim/2005-January/001408.html
> UTUMI Hirosi <utu...@ya...> さんは書きました:
>
>> If I switch scim-m17n engines on mlterm, mlterm will freeze.
>> $ mlterm
>> // in mlterm
>> Press Ctrl+space
>> Choose M17N-ja-anthy
>> Type some words => You can type them
>> Choose M17N-zh-py
>> Type some words => You can't type any words
>>
>> Does it work for you?
>
> I have the same problem already since spring 2004.  This is
> *extremely* annoying because I use mlterm all the time.
>
> As a workaround I found that I can "unfreeze" mlterm again by focusing
> another application using SCIM via XIM, for example xterm and moving
> the focus back to mlterm.
>
>> I can switch them if I use UIM.
>> scim-m17n works fine with other XIM apps.
>>
>> I'm using them:
>> mlterm-cvs-20041229
>> scim-cvs20050103
>> scim-m17n-cvs20050103
>> anthy-6024
>> libgtk+-2.6.0
>
> I am currently using
>
> mlterm-cvs-20040906 (a lot older then your version) and
> scim-1.0.2.
>
> I don't think the versions of the other packages like scim-m17n and
> anthy matter because this problem happens with all input methods
> supported by SCIM.
>
>
> __________________________________
> Do You Yahoo!?
> Upgrade Your Life
> http://bb.yahoo.co.jp/
>

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

[Mlterm-dev-en] Re: mlterm will freeze if I switch scim-m17n engines

[UTUMI H. <utu...@ya...>]

Hi Mike,

I found it in November 2004, but I'm using many unstable packages,
so I couldn't believe it.
Now I can believe it. :-)

SATO-san, Minami-san, what do you think about it?

Thank you so much.
Hirosi

-------
http://lists.freedesktop.org/pipermail/scim/2005-January/001408.html
UTUMI Hirosi <utu...@ya...> さんは書きました:

> If I switch scim-m17n engines on mlterm, mlterm will freeze.
> $ mlterm
> // in mlterm
> Press Ctrl+space
> Choose M17N-ja-anthy
> Type some words => You can type them
> Choose M17N-zh-py
> Type some words => You can't type any words
>
> Does it work for you?

I have the same problem already since spring 2004.  This is
*extremely* annoying because I use mlterm all the time.

As a workaround I found that I can "unfreeze" mlterm again by focusing
another application using SCIM via XIM, for example xterm and moving
the focus back to mlterm.

> I can switch them if I use UIM.
> scim-m17n works fine with other XIM apps.
>
> I'm using them:
> mlterm-cvs-20041229
> scim-cvs20050103
> scim-m17n-cvs20050103
> anthy-6024
> libgtk+-2.6.0

I am currently using

mlterm-cvs-20040906 (a lot older then your version) and
scim-1.0.2.

I don't think the versions of the other packages like scim-m17n and
anthy matter because this problem happens with all input methods
supported by SCIM.


__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

[Ian W. <ia...@ex...>]

On Tue, Jan 04, 2005 at 11:49:21AM +0900, MINAMI Hirokazu wrote:
> On Sun, 2005-01-02 at 01:16 -0500, Ian Ward wrote:
> 
> > xterm always flips the foreground and background colors of the character
> > the cursor is on (white on blue becomes blue on white etc.)  rxvt uses
> > black on white if the background of the character the cursor is on is
> > black, otherwise it uses white on black.
> 
> I've prepared a patch for the xterm-like scheme (attached).
> i.e. make cursor's fg/bg color be taken from the character under cursor.

Thanks! I will try it soon.

> > BTW, I'm hoping to add support for all mlterm's supported encodings to
> > Urwid (http://excess.org/urwid/).  Can you recommend any good texts that
> > I may use as a reference?  At the moment I am using:
> > http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html
> 
> Sorry, I couldn't find the better one.
> 
> Just curious: what function are you going to add? 
> I'm assuming that the knowledge of encoding should not
> be neccesary to simply display some strings.

I need to know the encoding for things like word wrapping and cursor
movement in edit boxes (sometimes the cursor should move 2 spaces).  I
will also have to know how the terminal will behave when I send it
combining characters and BiDi text.  I don't support BiDi yet -- That
will be an interesting challenge.

Ian

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

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

On Sun, 2005-01-02 at 17:33 +0100, Mike FABIAN wrote:
> Ambrose Li <ac...@ad...> さんは書きました:
> 
> > Old versions of xterm and rxvt both can have the invisible
> > cursor problem, but can be worked around because they accept a
> > command-line option to set the cursor colour (I usually set it
> > to orange or other equally improbable colour). I don't think
> > this is possible with mlterm.
> 
> You can set the cursor colour in mlterm as well, either with
> command line options or in ~/.mlterm/main:
> 
> mike@kibou:~$ grep cursor  .mlterm/main
> cursor_fg_color=white
> cursor_bg_color=blue
> mike@kibou:~$


The cursor color can be also configured dynamically -- 
though it's not accessible from GUI configuration helper.

If you have recent version of "mlcc", you can do
 $ mlcc cursor_bg_color orange
to make your cursor orange and
 $ mlcc cursor_bg_color none
to revert to the default.
(or, if you really want, you can send a escape sequence by hand.
see mlterm/doc/en/PROTOCOLS) 

--
minami

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

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

On Sun, 2005-01-02 at 01:16 -0500, Ian Ward wrote:

> xterm always flips the foreground and background colors of the character
> the cursor is on (white on blue becomes blue on white etc.)  rxvt uses
> black on white if the background of the character the cursor is on is
> black, otherwise it uses white on black.

I've prepared a patch for the xterm-like scheme (attached).
i.e. make cursor's fg/bg color be taken from the character under cursor.

When cursor's fg/bg color was specified in your config file or
by a command line option, Those color would be used as they had been.

Though cursor would be remain invisible in a sick situation
(like the "black on black" case), it seems acceptable for me.
  
> BTW, I'm hoping to add support for all mlterm's supported encodings to
> Urwid (http://excess.org/urwid/).  Can you recommend any good texts that
> I may use as a reference?  At the moment I am using:
> http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html

Sorry, I couldn't find the better one.

Just curious: what function are you going to add? 
I'm assuming that the knowledge of encoding should not
be neccesary to simply display some strings.

--
minami

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

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

Ambrose Li <ac...@ad...> さんは書きました:

> Old versions of xterm and rxvt both can have the invisible
> cursor problem, but can be worked around because they accept a
> command-line option to set the cursor colour (I usually set it
> to orange or other equally improbable colour). I don't think
> this is possible with mlterm.

You can set the cursor colour in mlterm as well, either with
command line options or in ~/.mlterm/main:

mike@kibou:~$ grep cursor  .mlterm/main
cursor_fg_color=white
cursor_bg_color=blue
mike@kibou:~$

-- 
Mike FABIAN   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

[Ambrose Li <ac...@ad...>]

On Sun, Jan 02, 2005 at 01:16:24AM -0500, Ian Ward wrote:

> xterm always flips the foreground and background colors of
> the character the cursor is on (white on blue becomes blue on
> white etc.) rxvt uses black on white if the background of the
> character the cursor is on is black, otherwise it uses white
> on black.

Old versions of xterm and rxvt both can have the invisible
cursor problem, but can be worked around because they accept a
command-line option to set the cursor colour (I usually set it
to orange or other equally improbable colour). I don't think
this is possible with mlterm.

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

[Ian W. <ia...@ex...>]

On Sun, 2005-02-01 at 13:44 +0900, MINAMI Hirokazu wrote:
> I've tried your script on the default setting
> and on "mlterm -f white -b black".
> 
> When default color (black on white) is used, the cursor couldn't
> be seen because it's rendered by black on black background. 
> In the latter case (white on black), I could see white rectangle.
> These result seems to be identical to xterm/rxvt.
> 
> Are you requesting to draw cursor differently to be always visible?
> I'm afraid it may rather annoying in some cases.

xterm always flips the foreground and background colors of the character
the cursor is on (white on blue becomes blue on white etc.)  rxvt uses
black on white if the background of the character the cursor is on is
black, otherwise it uses white on black.

I don't want to tell people "Never use a black background because mlterm
users won't be able to see the cursor".  I'm sorry if this is annoying.

Ian

BTW, I'm hoping to add support for all mlterm's supported encodings to
Urwid (http://excess.org/urwid/).  Can you recommend any good texts that
I may use as a reference?  At the moment I am using:
http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

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

On Sat, 2005-01-01 at 20:57 -0500, Ian Ward wrote:
> On Sun, 2005-02-01 at 09:58 +0900, MINAMI Hirokazu wrote:
> > I couldn't find a demo that uses "start_color" under
> > python2.3-2.3.4/Demo/curses and not sure what the problem is.
> > Could you prepare some tiny test case?
> 
> Ah, you're right.  The demos call curses.wrapper, which calls
> start_color for color terminals.
> 
> Here is a test case:
...

I've tried your script on the default setting
and on "mlterm -f white -b black".

When default color (black on white) is used, the cursor couldn't
be seen because it's rendered by black on black background. 
In the latter case (white on black), I could see white rectangle.
These result seems to be identical to xterm/rxvt.

Are you requesting to draw cursor differently to be always visible?
I'm afraid it may rather annoying in some cases.

> Without start_color the cursor is visible.
> 
> > BTW, cursor state(invis/norm) currently doesn't save/restored
> >  and are sheared between normal/alternate screen.
> > Are they intentional ?> Sato san
> 
> I'm not sure what you mean by "intentional".  Would you rephrase the
> question?

Don't mind. In this case, as far as cursor visibility is not touched,
It shouldn't matter anyway. 

minami 
 

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

[Ian W. <ia...@ex...>]

On Sun, 2005-02-01 at 09:58 +0900, MINAMI Hirokazu wrote:
> I couldn't find a demo that uses "start_color" under
> python2.3-2.3.4/Demo/curses and not sure what the problem is.
> Could you prepare some tiny test case?

Ah, you're right.  The demos call curses.wrapper, which calls
start_color for color terminals.

Here is a test case:

-----------------------
#!/usr/bin/python

import curses
import sys
s = curses.initscr()
curses.start_color()
s.addstr("No cursor")
s.refresh()
sys.stdin.read(1)
curses.endwin()
-----------------------

Without start_color the cursor is visible.

> BTW, cursor state(invis/norm) currently doesn't save/restored
>  and are sheared between normal/alternate screen.
> Are they intentional ?> Sato san

I'm not sure what you mean by "intentional".  Would you rephrase the
question?

Ian

Re: [Mlterm-dev-en] Invisible cursor with python curses module and start_color

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

On Sat, 2005-01-01 at 16:48 -0500, Ian Ward wrote:
> I'm developing a curses-based UI library for python
> (http://excess.org/urwid/) and I've noticed that when I call start_color
> the cursor in mlterm becomes invisible.  Calling curs_set to enable the
> cursor doesn't have any effect.
...
> I'm running Debian Sid and I've tested with mlterm 2.8.0 and 2.9.1, and
> python 2.1 and 2.3.

In the days of 2.8.0, mlterm did not support changing 
cursor visibility and curs_set should have no effect on it.

After 2.9.0, or 2004/05 in CVS, that should work. i.e.
  echo -e "\033[?25l" 
 or 
  tput civis
makes cursor invisible and
  echo -e "\033[?25h"
 or
  tput cnorm
reverts it.

So your problem occurs both of them,
it seems to be in the color for drawing cursor
not in the cursor state.

I couldn't find a demo that uses "start_color" under
python2.3-2.3.4/Demo/curses and not sure what the problem is.
Could you prepare some tiny test case?



BTW, cursor state(invis/norm) currently doesn't save/restored
 and are sheared between normal/alternate screen.
Are they intentional ?> Sato san

regards,
--
minami <mi...@mi...>

[Mlterm-dev-en] Invisible cursor with python curses module and start_color

[Ian W. <ia...@ex...>]

I'm developing a curses-based UI library for python
(http://excess.org/urwid/) and I've noticed that when I call start_color
the cursor in mlterm becomes invisible.  Calling curs_set to enable the
cursor doesn't have any effect.

The same thing happens with the curses demos included in the python
package (found under examples/Demo/curses). Demos that use start_color
have an invisible cursor.

I'm running Debian Sid and I've tested with mlterm 2.8.0 and 2.9.1, and
python 2.1 and 2.3.

Any ideas?

Re: [Mlterm-dev-en] m17n-lib ver.1.2.0 is released

[Seiichi S. <ss...@sh...>]

On Tue, Dec 28, 2004 at 05:32:19PM +0900,
 Kenichi Handa wrote:

> I tried them with the latest CVS mlterm and found one
> problem.  The attached patch is necessary for configuire.in
> to find m17n-lib installed only in /usr/local/lib.

Applied. Thanks a lot.

--
Seiichi

[Mlterm-dev-en] m17n-lib ver.1.2.0 is released

[Kenichi H. <ha...@m1...>]

We have just released the version 1.2.0 of m17n-lib and
m17n-db.

I tried them with the latest CVS mlterm and found one
problem.  The attached patch is necessary for configuire.in
to find m17n-lib installed only in /usr/local/lib.

---
Ken'ichi HANDA
ha...@m1...

*** configure.in	28 Dec 2004 14:33:59 +0900	1.72
--- configure.in	28 Dec 2004 16:54:50 +0900	
***************
*** 423,437 ****
  	[  --enable-m17nlib        m17n library (Experimental) [default=disabled]],
  	m17nlib=$enable_m17nlib)
  if test "x$m17nlib" = xyes ; then
  	AC_CHECK_LIB(m17n, minput_open_im,
  		[
  		IM_CFLAGS="$IM_CFLAGS -DUSE_M17NLIB"
  		M17NLIB_CFLAGS="`m17n-config --cflags`"
- 		M17NLIB_LIBS=`m17n-config --libs`
  		MAKE_DIRS="inputmethod/m17nlib ${MAKE_DIRS}"
  		OUTPUT_FILES="inputmethod/m17nlib/Makefile ${OUTPUT_FILES}"
  		input_methods_result="$input_methods_result m17nlib"
  		])
  fi
  AC_SUBST(M17NLIB_CFLAGS)
  AC_SUBST(M17NLIB_LIBS)
--- 423,443 ----
  	[  --enable-m17nlib        m17n library (Experimental) [default=disabled]],
  	m17nlib=$enable_m17nlib)
  if test "x$m17nlib" = xyes ; then
+ 	AC_CHECK_PROG(m17nlib, m17n-config, yes, no)
+ fi
+ if test "x$m17nlib" = xyes ; then
+ 	m17n_saved_libs="$LIBS"
+ 	M17NLIB_LIBS=`m17n-config --libs`
+ 	LIBS="$LIBS $M17NLIB_LIBS"
  	AC_CHECK_LIB(m17n, minput_open_im,
  		[
  		IM_CFLAGS="$IM_CFLAGS -DUSE_M17NLIB"
  		M17NLIB_CFLAGS="`m17n-config --cflags`"
  		MAKE_DIRS="inputmethod/m17nlib ${MAKE_DIRS}"
  		OUTPUT_FILES="inputmethod/m17nlib/Makefile ${OUTPUT_FILES}"
  		input_methods_result="$input_methods_result m17nlib"
  		])
+ 	LIBS="$m17n_saved_libs"
  fi
  AC_SUBST(M17NLIB_CFLAGS)
  AC_SUBST(M17NLIB_LIBS)

Re: [Mlterm-dev-en] A few questions.

[Seiichi S. <ss...@sh...>]

On Sun, Nov 28, 2004 at 02:16:22PM +0900,
 Seiichi SATO wrote:

> termcap:
> http://www.sh.rim.or.jp/~ssato/mlterm/mlterm.tc
> $ cat mlterm.tc >> ~/.termcap

$ cat mlterm.tc >> /etc/termcap

-- 
Seiichi

Re: [Mlterm-dev-en] Now mlconfig works fine with m17n-lib-cvs

[Seiichi S. <ss...@sh...>]

Hi,

On Fri, Nov 26, 2004 at 04:15:32PM +0900,
 UTUMI Hirosi wrote:

> I've tested mlterm-cvs20041125 with m17n-lib-cvs-20041126.
> mlconfig is working fine now. :-)

closed #1061554.

> I packed them for Mandrake Cooker:
> http://sourceforge.net/project/showfiles.php?group_id=109779&package_id=131210
> http://sourceforge.net/project/showfiles.php?group_id=109779&package_id=118931

Thanks.

> // btw, what do you think about SCIM?

I think SCIM is useful for Chinese and Koren speakers.
Speially, pinyin based scim-chinese is a sensible input method.

> // Will mltem support SCIM?

Probably, yes.

-- 
Seiichi

Re: [Mlterm-dev-en] mlterm-2.9.0, UTF-8 and Norwegian Characters

[Seiichi S. <ss...@sh...>]

On Mon, Nov 22, 2004 at 10:19:01PM +0100,
 Esben Stien wrote:

> Anyone have any idea what happends here?.

Please try to set XMODIFIERS environment variable as:

  $ XMODIFIERS="@im=none" mlterm


-- 
Seiichi