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

Ben> Thankfully, nearly all of this horridity you bring up is Ben> irrelevant. I don't think so. The GNU Translation Project has worked very hard to bring GNU gettext() to the state it is in; do you think they would have settled for something as weak as it is if dealing with the "horridity" was easy or irrelevant? Ben> In XEmacs, "gettext" does not refer to any standard API, but Ben> is merely a stand-in for a translation routine (presumably Ben> written by us). Oh. Bad naming, then. Ben> We may as well call it something else. Yes, please. Ben> We define our own concept of "current language". We also Ben> allow for a function that needs a different version for each Ben> language, which handles all cases where simple translation Ben> isn't sufficient, e.g. when you have to pluralize some noun Ben> given to you or insert the correct form of the definite Ben> article. No weird hacks needed. No interaction problems Ben> with other pieces of software. The interaction problems I'm worried about are all within XEmacs. Whether "what you wrote awhile ago" is sufficient I will wait until I see it to judge. Ben> "There you go again" is usually not true; most of what I Ben> quote was indeed put out publicly at some point, but I'll try Ben> to be more explicit about this in the future. Ben, you asked a question about how to merge agendas; "publically at some point [implicitly, in bits and pieces]" is not an agenda. If XEmacs Beta is not going to be the channel for design discussions, especially at that level, then a public one, perhaps moderated/write- restricted if you must, should be opened up. -- 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."