Skip to content
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

Move simple prompt to the module. #217

Closed
thezim opened this issue Sep 8, 2015 · 13 comments
Closed

Move simple prompt to the module. #217

thezim opened this issue Sep 8, 2015 · 13 comments
Milestone

Comments

@thezim
Copy link

thezim commented Sep 8, 2015

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
Copy link
Collaborator

rkeithhill commented Sep 15, 2016

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
Copy link
Owner

dahlbyk commented Sep 21, 2016

(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
Copy link
Collaborator

lzybkr commented Sep 22, 2016

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
Copy link
Collaborator

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.

@dahlbyk dahlbyk added this to the v1.0 milestone Jan 2, 2017
@dahlbyk dahlbyk mentioned this issue Jan 2, 2017
13 tasks
@rkeithhill
Copy link
Collaborator

rkeithhill commented Jan 3, 2017

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.

rkeithhill added a commit that referenced this issue Jan 3, 2017
Fix #217.  This would only export the prompt function if the prompt function is still set to the default.
@lzybkr
Copy link
Collaborator

lzybkr commented Jan 3, 2017

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
Copy link
Collaborator

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
Copy link
Collaborator

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:
image

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?
image

@lzybkr
Copy link
Collaborator

lzybkr commented Jan 3, 2017

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

@rkeithhill
Copy link
Collaborator

rkeithhill commented Jan 3, 2017

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.

@lzybkr
Copy link
Collaborator

lzybkr commented Jan 3, 2017

In Emacs mode, try 'Measure-<TAB> <TAB>. The possible completions are displayed and the prompt appears **below** the possible completions. If you don't set-ExtraPromptLineCount` correctly, the extra line won't be there, e.g.

@ C:\Users\jasonsh
#522 PS> Measure-
Measure-Command         Measure-Object          Measure-VM              Measure-VMReplication   Measure-VMResourcePool
#522 PS> Measure-

@rkeithhill
Copy link
Collaborator

rkeithhill commented Jan 3, 2017

I use the Windows edit mode so that is probably why I haven't seen any problems.

@dahlbyk
Copy link
Owner

dahlbyk commented Jan 4, 2017

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?

From #349 (comment):

I'd prefer not to change the default posh-git prompt since it's what non-customizing users (like me 😀) are now used to. But we could add PromptPrefix and PromptSuffix (and PromptDebug*ix?) to $GitPromptSettings to make this particular arrangement easier to achieve without modifying prompt.

Keeping the default prompt reasonably simple also means we can skip the ExtraPromptLineCount fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants