Repository navigation
Expose readline.Interface "line", "cursor", "getCursorPos" #30347
Description
Activity
I can't speak for other collaborators but I'm okay with promoting
_getCursorPos()to public API, i.e., by stripping the underscore. readline's implementation has been stable for a long time now and I don't expect that to change.The
.lineand.cursorproperties have simply never been documented, I think.I suggest opening a pull request and see how it's received.
Reacted by antsmartianI'd be OK with that suggestion as well ^
- added a commit that references this issue
on Nov 19, 2019 Opened a PR for
@types/node. If I strip the underscore from_getCursorPos(), would that only make it into future releases of node? Or are patches still being released for v8+?Opened a PR for @types/node.
We should document them in this repo as well. Care to open a documentation PR?
If I strip the underscore from _getCursorPos(), would that only make it into future releases of node? Or are patches still being released for v8+?
I'd recommend stripping the underscore, but also creating an alias (
_getCursorPos = getCursorPos). If you don't create the alias, it will be a breaking change and will have to wait for Node 14. If you add the alias, it can be a semver-minor change, allowing it to land in Node 13 and potentially as far back as Node 10. I think Node 8 is unlikely at this point, given that it is end-of-life next month.If it's all the same to you, I think I'd rather just make an alias the other way around:
getCursorPos = _getCursorPos.To me that makes more sense (even though they both effectively do the same thing); instead of changing every instance where
_getCursorPosis used internally, it would just be exposing an internal member. Minimally invasive 😆.I will make both of these PRs when I have a few more minutes to spare.
- added 2 commits that reference this issue
on Nov 23, 2019 +1 to move
_getCursorPosto public API.- added a commit that references this issue
on Dec 2, 2019 - added a commit that references this issue
on Dec 7, 2019 - added a commit that references this issue
on Dec 9, 2019 - added a commit that references this issue
on Dec 9, 2019 - added a commit that references this issue
on Dec 9, 2019 - added a commit that references this issue
on Dec 16, 2019 - added a commit that references this issue
on Dec 17, 2019 Thanks @Js-Brecht , this is taken care in: #30667, #30687
Reacted by Jeremy Albright- added 3 commits that reference this issue
on Jan 14, 2020 - added 2 commits that reference this issue
on Feb 6, 2020
Describe the solution you'd like
I think it would be very useful to be able to access
readline.Interface's currentlineandcursorvalues, as well as access the_getCursorPos()member function.It's frequently desirable to draw something outside of the current prompt during input. I am endlessly recreating actions that
readlinedoes already; specifically, tracking the cursor position (so listening for left, right, home, end, delete, backspace, ctrl+, etc, etc, ad nauseam), as well as listening to stdin for data, so that I can keep track of what the input looks like. This way, if I want to draw something outside of the prompt, I know where to return the cursor to.I also see that
readlineusesInterface._getCursorPos()internally; also very useful, and pretty much what I'm recreating withInterface.line&Interface.cursorcalculations.Being able to read
Interface.lineat any given time can be important, if you need to use that value somewhere else, but you aren't done with the prompt yet (for example, drawing an autocomplete list)But it seems awfully redundant to have to do all of this, when
readlinealready does it quite well. Honestly, by the time I'm done, I've basically created my ownreadlineinterface. Seems like a waste.I can read
Interface.line,Interface.cursor, etc... but they aren't exposed in@types/node, so it makes me feel like they are omitted for a reason.Describe alternatives you've considered
There's a couple of alternatives. One, I guess, is to just use the
Interfacemembers, and hope they don't ever change. The other is essentially creating my own custom readline interface, which really is just reinventing the wheel.Perhaps somebody could share the philosophy behind the current design? On the other hand, if they can be safely exposed in the types, I'd be happy to make a PR.