-
Notifications
You must be signed in to change notification settings - Fork 234
Print prompt and command when WriteInputToHost
is true
#1691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@PrzemyslawKlys, @JustinGrote, and @SeeminglyScience what do you think of this? I'm not sure I like it to be quite honest. |
LGTM to be honest. The side effects of running |
The only other way it could work is to capture the user's prompt every time and then replicate the characters as-is to avoid side-effects. I think if you have a prompt that isn't idempotent youre going to have other problems and this would just reveal them, so I don't think it's that big of a deal. LGTM, this is how I would have solved it too :) EDIT: Alternatively, maybe issue an ANSI command to move the cursor back to where the existing prompt is before running the F8? Or does it always display on a newline? |
Hm, I'll see if I can make this work but I'm not sure with the current implementation. |
We are cancelling PSReadLine for this right? When we do, it saves the current REPL input for us to restore later. I believe that's done automatically by PSRL. All we should need to do is:
That should result in the desired behavior. Edit: Now that I think about it though, the actual writing of if (ShouldInterruptForeground && WriteInputToHost)
{
CancelPSReadLineAndWait();
WritePrompt();
WriteInputText();
NowInvoke();
} |
@SeeminglyScience There is something wrong with it. I'm debugging. I managed to accidentally reproduce PowerShell/vscode-powershell#3751 while just trying to manually save and then restore the user's input, not knowing what you just told me about PSReadLine magically doing it for us. |
@SeeminglyScience As far as I can see we do not wait for PSRL to cancel. Only entry-point is: PowerShellEditorServices/src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs Lines 675 to 678 in f890a75
And it's just being synchronously called: PowerShellEditorServices/src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs Lines 623 to 646 in f890a75
|
That very well could be fine as well. The only reason we had to do that before was because |
This part is fine and easy. It's saving the existing input (if there is any) and then restoring it that's proving tricky. |
Ah right that code is already where I was suggesting. For some reason I thought it was in the
|
Umm nevermind...it's working perfectly once I combined it with my fix in #1690 |
ff88d24
to
ba0f25b
Compare
WTF now it's not working. What did I do!? |
Consistently? Or we got one of them super fun race conditions goin' on? |
Super fun race condition, it's half working. Mostly works, can sometimes cause it to lose the input. |
ba0f25b
to
8d8d3ed
Compare
8d8d3ed
to
44880b6
Compare
WriteInputToHost
is true
It definitely works much better than it was, and the occasional loss of input is not due to this change but is an extant bug, so marking as ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This fixes PowerShell/vscode-powershell#3786 by simply printing the prompt before the input of the command run by F8. It's almost cosmetic-only, except it does invoke the user's
prompt
function again which could have side-effects. What's more, we'll still have an empty prompt before the invocation; however, I believe that to be an accurate representation of what's happening because that prompt is canceled per my explanation here: PowerShell/vscode-powershell#3786 (comment)