The existing mlterm-2.9.2 ebuild does not support SCIM despite mlterm having support for it. Editing the ebuild to allow enabling SCIM support is trivial and compiles and works on x86. Reproducible: Always Steps to Reproduce: 1. USE="scim" emerge =mlterm-2.9.2 2. Note ebuild added "--disable-scim" in configure output. 3. Try using SCIM as the input method. Actual Results: Despite saying "USE=scim" emerge =mlterm-2.9.2 no SCIM support is compiled. Expected Results: It should enable SCIM if included in the USE flags, because the upstream mlterm source supports it. The changes necessary to add SCIM support in the ebuild are simple. Change IUSE to IUSE="truetype gtk imlib bidi nls uim scim". Add "scim? ( >=app-i18n/scim-1.2.0 )" to DEPEND. Stick "$(use_enable scim) \" in the list of arguments passed to econf in the src_compile() function. Once these are added and "scim" is in the USE flags, it compiles and apparently works. (At least, I can type Japanese text into vi in mlterm and subsequently read it in Firefox without problem.) Also, since SCIM's latest stable ebuild is 1.2.0 and this is for mlterm's latest ebuild 2.9.2, I figure that requiring the latest stable SCIM ebuild is acceptable. Earlier versions of SCIM tend to misbehave in peculiar ways. SCIM 1.2.0 seems to work fine, although the IM mode switch key doesn't work with SCIM in mlterm yet so mousing is necessary for changing IM modes.
The reason why I don't add iiimf, m17n-lib and scim support is they are not stable. (mlterm upstream says they are experimental, and thus not enabled by default) Since we cannot assign keywords to USE flag (e.g. we cannot mark scim USE flag is unstable, and so on) I don't think we should support it. (Note that X terminal is one of the common software and most people expect it to be stable) uim support of mlterm is also marked experimental but works flawlessly, so I added uim USE flag to mlterm. A package supports X feature doesn't necessarily mean we should add X feature to A. If these features become fairly stable I will reconsider adding them. Any comments on this?
How about an mlterm-2.9.2-r2 ebuild where everything is marked ~x86, ~sparc, and so forth? Then the ebuild would be experimental as well, and only people who wanted to deal with bugs would install it.
