From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [dalias@aerifal.cx: ansi-term \e[J causes spurious newline [revised report]] Date: Wed, 21 Mar 2007 12:51:01 -0400 Message-ID: <87zm66o80a.fsf@stupidchicken.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174495944 10991 80.91.229.12 (21 Mar 2007 16:52:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2007 16:52:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 21 17:52:12 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HU42m-0002ft-Ea for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2007 17:52:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HU44T-0006Im-7M for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2007 11:53:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HU43X-0004I3-5V for emacs-devel@gnu.org; Wed, 21 Mar 2007 12:52:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HU43W-0004Go-Ga for emacs-devel@gnu.org; Wed, 21 Mar 2007 11:52:58 -0500 Original-Received: from south-station-annex.mit.edu ([18.72.1.2]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HU41o-0003F1-RX; Wed, 21 Mar 2007 12:51:12 -0400 Original-Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l2LGpBjB003165; Wed, 21 Mar 2007 11:51:11 -0500 (EST) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by central-city-carrier-station.mit.edu (8.13.6/8.9.2) with ESMTP id l2LGp1uD006199; Wed, 21 Mar 2007 12:51:02 -0400 (EDT) Original-Received: from localhost (MAIN-TWELVE-TWO-FIFTY-SIX.MIT.EDU [18.19.6.1]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id l2LGp1OV020794; Wed, 21 Mar 2007 12:51:01 -0400 (EDT) Original-Received: from cyd by localhost with local (Exim 3.36 #1 (Debian)) id 1HU41d-0001zz-00; Wed, 21 Mar 2007 12:51:01 -0400 In-Reply-To: (Richard Stallman's message of "Mon\, 19 Mar 2007 14\:10\:23 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0 X-detected-kernel: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68243 Archived-At: > From: Rich Felker > Subject: ansi-term \e[J causes spurious newline [revised report] > To: bug-gnu-emacs@gnu.org > > On versions of GNU emacs I have tested (21.1 and cvs unicode-2 > branch), the "ansi-term" terminal emulator (M-x ansi-term) exhibits > incorrect terminal behavior when given the ESC [ J sequence. In > addition to clearing to the end of the screen, it moves the cursor to > the beginning of the next line if the cursor is not already at the > beginning of a line. To test this, use the following shell command > from a shell running in ansi-term: > > echo -e 'hello\e[Jworld' > > On a vt100/ansi/ecma compatible terminal, this should leave > "helloworld" visible on the screen, with everything afterward cleared. > On GNU emacs' ansi-term, it prints hello on one line and world on the > next, after clearing to the end of the screen. > > Removing the calls to term-unwrap-line from term-erase-in-display (in > term.el) fixes the problem, but I don't know if this has any bad > side-effects. Looking through the code, I think the calls to term-unwrap-line should be removed. The note in the docstring of term-erase-in-display that it "should only be called when point is at the start of a screen line" is also false; this condition generally doesn't hold in situations where this function is called, and if we remove the term-unwrap-line calls, it's not necessary at all. Cursory testing seems to indicate that ansi-term behaves fine without the term-unwrap-line calls. What do you think?