broken escape sequence parser states

[jerch]

Please have a look at http://www.vt100.net/emu/dec_ansi_parser. In the state diagram there you can see, that "execute" characters (like '\n', '\r' ...) don't break or reset the actual parser state - they will just get executed for most of the possible states.
Problem is that some sequence parser states allow nesting other escape sequences while others dont. That is not reflected by the actual state handling in xterm.js
This is partly tested by vttest under "1. Test of cursor movements" (press 5 times 'enter')

IMHO this is a major issue, since it affects the flow/state logic in write which is kinda the terminal core.

[jerch]

You can test this with: echo -e '###\x1b[\nC###'

expected result:

###
 ###

xterm.js result:

###
   C###

The cursor movement sequence is cancelled and the 'C' is treated as printable. There seems to be another problem since the '\n' doesnt move the cursor to position 1 on the next line (have not investigated this).

[parisk]

@jerch thanks for reporting this! Could you please mention a use case where this bug will come up and what will be the outcome for the end user?

UPDATE: Disregard this, did not see #145 (comment)

[parisk]

Disregard my previous comment.

[thomasjm]

I think I have an example of this affecting a real user... I'm using zsh in xterm.js. On a blank line, I type emacs and then hit tab to trigger tab completion. The backend responds with this on the websocket:

�[0memacs                emacs24-x            emacsclient.emacs24
�[Jemacs24              �[Jemacsclient          �[J                   �[A�[A�[m�[m�[m
�[7Cemacs�[K

When xterm.js renders this, the string at the cursor instantly turns into ememacs, and if I backspace 5 times I can't delete the em -- hitting backspace a lot makes the cursor stay like this: prompt > em

Seems like broken escape sequence parsing, apologies in advance if it's actually a separate issue.

[Rodeoclash]

I'm seeing the problem with parsing \n characters as well. While the writeLn function works great, new line escape characters in the string just seem to move the cursor to the next row but the same column. Here's an example of rendering the output from a WebPack build to the console:

[jerch]

@Rodeoclash Are you sending program output directly to the emulator without a pty by any chance? Note that on Unix the newline character is a single '\n' for files, but still gets translated to '\r\n' for terminals by the termios lib in the kernel.

[Rodeoclash]

@jerch Correct. I'm running Webpack via its Node API, capturing the output of a build and sending to an Xterm instance.

[jerch]

@Rodeoclash You basically lack the pty rewrites which ensure, that the data stream fits into the terminal.

Try replacing '\n' with '\r\n'. This will solve the left align issue. If you get problems with lines being to long for the terminal, you'll need to insert additional '\r\n' into a line at the terminal width index. (might not be necessary due to the autowrapping of the emulator)

[jerch]

Fixed with #1399.