There was an underlying assumption in readline.emitKeypressEvents (and
by extension emitKey) that the given stream (usually process.stdin)
would emit 'data' once per keypress, which is not always the case.
This commit buffers the input stream and ensures a 'keypress' event is
triggered for every keypress (including escape codes).
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Not removing 'end' listeners for input and output on the 'close' event
resulted in an EventEmitter related memory leak.
This issue also might be reproduced at:
https://github.com/npm/npm/issues/5203
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
If an input stream would emit `end` event, like
`fs.createReadStream`, then readline need to get the last line
correctly even though that line isnt ended with `\n`.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927
This is a backport of dfb0461 (see #5930) to the v0.10 branch.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927Closes#5930
Ability to return just the length of listeners for a given type, using
EventEmitter.listenerCount(emitter, event). This will be a lot cheaper
than creating a copy of the listeners array just to check its length.
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.
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.
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.
The idea here is to reduce the number of times that `setRawMode()` is called
on the `input` stream, since it is expensive, and simply pause()/resume()
should not call it.
So now `setRawMode()` only gets called at the beginning of the Interface
instance, and then when `Interface#close()` is called.
Test case included.
The overall goal here is to make readline more interoperable with other node
Streams like say a net.Socket instance, in "terminal" mode.
See #2922 for all the details.
Closes#2922.
This reverts commit 443071db57.
Patch was overly compilicated and made some incorrect assumptions about the
position of the cursor being at the bottom of the screen. @rlidwka and I are
working on getting a proper implementation written.