Add Go prompt

[seanhagen]

Adds the version of Go as reported by go version as a prompt segment:

[seanhagen]

Actually, just realized there's a better way to do this based on what you said.

Instead of always showing the version based on the go version command, only show the version if you're in a folder that has a go.mod file ( or there is a go.mod in a folder above the one you're in ). And instead of showing the output of go version show the version from go.mod?

And you're right about it being noise, I'm already considering turning it off and I've only had it for a few days now. I think what's more useful is showing the version of Go only if you're in a Go project ( folder with go.mod, or a child folder inside that project ); and changing the color if the output of go version is lower than what's in the go.mod.

That way, you can see immediately if the version of Go you have is the right one when you check out a project ( or if the version of Go you have installed/configured with a version manager like asdf isn't the right one for the project ).

Also, maybe a flag so that it only shows if the version of Go you have isn't high enough for the project that you're in; kind of the way the Git stuff only shows if there's changes?

[bobthecow]

Yep, that sounds consistent, and like it'd be a much better experience :)

[seanhagen]

Okay, changed it so it up a bit, here's what changed.

First up, I added two variables: theme_display_go_show_wrong_version and theme_display_go_actual. More on those in a bit.

Next, check to see if we're in a Go project by looking for a go.mod file. If one isn't found don't display the Go version -- like how the Git prompt works.

Next, check if there's a Go executable. Not worrying about asdf or virtualgo, just if there is a binary called go in the PATH. If there is a Go executable, use it to grab the current version.

After that, check if the version reported by go meets the required version from the go.mod.

What the prompt displays depends on three things:

• the value in theme_display_go_show_wrong_version
• the value in theme_display_go_actual
• the version of Go from go version and what's in the go.mod

If theme_display_go_show_wrong_version is set to "yes" and the version reported by go isn't equal to or higher than the version from the go.mod file the version is printed out in red ( or whatever color color_rvm is set to ). I thought this might be useful, as it lets the user know that the version of Go they're currently using can't ( or at least probably can't ) compile this project.

After that, we check the value of theme_display_go_actual; it can be set to "no", "yes", or "diff". If it's set to "no", the version from the go.mod file is displayed. If it's set to "yes", the version from go version is displayed.

If it's set to "diff", it shows just the version from go.mod if it matches go version, or the go.mod version followed by the actual go version version. For example, if the version set in go.mod is "1.12" and the version reported by go version is "1.18" it will show "1.12 (1.18)".

With those two variables the user can control:

• if they get a warning in the prompt if the version from go version isn't high enough for the project
• if they see just the version from go.mod, just the version from go version, or both ( if they're not the same )

[seanhagen]

@bobthecow I think it's ready for another look now

[seanhagen]

i think we can cover all of those with just three options:

* `off`: never display any golang segment.
* `on`: regular colored segment with required version, or error colored segment, also with required version.
* `verbose`: regular colored segment with required version, or "error" colored segment with required version _and actual version_.

i could also see just the golang segment, but no version number, for the non-error state in on. i don't do enough go development to know whether this is okay, or if we need to know the version number in a non-error state.

I went with keeping the version number always visible, even in the "ok" state because it's a piece of information that's handy to surface -- probably for the same reasons the Ruby segment does

[seanhagen]

Lemme know if there is anything else that needs tweaking or polishing!

[fabiomargarido]

Hey there. It's been almost 2 years since this has seen any activity, are there still any plans to include these changes? I personally think this is helpful and have been using it (locally modifying my git copy) for quite some time.

[bobthecow]

you're right. this should have been merged a long time ago 😞

[fabiomargarido]

no problems, thanks for the quick response and for integrating it 🎉