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."

Stefan> I'd love it and so would the rest of the Emacs Stefan> maintainers, I'm sure (we'd even get a CCL documentation Stefan> to boot), but I think it would get bogged down in Stefan> copyright problems. Unless all contributors to those Stefan> parts of the manual have (or are willing to) signed the Stefan> relevant legal blabla. The CCL parts are unambiguously usable by the FSF. They are my translation (assign.future for all of XEmacs on file at FSF) of the original Japanese English in the docstrings and source comments (copyright Japanese Ministry of Finance and file authors, but presumably covered under the contract with ETL). If you want the CCL stuff, when our release settles down a bit I'd be happy to do the legwork (grepping ChangeLogs and the CVS repository, listing up authors and contacting those without FSF papers on file) to confirm that statement, but I'm fairly sure it's true. I'll also work with himi on fleshing it out, since he seems to be the main authority on CCL right now, but that will probably have to wait until the summer. In any case I see NO copyright problems. The GNU Project doesn't supply any Internals manual, so you can distribute ours "as is" until you do, or somebody files suit against us for infringement. It's "mere aggregation," you just abandon it, and so it will have no legal impact on other documentation or code. (IANAL, of course, but I think that's a legal theory worth checking with a lawyer.) You would have a management problem (people would surely be tempted to copy translated docstrings back into the code or into your new manual), but that's a different issue. -- 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."