PR-URL: https://github.com/nodejs/node/pull/57591
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Jordan Harband <ljharb@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/52625
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
The logic for reading lines was slightly flawed, in that it assumed
there would be a final new line. It handled the case where there are no
new lines, but this then broke if there were some new lines.
The fix in logic is basically removing the special case where there are
no new lines by changing it to always read the final line with no new
lines. This works because if a file contains no new lines, the final
line is the first line, and all is well.
There is some subtlety in this functioning, however. If the last line
contains no new lines, then `lastIndex` will be the start of the last
line, and `kInsertString` will be called from that point. If it does
contain a new line, `lastIndex` will be equal to `s.length`, so the
slice will be the empty string.
Fixes: https://github.com/nodejs/node/issues/47305
PR-URL: https://github.com/nodejs/node/pull/47317
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Since the lineEnding Regular Expression is declared on the module scope,
recursive invocations of its `[kTtyWrite]` method share one instance of
this Regular Expression.
Since the state of a RegExp is managed by instance,
alternately calling RegExpPrototypeExec with the same RegExp on
different strings can lead to the state changing unexpectedly.
This is the root cause of this infinite loop bug when calling .load on
javascript files of certain shapes.
PR-URL: https://github.com/nodejs/node/pull/46742
Fixes: https://github.com/nodejs/node/issues/46731
Reviewed-By: Kohei Ueno <kohei.ueno119@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
`validateNumber` throws more proper error code and
error name.
PR-URL: https://github.com/nodejs/node/pull/45801
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Using a direct approach to create the readline async iterator
allowed an iteration over 20 to 58% faster.
**BREAKING CHANGE**: With that change, the async iteterator
obtained from the readline interface doesn't have the
property "stream" any longer. This happened because it's no
longer created through a Readable, instead, the async
iterator is created directly from the events of the readline
interface instance, so, if anyone is using that property,
this change will break their code.
Also, the Readable added a backpressure control that is
fairly compensated by the use of FixedQueue + monitoring
its size. This control wasn't really precise with readline
before, though, because it only pauses the reading of the
original stream, but the lines generated from the last
message received from it was still emitted. For example:
if the readable was paused at 1000 messages but the last one
received generated 10k lines, but no further messages were
emitted again until the queue was lower than the readable
highWaterMark. A similar behavior still happens with the
new implementation, but the highWaterMark used is fixed: 1024,
and the original stream is resumed again only after the queue
is cleared.
Before making that change, I created a package implementing
the same concept used here to validate it. You can find it
[here](https://github.com/Farenheith/faster-readline-iterator)
if this helps anyhow.
PR-URL: https://github.com/nodejs/node/pull/41276
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
That method is overwritten in both
`require('node:readline').Interface.prototype` and
`require('node:readline/promises').Interface.prototype`, and is very
much not useful outside of interacting with TTY, removing it from the
parent class could enable the use of `InterfaceConstructor` in other
contexts (such as interacting with files).
PR-URL: https://github.com/nodejs/node/pull/44606
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
1. Any keystroke emits `0x1E` will do redo action.
2. Fix bug of undo/redo.
3. More detailed document.
4. Unit tests.
PR-URL: https://github.com/nodejs/node/pull/41662
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
1. `Ctrl-Y` to yank previously deleted text
2. `Meta-Y` to do yank pop (cycle among deleted texts)
3. Use `getCursorPos().rows` to check if we have reached a new line,
instead of `getCursorPos().cols === 0`.
4. document and unittests.
PR-URL: https://github.com/nodejs/node/pull/41301
Fixes: https://github.com/nodejs/node/issues/41252
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Qingyu Deng <i@ayase-lab.com>
This is a minor performance improvement for readline. It skips to
escape individual characters again after escaping them before.
Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/41005
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Dario Piotrowicz
Giovanni Bucci
Antoine du Hamel
Daniel Venable
Aviv Keller
Michaël Zasso
atlowChemi
Jackson Tian
atlowChemi
Ian Harris
Theodor Steiner
Deokjin Kim
Thiago Oliveira Santos
LiviaMedeiros
Xuguang Mei
Ray
Ray
Ruben Bridgewater