bug w/file-coding & processes

Darryl> Scenario: Darryl> XEmacs 21.1.4 w/file-coding but not MULE Darryl> (I think MULE is irrelevant, for this bug) Deciding coding systems is one of the core functions of Mule; Mule is not irrelevant to the solution. Darryl> Problem: Darryl> This is, er, "interesting"; `coding-system-for-read' Darryl> needs to be `nil' (for binary input), but `call-process' Darryl> insists on setting it to be `undecided'. <sigh> A bug on a bump on a bag on a hack on a kludge... The apparent "right" way to handle this is to set `process-coding-system-alist' to an appropriate value. That should be done in any relevant packages. The logic should look like this, I think, but some stuff still needs checked so no patch yet: (let (ret) (catch 'found (let ((alist process-coding-system-alist) (case-fold-search (eq system-type 'vax-vms))) (while alist (if (string-match (car (car alist)) program) ;; Old code set RET to CDR of RET as set here (throw 'found (setq ret (car alist))) ) (setq alist (cdr alist)) ))) ;; logic changed to assume RET is elt of alist, not its CDR (if (not ret) 'undecided ;; not found in alist (setq ret (cdr ret)) ;; ### should be fixed to catch non-coding-systems ;; but the semantics are not clear without reading ;; source (documentation confounds symbols naming ;; coding systems with coding system objects) (cond ((consp ret) (car ret)) ((find-coding-system ret) ret)) ((functionp ret) (funcall ret 'call-process program)) (t 'undecided))) There is still a bug that there's no way for higher level code to explicitly bind coding-system-for-read to nil to set the coding system to binary. This can't be fixed without an explicit `binary' coding system name. But at least this code gets a good guess for programs properly registered in `process-coding-system-alist'. `process-coding-system-alist' is a variable declared in Lisp. -- loaded from "/playpen/src/xemacs-21/lisp/code-process.elc" Value: nil Documentation: Alist to decide a coding system to use for a process I/O operation. The format is ((PATTERN . VAL) ...), where PATTERN is a regular expression matching a program name, VAL is a coding system, a cons of coding systems, or a function symbol. If VAL is a coding system, it is used for both decoding what received from the program and encoding what sent to the program. If VAL is a cons of coding systems, the car part is used for decoding, and the cdr part is used for encoding. If VAL is a function symbol, the function must return a coding system or a cons of coding systems which are used as above. Darryl> Perhaps we should add an explicit binary coding name? I certainly would vote for that (which should, if just an additional alias, maintain backward compatibility). I think that is preferable to using t. In Lisp, nil is normally the default, often undecided, value. The usage of nil to mean "binary" == "raw" fits neither criterion. (The nil means "null conversion" interpretation is attractive but wrong, as we see.) I have no idea how t would fit here.... In this case I do not think we should try to maintain backward compatibility. That by definition will require maintaining an ambiguity between the "raw" meaning and the "undecided" meaning, which is only asking for future similar bugs when porting FSF code. Unless we can get the FSF to agree on this change that would cost FSF compatibility, but I think the benefit in reliability is worth it. The auto-coding-system stuff needs to have semantics and an API documented (and before that, I'm afraid, defined). -- 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."