Bug 52660 - Problems with term.el
Summary: Problems with term.el
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xemacs   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-27 19:29 UTC by Reuben Thomas
Modified: 2007-04-18 16:36 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-19 12:05:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Reuben Thomas 2001-08-27 19:29:55 UTC
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):

How reproducible:

Steps to Reproduce:
1. Start xemacs
2. M-x term
3. ls<ret>

Actual Results:  I get something like
bash-2.04 $ ls
                                bash-2.04 $
plus the error above

Expected Results:  Instead of 
bash-2.04 $ ls
bash-2.04 $
and no error

Additional info:

Comment 1 Trond Eivind Glomsrxd 2001-08-27 20:29:07 UTC
You should run M-x shell, not M-x term directly.

Comment 2 Reuben Thomas 2001-08-28 08:35:35 UTC
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).

Comment 3 Reuben Thomas 2001-09-05 14:52:48 UTC
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.

Comment 4 Reuben Thomas 2001-09-11 18:09:59 UTC
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.

Comment 5 Trond Eivind Glomsrxd 2002-03-25 19:55:10 UTC
This is still a problem with xemacs 21.4.6 and the latest lisp packages.

Comment 6 Jens Petersen 2003-05-19 12:05:52 UTC
This to be ok to be with the current xemacs + xemacs-sumo in rawhide.
Please re-open if problem persists.

Note You need to log in before you can comment on or make changes to this bug.