Re: [dalias@aerifal.cx: ansi-term \e[J causes spurious newline [revised report]]

[Dan Nicolaescu <dann@ics.uci.edu>]

Miles Bader <miles.bader@necel.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> 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.