Move simple prompt to the module.

[thezim]

I frequently use PowerShell for many tasks and have many modules that I do not load automatically in my profile. When loading posh-git I have to manually execute the simple prompt code. Moving the simple prompt to the module make the it more user friendly.

[rkeithhill]

Moving the simple prompt to the module make the it more user friendly.

In that case, it would have to be optional and off by default. Many folks I know have highly customized prompts and with PowerShell there can only be one prompt function. If importing posh-git stomped their prompt function, they wouldn't be happy. Other than that, it seems like a reasonable request.

[dahlbyk]

(First, terribly sorry for basically ignoring this for a year @thezim!)

As I mentioned in the PowerLine issue referenced above...

I've never been particularly happy with how posh-git actually integrates into the prompt - replacing prompt feels pretty hacky (and in the Chocolatey install it's even worse), so if there is a better way to handle this in newer versions of PowerShell (or a community convention I've missed), please let me know.

posh-git could certainly expose its basic prompt function, but as @rkeithhill we need to tread lightly on existing prompts. In theory we could compare the existing prompt function against content/hash of known default prompt functions and only override in that case? I've never really found a good balance, which is why we've never really deviated from what was put in place years ago.

[lzybkr]

To get the default prompt, you can use

[runspace]::DefaultRunspace.InitialSessionState.Commands['prompt'].Definition

There are some rare cases where this might not work in some hosts, but it should work in powershell.exe and powershell_ise.exe starting with V3.

[rkeithhill]

We can use (Get-Command prompt).Definition to get the current prompt function in all versions. So yeah, we could "stash" a copy of version strings for v2/3/4/5/6 to check against. If the user does not have a customized prompt function, then we could provide/export a prompt function.

However, in the scenario where the user remove's the posh-git module, we should attempt to restore the original prompt function.

[rkeithhill]

I have an implementation that I have submitted as PR #349 for folks to look at. The one issue with it is that because it exports prompt, removing posh-git will remove the prompt function altogether. This leaves with the prompt PS> which is what PowerShell resorts to when there is no prompt function.

I've been trying to restore the prompt in OnRemove but that handler gets called before the module has fully unloaded. So even if I put the prompt function back to the original, the restored prompt function still gets removed later in the unload process. :-(

Perhaps this isn't that big of a deal? Not sure how often folks would do a Remove-Module posh-git.

[lzybkr]

Instead of exporting the function, why not use Set-Item function:prompt $promptScriptBlock?

If you are defining a prompt for folks, do look closely at how the default prompt function changes when debugging, see:
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/debugger/debugger.cs#L1644
and
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/debugger/debugger.cs#L3940

[rkeithhill]

That works better! Thx.

The debug prompt changes only seem to take effect when the default prompt is in place. Are you suggesting we provide the same debug info in the posh-git prompt during debugging? I think we could do that pretty easily, just want to make sure that's what you're suggesting.

[rkeithhill]

Hmm, it appears the debug prompt from line 3940 - for remote process debugging - always stomps the current prompt (default or not). The prompt for locally debugging at 1644 does not seem to stomp a custom prompt. So it looks like we only need to implement this one - which is easier to implement. :-)

However, I wonder if we should provide a prompt that is split to two lines by default. For example, this is more or less taken from profile.example.ps1:

But what if we supplied a default prompt that is two lines and puts the prompt cursor on a newline thereby giving folks more room to type commands?

[lzybkr]

My preferred prompt spans two lines. If you make that the default, you need to tell PSReadline with Set-PSReadlineOption -ExtraPromptLineCount 1.

[rkeithhill]

Hmm, I've been using a two line prompt for over a year without setting that PSReadline option. And I haven't noticed any ill effects. Looking at the help on this parameter:

Specifies the number of extra lines. Specify a value for this parameter if your prompt spans more 
than one line, and you want extra lines to be available when PSReadline displays the prompt after 
showing some output, such as when PSReadline returns a list of completions.

But if I get PSReadline to display a long list of completions (say contents of \windows) when I complete or esc, both lines of my prompt are displayed.