Re: bug w/file-coding & processes

Easy part first: Jan> BTW nil == undecided is used is used in many more places and Jan> probably even it 3rd party code. We should not ask people who are not using Mule to think about coding systems if we can help it. The linebreak detection seems to be extremely reliable, so if there is an optional coding-system argument to a function, it should default to auto-detect. Thus nil should mean autodetect. Jan> This is what the Lispref says Jan> Coding System Types Jan> ------------------- Jan> `nil' Jan> `autodetect' Jan> Automatic conversion. XEmacs attempts to detect the Jan> coding system used in the file. and from src/mule-coding.c (at the very end): /* Need to create this here or we're really screwed. */ Fmake_coding_system (Qno_conversion, Qno_conversion, build_string ("No conversion"), list2 (Qmnemonic, build_string ("Noconv"))); Fcopy_coding_system (Fcoding_system_property (Qno_conversion, Qeol_lf), Qbinary); Jan> So it at least used to be correct (the lispref doesn't know Jan> about 'undecided). Given that is almost the only Jan> documentation there is about this stuff would it be possible Jan> to update the documentation first? I'll give it a whack later this week. Since we already do have both 'no-conversion and 'binary defined, we should set up the API so that anything that might want to handle the 'no-conversion coding system should expect one of those, and not 'nil as an argument. I suspect that this is just a typo somewhere, and nobody really intended for 'nil to stand for 'no-conversion (I hope). -- 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 two straight lines for? "Free software rules."