summaryrefslogtreecommitdiff
path: root/test/simple/test-readline-interface.js
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'upstream/v0.10'Timothy J Fontaine2013-09-241-0/+12
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: AUTHORS ChangeLog configure deps/uv/ChangeLog deps/uv/src/version.c lib/tls.js src/node_version.h
| * readline: handle input starting with control charsEric Schrock2013-09-231-0/+12
| | | | | | | | | | Handle control characters only when there is a single byte in the stream, otherwise fall through to the standard multibyte handling.
* | readline: strip ctrl chars for prompt width calcKrzysztof Chrapka2013-06-171-0/+10
| | | | | | | | | | | | | | Use regular expression to strip vt ansi escape codes from display when calulating prompt display width and cursor position Fixes #3860 and #5628.
* | readline: handle wide characters properlyNao Iizuka2013-03-151-0/+19
|/ | | | | | | | Handle wide characters (such as あ, 谢, 고) as two column wide to make cursor move properly. Closes #555. Closes #4994.
* readline: treat bare \r as a line endingisaacs2013-01-291-0/+30
| | | | Fixes #3305
* readline: make \r\n emit one 'line' eventBen Noordhuis2013-01-291-0/+13
| | | | | | | | | Make lines ending \r\n emit one 'line' event, not two (where the second one is an empty string). This adds a new keypress name: 'return' (as in: 'carriage return'). Fixes #3305.
* readline: use a "string_decoder" to parse "keypress" eventsNathan Rajlich2012-11-061-88/+92
| | | | | | | While updating the readline test cases to test both "terimal: false" and "terminal: true" mode, it turned out that the test case testing utf8 chars being sent over multiple write() calls was failing. The solution is to use a string_decoder instance when parsing the "keypress" events.
* readline: don't emit "line" events with a trailing '\n' charNathan Rajlich2012-11-061-6/+6
| | | | | | | | | | Before this commit, readline was inconsistent in whether or not it would emit "line" events with or without the trailing "\n" included. When "terminal" mode was true, then there would be no "\n", when it was false, then the "\n" would be present. However, the trailing "\n" doesn't add much, and most of the time people just end up stripping it manually. Part of #4243.
* readline: Remove event listeners on closeisaacs2012-07-241-0/+9
| | | | Fix #3756
* readline: use StringDecoder for decoding "normal" dataNathan Rajlich2012-04-061-0/+16
| | | | The fix from #3059 was not handling multi-byte utf8 data properly.
* readline: buffer data to only emit 'line' on '\n'Nathan Friedly2012-04-061-0/+106
In "terminal: false" mode. (And fire it multiple times if multiple lines arrive at once.) This is necessary because the Windows telnet client sends every single keystroke as it's typed. See: http://stackoverflow.com/questions/9962197/node-js-readline-not-waiting-for-a-full-line-on-socket-connections Closes #3059.