-
Notifications
You must be signed in to change notification settings - Fork 511
2.0.0-insiders-834: prompt gets displayed in an endless loop #1570
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
Comments
Seems logs didn't make it via drag-and-drop. 1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip |
This seems to be the relevant part of the log:
|
@sba923 Out of curiosity:
|
Tagging @SeeminglyScience as well, since he knows much more about PSReadLine than me |
Ah yeah. That's most likely the known issue with different keyboard layouts.
The fix has already been merged (Thank you @lzybkr!) @sba923 here's the latest preview build for PSReadLine if you'd like to see if that fixes your issue. @rjmholt We should consider updating the insiders build to pull a daily until that fix gets into a beta |
@SeeminglyScience - wrong PR, the fix was merged in PowerShell/PSReadLine#768 |
Here's my setup:
If I switch VScode to PowerShell Core 6.1, the problem is still present. If I switch the keyboard layout to English while the PowerShell "integrated terminal" starts, the problem disappears -- even if I later change the keyboard layout back to French. HTH |
@sba923 - note that some key bindings won't work correctly if you switch keyboard layouts after starting PowerShell - specifically the need for Shift differs between the initial and changed keyboard layouts, e.g. Alt+1 does not require Shift in English, but does for French. I don't think this affects commonly used key bindings, but it's good to be aware of. If it does affect important bindings, I'd like the hear about it because I rely on a Win32 api that reports incorrect information after the keyboard layout change and the team needs customer feedback to justify fixing it. |
@sba923 sorry by "swtich to PSCore", I meant as the standalone app rather than in VSCode. But I think we are using an even newer version of PSReadLine than PSCore anyway. Anyway, it looks like this is fixed in PSReadLine. @SeeminglyScience maybe we can come up with a way to identify PSReadLine issues similar to how PSReadLine itself deals with them to make crashing and reporting easier? Just thinking about being more helpful to @lzybkr here :) |
@rjmholt I'm using PowerShell Core 6.1 next to Windows PowerShell 5.1, and don't have any prompt issues in either. Only the integrated terminal in VScode with any post-1.9.0-test-build of the PowerShell extension exhibits the problem. @lzybkr I find it very strange that 1) there are apps that still do their keycode-to-action-or-character mapping on their own instead of relying on OS infrastructure for that 2) changing the keyboard mapping e.g. with Win+Space while an app is running (which is just... always the case) would cause problems Where does this all tell about us getting a version of the PowerShell extension for VScode that "just works"? Do you guys have to wait for a fixed PSReadLine to be "baked into" the extension? |
Yeah this issue was just recently discovered and fixed in PSReadLine, so it hasn't made it to a beta release yet. Once that happens we can change the CI build to pull the newest release and it will be a part of the daily build bundle.
Yeah we need to handle this better, even though a similar situation is unlikely to happen again. Because PSRL is invoked via |
Great! I'll hold my breath then ;-) Can you explain why the PowerShell Core 6.1 based Integrated Terminal in VScode is affected by the issue, whereas pwsh.exe isn't? |
@sba923 I was about to give you an explanation that pwsh.exe has a lower version of PSReadLine, but it turns out it's also on beta3. According to @SteveL-MSFT this issue should be occurring in pwsh.exe 6.1.0 as well, unless you have a lower version of PSReadLine (like 1.2) overriding it somewhere. Anyway, it will be fixed in the next PSReadLine release. |
@rjmholt Here's what PSReadLine's I have on my system:
|
With https://ci.appveyor.com/api/buildjobs/ma1a8og5h1d0g5cu/artifacts/PowerShell-insiders.vsix posted yesterday I still get the endless loop... |
Just noticed that at my PS6 prompt I don't get syntax coloring, whereas it works in PS5.1 -- both with PSReadline 2.0.0-beta3. What's up, doc? |
We'll have an official preview release this week that will be installable from the extension marketplace. |
@sba923 Is it PS6.0? If so try updating to 6.1 |
I'm running 6.1.2 on all my systems |
Well... I must've done something... now even in Windows PowerShell 5.1 I don't get syntax coloring anymore either... How do I repair that? (I know, that's somewhat off-topic, but linked to experimenting with versions of PSReadLine in relationship to the present issue...) |
I hate to say, but the endless loop is still there with that preview... |
I've also encountered the endless prompt loop. |
Where do we go from here? |
What could I do to help fix that? |
IMVHO this is a showstopper for version 2.0 of the PowerShell extension for VScode. How can I help getting this resolved? |
@fMichaleczek Oh, I'm not using a French keyboard. I was playing with the debugger in vscode, and when I stopped the debugger, the integrated powershell window just started looping over and over at the prompt. It was like it couldn't exit the debugger or something and kept printing the debugger help, like when you just type ? at the prompt and it shows you the available commands. The prompt still showed the [DBG] on the prompt. I've been trying to reproduce it but haven't been able to so far. Although this last time when I stopped the debugger, pwsh crashed and vscode said: "The PowerShell session has terminated due to an error, would you like to restart it?" I think it showed a stack trace but it disappeared. |
@TylerLeonhardt What do you prefer ? A global issue about endless loop or a dedicated for each different case ? In my opinion, @rfoust has a different issue, so it must be another item. Maybe @sba923 should edit this issue's title to be more precised (keyboard layout) and to exclude race condition. |
Maybe… is that OK / "good practice"? |
Hi everyone! If you can, please try out this version of PSReadLine: To be sure you're using that version, I recommend:
Please let me know if this fixes the issue or if you need any assistance getting beta4. Keep in mind, this is not a signed version of PSRL and should only be used for testing this bug fix. |
Trying this (PSRL beta4) on a dev build of latest master (both vscode-powershell & pses):
|
@rkeithhill were you able to get it to start up at all? I can't seem to repro. Double check you've unblocked all of the files |
Yes, I got it to work but I had to comment out some of my PSRL settings in my profile |
Not sure if this is related or not, but if I'm debugging and at a breakpoint, and stop the debugging, I get this repeated over and over in a loop. It's nice the error was formatted in markup. :) Exception
P> @ EnvironmentPSReadLine: 2.0.0-beta3
Exception
P> @ |
@sba923 and @fMichaleczek were you guys able to try with the PSReadLine @TylerLeonhardt commented |
Not yet, and I must confess I was kinda scared by the first testing reports... |
@rfoust would you mind opening that as a separate issue? Thanks! |
The behaviour's probably going to be better than an infinite loop. There were changes made in the most recent update for international keyboards. But the only way we can improve it is by trying it out. |
I've replaced PSRL beta3 with beta4, made it so that @fMichaleczek's workaround is nop-ed out using:
and it seems to work (just did one quick test):
no endless loop at this point! I'll deploy this on as many systems as possible and report back. |
FWIW here's how I checked that I have only copies of PSReadLine beta4 on $env:PSModulePath:
|
On one system I'm facing something pretty weird: during execution of Microsoft.VSCode_profile.ps1, and at the TERMINAL prompt, "get-module PSReadLine" returns $null, even though the module is found on $env:PSModulePath. There must be something I don't understand / guess about the inner workings of PSES / the extension. Can someone help me out with this? |
Same problem on another machine... |
Does this give a hint on what's going on?
|
@SydneyhSmith @TylerLeonhardt I tested beta4 (On preview 2) on 2 PCs and it looks like it working. |
@sba923 We probably load PSRL after profiles are run, but if your profile runs a cmdlet from PSRL, it will cause it to load PSRL and all will be fine. |
We can close this issue now as being an external issue fixed in the next release of PSRL but @sba923 if you have more concerns regarding when PSRL gets loaded, feel free to open a new issue. |
Thanks to all who contributed to this fix! ISE's grave is getting deeper ;-) @TylerLeonhardt Yes I will open another issue for the problem where PSRL doesn't get loaded in some circumstances: when this happens not only don't I get PSRL in my VScode session, but also if I load it manually using Import-Module it doesn't behave properly (no syntax highlighting, so history backed by a file on disk....) |
Opened #1834 |
@sba923 That link in your comment is broken (leads to: https://github.com/PowerShell/vscode-powershell/issues/url) |
Fixed, thanks for the remark. |
Issue Description
When I open a folder containing PowerShell scripts, the integrated terminal displays the prompt in an endless loop, as if I would press and hold the Enter key for it to autorepeat.
Attached Logs
See 1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip
Environment Information
Visual Studio Code
PowerShell Information
Visual Studio Code Extensions
Visual Studio Code Extensions(Click to Expand)
The text was updated successfully, but these errors were encountered: