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: Wed, 21 Mar 2007 22:08:41 -0700 Message-ID: <200703220508.l2M58fte023654@oogie-boogie.ics.uci.edu> References: <87zm66o80a.fsf@stupidchicken.com> <200703211840.l2LIem6A013375@oogie-boogie.ics.uci.edu> <87ps724dbd.fsf@stupidchicken.com> <200703212016.l2LKGo67015610@oogie-boogie.ics.uci.edu> <200703220322.l2M3M8Ed022513@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174540335 22969 80.91.229.12 (22 Mar 2007 05:12:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2007 05:12:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 22 06:12:08 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 1HUFam-0001ox-2Y for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2007 06:12:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUFcW-0003IH-D2 for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2007 00:13:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUFcO-0003BN-6S for emacs-devel@gnu.org; Thu, 22 Mar 2007 01:13:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HUFcN-0003B3-Kn for emacs-devel@gnu.org; Thu, 22 Mar 2007 01:13:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUFcN-0003Ay-Ca for emacs-devel@gnu.org; Thu, 22 Mar 2007 00:13:43 -0500 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 1HUFab-0007MD-Sm for emacs-devel@gnu.org; Thu, 22 Mar 2007 01:11:54 -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 l2M58fte023654; Wed, 21 Mar 2007 22:08:41 -0700 (PDT) In-Reply-To: (Miles Bader's message of "Thu\, 22 Mar 2007 12\:44\:36 +0900") Original-Lines: 52 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.267, required 5, autolearn=disabled, ALL_TRUSTED -1.44, FS_OBFU_X 1.03, J_CHICKENPOX_42 0.60, TW_VT 0.08) 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:68274 Archived-At: Miles Bader writes: > Dan Nicolaescu writes: > > > Is it the escape sequence "\e[J" actually undefined on a real terminal > > > in that case, or is merely the more abstract "ed" terminfo capability > > > which is undefined in that case? > > > > I am not sure what the question is... :-( > > In any case I am not aware of any documentation for the different > > escape sequences other than terminfo (or the terminal emulator > > actual code, if that counts as documentation). > > I mean that you described the preconditions of the terminfo "ed" > capability, but that's not what term.el seems to be modelled after (to > degree that it's modelled after anything :-). Terminfo is an > abstraction, and so tries to restrict the assumptions people make about > capabilities to some practical common denominator of the many types of > terminals it supports -- however many programs do not use terminfo; for > instance they may directly use ANSI escape sequences instead. > > term.el says: > > ;;; It emulates (most of the features of) a VT100/ANSI-style terminal. So it emulates most of the features, NOT the terminal itself... AFAIK there's no real effort in the code to emulate anything else other than the documented terminfo behavior. (There is some commented out code that I added that emulates non-terminfo stuff. I added that so that I can run a hacked up version of vttest to check if things still work when changing something). > I'm not saying it should exactly emulate any existing terminal -- that's > probably impractical -- but neither should it restrict its emulation to > only those sequences terminfo might produce. For term.el to be > practical, we should care whether term.el follows common xterm and > VT100/ansi practice, even in cases where the behavior in question would > never be produced by terminfo. Well, that's a rat hole that I don't think we want to get into. Not at this point in the release cycle. If users show that some features are required by real applications to run correctly, then we can consider it. If it's just: "'echo XYZ' works differently ", then it's not really important. The code that started this was documented to work the way it does since 1994. The proposed change fixes the issue at hand, but: 1. I am not convinced the change is correct in all cases. 2. Risking breaking something else this close to a release is not a great idea. 3. It's document undefined behavior created by an artificial testcase. I can look into this after the release.