get windows support locked down

[mroth]

There probably isn't too much to do here, but it requires a greater understanding on my part of what a typical Windows git CLI environment looks like, so help from Windows developers is greatly requested.

• get Windows integration testing working via Appveyor
• resolve existing file path issues (File path separator gets removed #10)
• additional shell support needed? (Powershell? something else?)

Figuring out a Windows based integration testing environment is a good first step towards seeing what is broken and what isn't.

[stereokai]

At the moment there are three native shells on Windows: CMD, Powershell and Bash on Windows.

Bash is probably irrelevant, because it is Linux and is already supported by scmpuff.

I would like to help bring scmpuff to CMD and Powershell. How can I help?

[mroth]

Hi @stereokai, excited for the help!

In theory, adding new shells should be relatively simple: if you look at /commands/inits/data directory, you'll see the actual wrapper scripts used for bash/zsh -- it's fairly minimal. We'd need new versions of those for any new shells you wanted supported. Once those were working, the scmpuff init command could be modified to do shell detection and output the correct wrapper script.

That said, I believe a very important precursor is getting the Integration Testing up and running via Appveyor, so we can see the effect of the changes as we develop (and I suspect we will see some minor bugs even in bash in windows as a result, since the tests will be running there for the first time).

[stereokai]

Next week I will try to translate the init script to Powershell.

For the uninitiated, can you please help me figure out:

eval "$(scmpuff expand -- "$SCMPUFF_GIT_CMD" "$@")";;

• eval is like the eval() of JavaScript, right?
• What is the $(...) notation for?
• With $@ you are forwarding the original parameters to the git command stored in $SCMPUFF_GIT_CMD, right?
• What is the ;; double semicolon for?

Cheers! Let's get this going :)

[stereokai]

@mroth can you help me out? :)

[stereokai]

@mroth I have the Powershell script nailed. I haven't actually tested it yet because I need to download Go and compile scmpuff first, but it should work.

Remove-Item alias:\git
Remove-Item function:\git

$SCMPUFF_GIT_CMD = Get-Command git | Select-Object -ExpandProperty Definition

function git {
  switch -regex -casesensitive($args[0]) {
    "^(commit|blame|log|rebase|merge)$" {
      & scmpuff expand -- $SCMPUFF_GIT_CMD $args
    }
    "^(checkout|diff|rm|reset)$" {
      & scmpuff expand --relative -- $SCMPUFF_GIT_CMD $args
    }
    "^add$" {
      & scmpuff expand -- $SCMPUFF_GIT_CMD $args
      scmpuff_status
    }
    default {
      & $SCMPUFF_GIT_CMD $args
    }
  }
}

[stereokai]

@mroth Alright I compiled the scmpuff command on my computer, got it running.

When I'm running scmpuff status in both CMD and Powershell, I'm getting:

?[2;37m#?[0m On branch: ?[1mRD-1578-add-company-name-post-signup  ?[2;37m|  [
?[0m*?[2;37m]?[0m => $e*
?[2;37m#?[0m
?[1;32m➤?[0m Changes not staged for commit
?[0;32m#?[0m
?[0;32m#?[0m     ?[0;32m  modified: ?[2;37m [?[0m1?[2;37m] ?[0;32msrc\app\dir
ectives\header\header.html?[0m
?[0;32m#?[0m

[stereokai]

Okay I have done some research into this and I have a solution.

First I looked into ANSI colors support in Powershell and CMD. Before Windows 10, the built-in terminals did not support ANSI color codes. In 2015, Microsoft has added basic support to Windows 10 only, and it looks like this (excerpt from here):

echo �[101;93m NORMAL FOREGROUND COLORS �[0m
echo ^<ESC^>[30m �[30mBlack�[0m (black)
echo ^<ESC^>[31m �[31mRed�[0m
echo ^<ESC^>[32m �[32mGreen�[0m
echo ^<ESC^>[33m �[33mYellow�[0m

Then I looked for the part in your code where you printing output with color, ie.:

	return fmt.Sprintf(
		"  %s|  %s%s%s",
		colorMap[dark], colorMap[neu], diff, colorMap[rst],
	)

Using the constants from constants.go.

I have found an alternative: fatih/color is an actively maintained cross-platform color library fro Go.

I guess it's time for some experimenting.

[mroth]

Oh interesting! I hadn't thought about the color output being platform specific, but that makes sense. Switching to a library for the color code constants will also probably present an opportunity to clean up and restructure the output UI code (which is currently very influenced by being a port from scmbreeze).

[stereokai]

Alright. I don't think it's going to be that hard to do. Unfortunately I don't have a Mac to test on. I could submit a pull request with that color library and then you would pick up from there?

By the way, I would definitely need some help translating the scmpuff_status script.

[stereokai]

BTW, what is the build command for scmpuff? would be good adding it to the docs. I guessed go build -o scmpuff github.com/mroth/scmpuff.

[stereokai]

@mroth I used go-colorable and got scmpuff status working. It was very straightforward.

However I couldn't get any expand command working (it doesn't work also without the color fix).

When I'm doing scmpuff expand -- git log, for exmaple, I am getting back: git log in the commandline. I don't think this is what scmpuff is supposed to do :)

[mroth]

I could submit a pull request with that color library and then you would pick up from there?

Yeah, I think we should probably abstract switching to a color library into it's own PR. It can happen independently of the cross platform work

BTW, what is the build command for scmpuff?

rake build, assuming you have the Ruby environment set up, which I use to manage the development tasks (and integration tests) -- via the Rakefile if you want to see what's going on under the hood.

When I'm doing scmpuff expand -- git log, for exmaple, I am getting back: git log in the commandline. I don't think this is what scmpuff is supposed to do :)

Actually, that's working correctly! scmpuff expand only should expand the numeric arguments into the filenames and return the results. E.g. replacing git add 1 with git add foo.txt. However, without the scmpuff_status script, it won't have anything to substitute, because the environment variables won't have been set. If you look at the Aruba integration tests for expand in features/command_expand.txt you'll see some examples.

By the way, I would definitely need some help translating the scmpuff_status script.

This is going to be trickier since I don't have a Windows dev environment set up, but I think this places even more importance on getting AppVeyor continuous integration testing set up (which should probably also be it's own PR, as just getting it up and running with the existing bash environment will probably take a little doing). Once continuous integration is set up, it will be easier for us to test the changes since with every commit in a PR we'll see what works and what doesn't across all environments (I think there may be a little complexity getting the Aruba tests working properly on Windows too, so this is a task in itself! But one that will greatly benefit scmpuff even before we start adding new shells).

What timezone are you in @stereokai ? If you would like, we could also do a pairing session via videoconference or something at some point to go over the architecture stuff if you want to get really involved in helping making all this happen!