mitigate prompt issue

[TylerLeonhardt]

I needed to remove the check of PSReadLine because in the PSRL experience, whether you used ENTER or Ctrl-C, we'd still only get empty string...

This means that it would work with ENTER as ENTER would cause the cursor to go down... but Ctrl-C didn't.

I'm not sure if this is a PSRL bug that only we are exposing or actually our bug... but this makes it less ugly for sure.

The downside is that once the screen starts scrolling, an extra new line shows up.

cc @daxian-dbw if you're curious.

[SeeminglyScience]

LGTM

The downside is that once the screen starts scrolling, an extra new line shows up.

Note that this used to work at some point (on Windows). Somewhere down the line (probably with the switch to ConPTY) the cursor API's started working more like Unix and now only reports based on the current view port instead of the whole buffer. The check if the cursor position is the same is now effectively useless.

[TylerLeonhardt]

@SeeminglyScience so I removed that cursor check and that actually gives us the extra new line all the time now rather than just when the buffer can scroll... hmmm

[SeeminglyScience]

@SeeminglyScience so I removed that cursor check and that actually gives us the extra new line all the time now rather than just when the buffer can scroll... hmmm

Yeah. The cursor position reported is based on the view port instead of the buffer. The cursor check was designed assuming (because it was at one point) that it would be based on the buffer. That's why once the buffer is larger than the view port, that check no longer works as initially designed. Removing the check makes the behavior consistent, but an extra line still needs to be removed somewhere.

[TylerLeonhardt]

Yeah I think consistency sounds better here. Plus we'd be removing 2 Cursor position queries which I'm happy about. Removed those @SeeminglyScience.