You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: Inform the "line" event on a Readline interface of the type of end-of-line input #7952
I was using the Readline module to rewrite a file line by line. While doing that I noticed that I had no idea which end-of-line (\r, \n, \r\n) caused the line break so I could not reassemble the file exactly as it was.
Of course I could detect the first EOL and then just use that for everything but in most cases I want to leave the line untouched anyway. Wouldn't it be a good idea to pass the found EOL string as a second argument to the callback of a line event emitted by a readline.Interface?
This is good idea, I think. It would definitely need to be line-by-line because a single doc could contain a mix. The key challenge with implementing this is that the current impl does not record the line-ending currently. It wouldn't be that difficult to add in tho.
I'd love to. I'll give it a try but it's quite possible that I'll just fail to understand the bigger picture of the project. Got a pretty promising looks on the readline.js file though so let's see what comes around, :)
I started with something but I'd really be completely fine to give that job over to @JungMinu since I realized that I'm actually pretty occupied with more important programming stuff for the next couple of weeks.
So @JungMinu, if you want to give it a shot, go for it. 👍
I just planned on implementing this I came to a point where it's difficult to identify the actual end-of-line.
Readline just receives arbitrary chunks and we have to delay emitting the last line in case the chunk contains a carriage return at the end of it. Otherwise it's not possible to guarantee that it's the correct line ending. We also have the crlfDelay option with a default of 100 ms. That means we'll have to trigger a timeout in such cases to emit the line in case no new chunk is incoming during that time. Having such a delay seems pretty bad for most applications, even though it's probably a pretty rare case.
It should also probably only work in case the terminal option is set to false.
I am for these reasons not sure anymore if we should really implement this.
Any opinions?
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
Activity
vsemozhetbyt commentedon Aug 9, 2016
@loilo
It is not a reliable approach unless you read the whole file first.
\rand\nin\r\n.jasnell commentedon Aug 9, 2016
This is good idea, I think. It would definitely need to be line-by-line because a single doc could contain a mix. The key challenge with implementing this is that the current impl does not record the line-ending currently. It wouldn't be that difficult to add in tho.
Interested in doing a PR? :-)
loilo commentedon Aug 9, 2016
I'd love to. I'll give it a try but it's quite possible that I'll just fail to understand the bigger picture of the project. Got a pretty promising looks on the readline.js file though so let's see what comes around, :)
addaleax commentedon Aug 9, 2016
@loilo Cool! If there’s anything you need or you’d like to ask, you can do that here or e.g. in #node-dev on Freenode!
jasnell commentedon Aug 9, 2016
+1 to what @addaleax said :-) If you get stuck or need someone to bounce ideas off of, just let one of us know!
JungMinu commentedon Aug 10, 2016
I'd love to do a PR, please let me know if I can help :)
addaleax commentedon Aug 10, 2016
I think @loilo is already working on something? :)
loilo commentedon Aug 10, 2016
I started with something but I'd really be completely fine to give that job over to @JungMinu since I realized that I'm actually pretty occupied with more important programming stuff for the next couple of weeks.
So @JungMinu, if you want to give it a shot, go for it. 👍
JungMinu commentedon Aug 11, 2016
Yep, I will do a PR soon @loilo @addaleax
Trott commentedon Jul 9, 2017
@JungMinu Are you still planning on doing this? If not, should we unassign it so someone else can pick it up?
gireeshpunathil commentedon May 21, 2018
ping @JungMinu
BridgeAR commentedon Dec 14, 2019
I just planned on implementing this I came to a point where it's difficult to identify the actual end-of-line.
Readline just receives arbitrary chunks and we have to delay emitting the last line in case the chunk contains a carriage return at the end of it. Otherwise it's not possible to guarantee that it's the correct line ending. We also have the
crlfDelayoption with a default of 100 ms. That means we'll have to trigger a timeout in such cases to emit the line in case no new chunk is incoming during that time. Having such a delay seems pretty bad for most applications, even though it's probably a pretty rare case.It should also probably only work in case the
terminaloption is set tofalse.I am for these reasons not sure anymore if we should really implement this.
Any opinions?
github-actions commentedon Mar 4, 2022
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
github-actions commentedon Apr 4, 2022
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.