PSReadLine
PSReadLine copied to clipboard
PowerShell
Multi-line text allows parts of Line 2 to bleed into Line 4 (if line 4 length is shorter than line 2 length)
Prerequisites
- [X] Write a descriptive title.
- [X] Make sure you are able to repro it on the latest released version
- [X] Search the existing issues, especially the pinned issues.
Exception report
No Exception, just a visual bug / Bleed-through of text
Previous analysis with Jan on Oh-my-posh: https://github.com/JanDeDobbeleer/oh-my-posh/issues/2911
Screenshot
Environment data
PS Version: 5.1.22621.436
PS HostName: ConsoleHost
PSReadLine Version: 2.2.6
PSReadLine EditMode: Windows
OS: 10.0.22621.1 (WinBuild.160101.0800)
BufferWidth: 345
BufferHeight: 47
Steps to reproduce
Select multi-line text, like this one:
function Get-StrictMode {
# returns the currently set StrictMode version 1, 2, 3
# or 0 if StrictMode is off.
try { $xyz = @(1); $null = ($null -eq $xyz[2]) }
catch { return 3 }
try { 'Not-a-Date'.Year }
catch { return 2 }
try { $null = ($undefined -gt 1) }
catch { return 1 }
return 0
}
Paste it into a session that has Oh-my-posh loaded with TransientPrompt enabled, the output is this:
[2022-10-08 15:48:44]❯ function Get-StrictMode { > # returns the currently set StrictMode version 1, 2, 3 > # or 0 if StrictMode is off.
> try { $xyz = @(1); $null = ($null -eq $xyz[2]) }, 2, 3
> catch { return 3 }de is off.
> try { $xyz = @(1); $null = ($null -eq $xyz[2]) }
> try { 'Not-a-Date'.Year }
> catch { return 2 }
> try { 'Not-a-Date'.Year }
> try { $null = ($undefined -gt 1) }
> catch { return 1 }
> try { $null = ($undefined -gt 1) }
> return 0return 1 }
> }
Expected behavior
Output displayed as-is
Actual behavior
On line 4, the text "de is off." is repeated from line 2. I could observe this on other terminals (Windows Terminal) with multi-line text as well.
This has no impact on the execution, but is a visual bug on the terminal.
Now that I see my screenshot, I noticed that most of the output is garbled/repeated...
Are you pasting with mouse right click? Using Ctrl+v for pasting should give you the expected result.
The right-clicking issue is old, tracking by #579.
I am indeed right clicking. - didn't know this was known for that long 😉
This seems to be indifferent to the Right-Click VS CTRL+V method, at least in PowerShell 7 in VSCode:
- First: Right click method
- Second: CTRL+V
- Third: Code selected/copied with CTRL+C before running
here my local environment:
PowerShell Module PathsC:\Users\David\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\program files\windowsapps\microsoft.powershell_7.2.6.0_x64__8wekyb3d8bbwe\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
c:\Users\David\.vscode\extensions\ms-vscode.powershell-preview-2022.10.0\modules
PowerShell Version Table
Name Value
---- -----
PSVersion 7.2.6
PSEdition Core
GitCommitId 7.2.6
OS Microsoft Windows 10.0.22623
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
PowerShell Host
Name : Visual Studio Code Host
Version : 2022.10.0
InstanceId : c3995ce1-641a-4bb4-bd0b-0db8a86102eb
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-GB
CurrentUICulture : en-GB
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace
Installed NET Frameworks
PSChildName Version Release
----------- ------- -------
v2.0.50727 2.0.50727.4927
v3.0 3.0.30729.4926
Windows Communication Foundation 3.0.4506.4926
Windows Presentation Foundation 3.0.6920.4902
v3.5 3.5.30729.4926
Client 4.8.09032 533320
Full 4.8.09032 533320
Client 4.0.0.0
I can reproduce the same in PowerShell 5.1 (and 7.2.6) in Windows Terminal
This seems to be indifferent to the Right-Click VS CTRL+V method, at least in PowerShell 7 in VSCode: I can reproduce the same in PowerShell 5.1 (and 7.2.6) in Windows Terminal
The given information is a little inconsistent. Can you confirm if this happens with both VSCode integrated console and pwsh.exe in Windows Terminal?
Paste it into a session that has Oh-my-posh loaded with TransientPrompt enabled
Can you please provide the step to enable TransientPrompt?
Adoption of the transient prompt is not yet very widespread, so I have uploaded my own file for convenience ParagnosterPlus2.omp.zip
AFAIK, having a Theme that supports it and running Enable-PoshTransientPrompt (once) did the trick for me.
I have repo'd in the following terminals:
- VsCode: PowerShell Extension terminal - set to
Powershell Core (x64)at the moment as using my theme locks up the Key Handler somehow when the environment is set toWindows PowerShell (x64) - VsCode: PowerShell 7.2.6
- VsCode: PowerShell 5.1
- Windows Terminal: PowerShell 5.1
- Windows Terminal: PowerShell 7.2.6
The above environment was taken from the pwsh session in Windows Terminal
My VsCode terminals
"terminal.integrated.profiles.windows": {
"PowerShell 5": {
"path": "C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"args": [
"-noExit"
]
},
"PowerShell 7": {
"path": "pwsh.exe",
"args": [
"-noExit"
]
},
},
In my case I am using a multiline oh-my-posh prompt. The issue occurs as well when running some command that is spanning across multiple lines. Only the first line is cleaned up.
oh-my-posh-line1>
oh-my-posh-line2> az rest --uri /subscriptions/mysubscription/providers/Microsoft.Web/locations/westeurope/managedApis/sap?api-version=2016-06-01
With 06-01 on the second line, pressing enter, leaves 06-01 on the second line:
transient-prompt> az rest --uri /subscriptions/mysubscription/providers/Microsoft.Web/locations/westeurope/managedApis/sap?api-version=2016-06-01 06-01
I guess the transient writing only clears the first oh-my-posh-line1> line but forgets that theoretically the command can span multiple lines beyond.
Second example: When executing
echo ${
"carl" = "3"
}
Only echo ${ gets cleared. I.e. only the first line gets cleared, leaving the rest cluttering the output.
@daxian-dbw I see you tagged this issue with the label "resolution-duplicate", but isn't the issue I am experiencing different? Should I create a new issue for my issue?
@cveld The issue you described here is different from the original issue that @DEberhardt opened.
With 06-01 on the second line, pressing enter, leaves 06-01 on the second line:
It looks oh-my-posh register its own handler for the key Enter: https://github.com/JanDeDobbeleer/oh-my-posh/blob/e45cd7ea17636a2d6c527eeda7d9b609c21c2851/src/shell/scripts/omp.ps1#L134-L159
I think you should open an issue in the oh-my-posh repo instead.
@daxian-dbw I just had a good debug session on our end to see what could cause the issue but without success. Yes, we register a handler for the Enter key, but it doesn't do magical things other than already fix 2 bugs (suggestion list troubles and UTF-8 problems when using InvokePrompt()) coming from PSReadLine.
All we want to do is display a different, more compact prompt on enter. This keeps the historical view in the terminal nice and clean, as you don't necessarily care about the previous state of your folder etc going forward. Therefore we make use of InvokePrompt(), which I believe serves this use-case just right. In our prompt function we evaluate the lines of the newly generated prompt every time, so if it's currently 2 lines, but the transient prompt is only 1 line, we set the extraPromptLineCount correctly. This implies it toggles between 0 or more every time we call InvokePrompt().
Provided this is what PSReadLine needs, it is solely responsible to reload the prompt correctly and display the current command and next prompt without issues (on AcceptLine() here), regardless of wether or not the user is in a prediction list, regular command, etc. That's why we have and rely on PSReadLine in the first place.
Unless you can point to what we should not or be doing differently in our handler, this is a bug for PSReadLine.
This seems to be the same root cause: https://github.com/JanDeDobbeleer/oh-my-posh/issues/4710