Re: check process state before accessing coding_stream (fix PR#1061)

Ben> Implementing message translation is not that hard. What I have in mind is not just gettext-izing everything in the XEmacs core sources. I currently believe that to be unacceptable (see Jan's message for the pitfalls in I18N; it's worse for M17N). I think really solving this problem needs a specifier-like fallback mechanism (this would solve Jan's example because you could query the text-specifier presenting the question for the affirmative and negative responses, and the catalog-building mechanism would have checks to make sure they were properly set, perhaps a locale (language) argument), and gettext is just not sufficient for that. At a minimum, we need to implement gettext for Lisp packages. (Currently, gettext is only implemented for C AFAIK.) But this could potentially cuase more trouble than it's worth. Ben> A lot depends on priority: How important do you think this Ben> issue is to your average Japanese/Chinese/etc. user? Which average Japanese (etc) user? The English-skilled (relatively) programmer in the free software movement, or my not-at-all-competent undergrad students who I would love to have using an Emacs? This is a really important ease-of-use issue. Realistically, for Japanese, it's low priority. The Japanese team in the GNU Translation Project is doing very little AFAIK, so even if the capability were there, I doubt the message catalog would soon be done. But I think that many non-English speakers would find it very attractive, and for many languages there are well-organized and productive translation teams. I suspect that if the I18N facility were well-designed, many Western European languages would have full catalogs within a year (granted, they are the ones where it's least needed :-( ). Personally, I think doing it well is hard, and of little benefit to _current_ core XEmacs constituency. I think doing a good job, with catalogs, would be very attractive to many non-English-speaking _potential_ users. Ben> How does it compare to some of the other important Mule Ben> issues that Martin and I are (trying to work) on? I don't know what you guys are _trying_ to work on. Everything in the I18N section of "Architecting XEmacs" is red-flagged. OTOH, it's clear from your posts that you are overburdened, so I can't read priority into the fact that you've responded to specific issues in the past. What I see as Mule priorities (in rough benefit order, I am not taking account of difficulty, nor the fact that some - eg 8 & 10 - will probably come as packages): 1. Fix the autodetect problem (by making the coding priority list user-configurable, as short as he likes, even null, with "binary" as the default). 2. Document the language environments and other Mule "APIs" as implemented (since there is no real design spec). Check to see how and where they are broken. 3. Make the Mule menu useful to non-ISO-2022-literate folks. 4. Redo the lstreams stuff to make it easy and robust to "pipeline", eg, libz | gnupg | jis2mule. 5. Make Custom Mule-aware. (This probably depends on a sensible fonts model.) 6. Implement the "literal byte stream" memory feature. 7. Study the FSF implementation of Mule for background for 7 & 8. 8. Identify desirable Mule features (eg, i18n-ized messages as above, collating tables by language environment, etc). (New features might have priority as high as 9.) 9. Specify Mule UIs, APIs, etc, and design and (re)implement them. 10. Implement the 8-bit-wide buffer optimization. 11. Move the internal encoding to UTF-32 (subject to Olivier's caveats regarding compose characters), with the variable-width char buffers using UTF-8. 12. Implement the 16- and 32-bit-wide buffer optimizations. There's surely other stuff I've forgotten. Ben> The big question is, would you be willing to help do the Ben> actual implementation, to "be my hands"? Sure, subject to the usual caveat that I'd need to be convinced it's worth doing and a secondary caveat that I am not an experienced coder. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."