Red Hat Bugzilla – Bug 52660
Problems with term.el
Last modified: 2007-04-18 12:36:38 EDT
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 directory) 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): How reproducible: Always Steps to Reproduce: 1. Start xemacs 2. M-x term 3. ls<ret> Actual Results: I get something like bash-2.04 $ ls Desktop bash-2.04 $ plus the error above Expected Results: Instead of bash-2.04 $ ls Desktop bash-2.04 $ and no error Additional info:
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 emulation code. 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.