From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: [dalias@aerifal.cx: ansi-term \e[J causes spurious newline [revised report]] Date: Fri, 03 Aug 2007 08:49:56 -0700 Message-ID: <200708031550.l73Fo0xh010200@oogie-boogie.ics.uci.edu> References: <87zm66o80a.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1186156419 9493 80.91.229.12 (3 Aug 2007 15:53:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2007 15:53:39 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 03 17:53:37 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 1IGzT5-0000Hb-Lm for ged-emacs-devel@m.gmane.org; Fri, 03 Aug 2007 17:53:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGzSs-0000oI-Aq for ged-emacs-devel@m.gmane.org; Fri, 03 Aug 2007 11:53:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGzSn-0000lr-RX for emacs-devel@gnu.org; Fri, 03 Aug 2007 11:53:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGzSh-0000iB-MS for emacs-devel@gnu.org; Fri, 03 Aug 2007 11:53:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGzSh-0000i6-In for emacs-devel@gnu.org; Fri, 03 Aug 2007 11:53:11 -0400 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IGzSJ-00018A-Mb; Fri, 03 Aug 2007 11:52:49 -0400 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id l73Fo0xh010200; Fri, 3 Aug 2007 08:50:00 -0700 (PDT) In-Reply-To: <87zm66o80a.fsf@stupidchicken.com> (Chong Yidong's message of "Wed\, 21 Mar 2007 12\:51\:01 -0400") Original-Lines: 38 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.69, required 5, autolearn=disabled, ALL_TRUSTED -1.44, FM_MULTI_ODD2 1.10, FS_OBFU_X 1.03) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-Detected-Kernel: Solaris 9 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:75998 Archived-At: Chong Yidong writes: > > 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? I checked in a patch that I hope fixes the problem.