Installing and setting up PowerShell PSReadline with predictive IntelliSense

The PowerShell Team recently announced the new predictive IntelliSense feature for the excellent built-in (since version 5.1) PSReadline module.

While the PowerShell Team’s post already fully covers the functionality of the feature, I actually struggled to install this on Windows PowerShell 5.1 and would like to share my experience in case someone else encounters a similar issue.

To use the predictive IntelliSense feature you currently have to install the latest (2.2.0-beta1 at the time I’m writing this) pre-release version of the PSReadLine module in PowerShell. If you want to install a pre-release version of a module through the Install-Module Cmdlet you also have to have at least version 1.6.0 of PowerShellGet (the module that Install-Module is part of). The commands to do that are:

Install-Module PowerShellGet -AllowClobber -Force
Install-Module PSReadLine -AllowClobber -AllowPrerelease -Force

This is where the fun started for me. Already the first command failed with the following error message:

It turned out that I had to close all PowerShell instances and had to run this via the good old cmd.exe (apparently this works with PowerShell ISE or Run a.ka. WIN+R too) instead:

powershell -noprofile -command "Install-Module PowerShellGet -AllowClobber -Force"

After upgrading PowerShellGet and PSReadLine (through the same workaround). I still couldn’t enjoy predictive IntelliSense in Windows PowerShell. When trying to enable the predictions Set-PSReadLineOption -PreditionSource History I received this error:

Set-PSReadLineOption : A parameter cannot be found that matches parameter name 'PredictionSource'.

This happened even though I validated, that the correct version (2.2.0) of PSReadLine was loaded into my PowerShell session via Get-Module PSReadLine. The solution for this problem was to manually delete any older version of the PSReadLine module on my machine. After that the predictions finally started to show up in Windows PowerShell (with PowerShell 7 I did not encounter any installation problems).

Finally, in order to set up and customize the predictive IntelliSense experience I added those lines to my profile script:

#use PSReadLine only for PowerShell and VS Code
if ($host.Name -eq 'ConsoleHost' -or $host.Name -eq 'Visual Studio Code Host' ) {
    #ensure the correct version is loaded
    Import-Module PSReadline -RequiredVersion 2.2.0
    #ListView currently works only with -EditMode Windows properly
    Set-PSReadLineOption -EditMode Windows
    if ($host.Version.Major -eq 7){
        #only PS 7 supports HistoryAndPlugin
        Set-PSReadLineOption -PredictionSource HistoryAndPlugin
        #use history as the prediction source on 5.1
        Set-PSReadLineOption -PredictionSource History
    #add background color to the prediction preview
    Set-PSReadLineOption -Colors @{InlinePrediction = "$([char]0x1b)[36;7;238m]"}
    #change the key to accept suggestions (default is right arrow)
    Set-PSReadLineKeyHandler -Function AcceptSuggestion -Key 'ALT+r'

Photo Credit: skipmoore Flickr via Compfight cc

One thought on “Installing and setting up PowerShell PSReadline with predictive IntelliSense

  1. You’re not Upgrading a module or forcing overwrite of an older version when you use -AllowClobber. That switch doesn’t enable overwriting of previous installs, that’s not what it’s intended to do. AllowClober is for when you’re installing a module that has Cmdlet names which are Ambiguous (identical) to the names of cmdlets that exist in modules that are already installed. It’s checking for the cmdlets inside of a module, it’s not the name OF the module that contains the cmdlets. When used, this switch will allow you to install a module that does have identical commands and then YOU have to know that if at any time, you Import both of those modules containing the ambiguous cmdlets, then the last module that was imported will always win. That is, when you use one of the ambiguous cmdlets, the module you imported most recently will be used. You can also manually assign Aliases for the ambiguous cmdlets if you really do need to use both the modules at the same time and don’t want the confusion. Or you can also use Remove-Module to un-import one of the modules once it’s job is done.

    I just thought I’d mention it because, sometimes people read pages like this and don’t fully understand the commands they are copy/pasting. In the case of -AllowClobber, if they don’t realize it, then using this switch will cancel a built-in warning which would normally tell the user that some ambiguous cmdlets exist.


I'd love to hear what you think

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s