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

Ben> "Stephen J. Turnbull" wrote: Ben> I don't quite understand. Could you elaborate and give some Ben> examples? Examples? Hmm. First, there's the surface of Jan's y-or-n-p example. You have to coordinate the translation of the message string and the response prompt. This is handled by y-or-n-p itself (I see that we already do have gettext for Emacs Lisp, that's nice to know). Except that it's not really handled by y-or-n-p. There's no reason to suppose that somebody writing a Lisp package would necessarily use the XEmacs domain (in fact, due to the way gettext binds text domains---if I understand that correctly---we don't want that to be the case, because it means that every time a Lisp package is updated the whole XEmacs catalog must also be updated). So which domain gets used for the message string? In the current implementation, it is the domain of y-or-n-p. So packages with their own domain won't get y-or-n-p prompts correctly translated. But that means that the package should do its own translation. But now you're applying gettext to the same string twice; you just have to pray the that translator upstream doesn't collide with an English string that's in the XEmacs domain. (The gettext docs mention the similar problem of English words with multiple meanings that must map to different words in the target language; this can be disambiguated by various trickeries in forming the strings ... but only if you "own" them, which in the multi-domain, interated gettext example you do not.) AFAICT this means that you must never pass untranslated strings across public APIs, but this may or may not be reasonable, and certainly is inconvenient. Next, we have to translate the possible answer strings to match the language being passed by the user. This is presumably OK here, because it's done by y-or-n-p. But what if y-or-n-p returned a string rather than a boolean? Then we would need to coordinate the presentation of the prompt (done by y-or-n-p) and the translation of the possible answer strings (done by the caller). This can in fact be done using dgettext with the XEmacs domain, but you must know that y-or-n-p is in the XEmacs domain. This is not necessarily going to be obvious, and it might very well be that sets of related packages might have the same domain, so you wouldn't necessarily know which domain is appropriate by looking at the requires. And what happens if one domain does supply translations for a language and the other does not? AFAIK, gettext has no way to find out if this is the case. But you might very will prefer a global fallback to English if substantial phrases are drawn from both domains, while you might prefer string-by-string fallback if the main text is translated and only a few words are left to fallback to English. Aside from confusing users, this puts a great burden on programmers. Programmers need to know about the status of the domains of packages they use as well as the XEmacs domain; they need to program defensively against the possibility that some package they use will become gettext-ized, or the translation projects will be out of synch (some teams will do the calling package first, others will do the caller package first). I don't think anybody will use gettext in these circumstances. At least not after they get the first bug report that "XEmacs is stuck in an infinite y-or-n-p loop and I can't get out." Ben> I wrote this awhile ago: "There you go again." Not anywhere I could see it! (At least, it doesn't look familiar and grepping the archives doesn't turn it up.) OK, you win. Subscribe me to xemacs-review. Or whatever seems appropriate. -- 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."