Re: i want to change no-conversion to equal binary

Jan> Ben Wing <ben(a)666.com&gt; writes: Jan> I very ambivalent about this change. It does make us Jan> compatible with FSF Jan> but I am not all sure us changing API all It it not _we_ who are changing the API. It is the non-English- speaker-chosen Mule terminology getting rationalized by the FSF. I believe this is a Morioka synch; I don't know whether (whoever) accurately synched and the FSF changed (that's what I recall, and Hrvoje says the same thing), or whether the synch was inaccurate; either way this is (a) better and (b) the standard API. We can fork the API or be damned. Like it or not, the FSF is the de facto standard, and they can no-conversion-us-harder, in the same way that Adobe Acrobats-ghostscript-harder and Microsoft MSVMs-java-harder. And in this case, as in many, the FSF API makes sense. We should talk to Gerd about this kind of stuff (once he gets Emacs 21 out). Martin seems to get along with him pretty well; he'll probably be more amenable to coordination than rms was. Jan> One wonders whether we should actually drop no-conversion Jan> altogether if this is a problem. No, if FSF Emacs supports "no-conversion", at least for now, we should too. But we can deprecate it as "ambiguous". Jan> P.S. It isn't helping that all the FSF docs prefer Jan> "no-conversion" over "binary". Somebody ought to do a diff FSF->XEmacs in ./man and submit it to them. At least they'd get an Internals manual out of it. :-) -- 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."