| … | |
… | |
| 582 | <dd> |
582 | <dd> |
| 583 | <p>Now you can start your terminal with <code>LC_CTYPE=ja_JP.UTF-8</code> and still |
583 | <p>Now you can start your terminal with <code>LC_CTYPE=ja_JP.UTF-8</code> and still |
| 584 | use your input method. Please note, however, that you will not be able to |
584 | use your input method. Please note, however, that you will not be able to |
| 585 | input characters outside <code>EUC-JP</code> in a normal way then, as your input |
585 | input characters outside <code>EUC-JP</code> in a normal way then, as your input |
| 586 | method limits you.</p> |
586 | method limits you.</p> |
|
|
587 | </dd> |
|
|
588 | <p></p> |
|
|
589 | <dt><strong><a name="item_rxvt_2dunicode_crashes_when_the_x_input_method_cha">Rxvt-unicode crashes when the X Input Method changes or exits.</a></strong><br /> |
|
|
590 | </dt> |
|
|
591 | <dd> |
|
|
592 | Unfortunately, this is unavoidable, as the XIM protocol is racy by |
|
|
593 | design. Applications can avoid some crashes at the expense of memory |
|
|
594 | leaks, and Input Methods can avoid some crashes by careful ordering at |
|
|
595 | exit time. <strong>kinput2</strong> (and derived input methods) generally succeeds, |
|
|
596 | while <strong>SCIM</strong> (or similar input methods) fails. In the end, however, |
|
|
597 | crashes cannot be completely avoided even if both sides cooperate. |
|
|
598 | </dd> |
|
|
599 | <dd> |
|
|
600 | <p>So the only workaround is not to kill your Input Method Servers.</p> |
| 587 | </dd> |
601 | </dd> |
| 588 | <p></p> |
602 | <p></p> |
| 589 | <dt><strong><a name="item_rxvt_2dunicode_uses_gobs_of_memory_2c_how_can_i_re">Rxvt-unicode uses gobs of memory, how can I reduce that?</a></strong><br /> |
603 | <dt><strong><a name="item_rxvt_2dunicode_uses_gobs_of_memory_2c_how_can_i_re">Rxvt-unicode uses gobs of memory, how can I reduce that?</a></strong><br /> |
| 590 | </dt> |
604 | </dt> |
| 591 | <dd> |
605 | <dd> |
