From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686; Nav)
Description of problem:
Two problems when starting up term.el with M-x term:
1. \ns don't work properly: after each newline the cursor remains at the
same x coordinate.
2. After each <ret> in bash I get the error:
(2) (error/warning) Error in process filter: (error /home/virgi/ is not a
The userid was actually virgin (I tested a virgin account to make sure it
wasn't something in my .bashrc that was messing things up).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start xemacs
2. M-x term
Actual Results: I get something like
bash-2.04 $ ls
plus the error above
Expected Results: Instead of
bash-2.04 $ ls
and no error
You should run M-x shell, not M-x term directly.
I'm sorry, I don't understand. If I run M-x shell I don't get terminal
emulation, even if I (load "term") first. And there's a documentation bug, as
/usr/lib/xemacs/xemacs-packages/lisp/eterm/README.term says that you should
start the terminal emulator with M-x term.
I also tried RH 6.2 and got the same problem, although under Emacs it seems to
work (by running M-x term).
I have now confirmed that various versions of XEmacs, under Debian as well as
RedHat, seem to have a non-functioning term. On closer investigation, this
appears to be because \r characters are not getting through to the terminal
Also, I have confirmed that under Emacs 20.7, term works fine; however, copying
Emacs's term.el into an XEmacs tree doesn't help, suggesting that the actual
problem is elsewhere.
I've asked about all this on comp.emacs.xemacs and gotten no response; I'll try
reporting a bug to the XEmacs development team as well as notifying you here.
I've managed to get a solution to this problem from the XEmacs team:
(defun evil-term-process-coding-system-bugfix ()
"Fix a term bug; the `process-coding-system' should always be `binary'."
(set-buffer-process-coding-system 'binary 'binary))
(add-hook 'term-exec-hook 'evil-term-process-coding-system-bugfix)
added to .xemacs/init.el does the trick. Presumably a similar fix can be made to
term.el itself; I think it worth reporting here because I don't know what
version of XEmacs you'll ship with 7.2, and even if it's up to date, the fix
might well take a long time to get into the stable version.
This is still a problem with xemacs 21.4.6 and the latest lisp packages.
This to be ok to be with the current xemacs + xemacs-sumo in rawhide.
Please re-open if problem persists.