-
-
Notifications
You must be signed in to change notification settings - Fork 799
-
-
Notifications
You must be signed in to change notification settings - Fork 799
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
Add custom path rendering in prompt #469
Comments
I really like this idea. Let's try a Another option would be to skip the new setting and just have
I'm not too worried about this. The cost of the default prompt putting together
No change here should be required since
That would be great! Let me know if you need any assistance. |
One option is to check
@dahlbyk So you would apply the |
I was actually thinking the other direction: let function Get-MyFancyPath ($path) {
if ($pwd.Provider.Name -ne 'FileSystem') { return "OMG! $path" }
"FileSystem:$path"
}
$GitPromptSettings.DefaultPromptPath = '$(Get-MyFancyPath $currentPath)' |
Considering Another route to go (would need to test this), would be to inject this value via a parameter in a scriptblock e.g.: $GitPromptSettings.DefaultPromptPath = { param($path) Get-MyFancyPath $path } Then this setting would not be dependent upon an implementation detail of our default prompt function. |
All good points, @rkeithhill. Note also that this whole discussion may be superseded in v2 by #340/#344 and possibly #345. In that context, I'm not overly concerned about churn in We could also check the type of |
I more concerned about getting this right for v2. In v2, I would be inclined to support only scriptblocks when we need to pass parameters to the user's script. Seems like a better approach. |
It just occurred to me one possible reason why my suggestion may not have as much validity as I originally envisioned it would. If the custom path only applies to git repository folders then the customization would only apply there. Generally customization I mentioned above is something I like to apply for the path regardless of whether the path is for source code or not. The same is true for using ~ in place of the home directory. So I guess my question is whether these values would impact non-git directories or not? If so I suppose my proposal still stands but either way perhaps Posh-Git isn't the correct place to customize the path as shown in the prompt assuming that this is essentially the only part of the path that makes sense to always carry through un-modified in general. Is there a more general way to override the "path" portion of the prompt in a way that posh-git and possibly other tools could pick up on for prompt customization? |
Nope. Another approach to implement this could be to consolidate the posh-git path logic into a (Equivalent to |
I believe this will be adequately addressed by #520 for 1.0. |
Along the same lines as with the work done for issue #386 it would be nice to more finely tune the path portion of the prompt. With older versions of posh-git I would typically hand edit my Profile to customize this but with the more extensible model through use of variables I think extending it this way will be cleaner and make it easier to setup a new custom environment up in a way that is less likely to break with updates.
Example custom path
Before:
After:
What about non file-system paths?
Perhaps it would be more convenient to have a separate
DefaultPromptFilePathTemplate
andDefaultPromptPathTemplate
just reduce the need for logical checks on the type of path for cases where the path is not a file system path.What about home directory abbreviation?
Perhaps
DefaultPromptAbbreviateHomeDirectory
can be re-implemented in terms of this template.Template vs. Function
Maybe it's more reasonable to provide a way way of supplying or overriding a function that provides the path string as a result instead of trying to embed this stuff into a expanded string template. I'm not sure what the common conventions are in the PowerShell world for providing for this type of extensibility model but I have some ideas of what may work.
I'll be happy to take a stab at contributing the change if it's something others may be interested in.
The text was updated successfully, but these errors were encountered: