Steve Youngs <youngs(a)xemacs.org> writes:
YH> Here's a quit fix. I don't know if it should be
applied to
YH> eterm package as is.
YH> Index: term.el
YH> ===================================================================
YH> RCS file: /usr/CVSroot/XEmacs/packages/xemacs-packages/eterm/term.el,v
YH> retrieving revision 1.6
YH> diff -u -r1.6 term.el
YH> --- term.el 6 Oct 2000 09:58:21 -0000 1.6
YH> +++ term.el 7 Dec 2001 08:14:10 -0000
YH> @@ -1002,7 +1002,10 @@
YH> If there is already a running process in that buffer, it is not restarted.
YH> Optional third arg STARTFILE is the name of a file to send the contents of to
YH> the process. Any more args are arguments to PROGRAM."
YH> - (let ((buffer (get-buffer-create (concat "*" name
"*"))))
YH> + (let ((buffer (get-buffer-create (concat "*" name "*")))
YH> + (coding-system-for-read (or (and (boundp 'coding-system-for-read)
YH> + coding-system-for-read)
YH> + 'binary)))
YH> ;; If no process, or nuked process, crank up a new one and put buffer in
YH> ;; term mode. Otherwise, leave buffer and existing process alone.
YH> (cond ((not (term-check-proc buffer))
It looks good to me. What are your concerns about it, Yoshiki?
I've tested it with and without MULE and it works. But
still you can bite yourself by specifying -dos or -mac
flavor of coding-system. Perhaps it should bail out if such
coding-system is given.
Also, it might be better to automatically use -unix variant
instead of binary if no coding-system is specified. It will
behave strangely if the escape sequence is valid in that
coding-system but it is very unlikey to happen. Or we
should be always on the safe side and use binary. Opinions?
--
Yoshiki Hayashi