Brace expansions

[georgebrock]

e.g. :echo h{i,o}p produces hip hop.

The implementation differs from GNU Bash and other general purpose shells in a few ways. First, there are a few deliberate things that I think improve the consistency of the language:

• Single-option expansions behave like strings, e.g. {x} is like 'x'.
• Zero-option expansions behave like empty strings, e.g. {} is like ''.
• Unclosed braces cause a parse error, not a literal brace.
• Spaces inside of expansions don't need to be escaped.
• Quotes inside of expansions are literals not string delimiters, which mirrors the fact that braces inside of quoted strings are literals not expansion delimiters.

There are also a couple of differences that we might want to consider changing:

• Expansions can't be used inside of variable names, e.g. in GNU Bash echo $FOO{1,2} is like echo $FOO1 $FOO2 (but echo ${FOO1,FOO2} is an error).

To support this new behaviour this PR also updates all of the various Gitsh::Arguments::* classes' #value methods to produce Arrays instead of single values. The Gitsh::ArgumentList class takes on the responsibility of flattening the results.

Begins to address #145

[georgebrock]

I've been using this version for a few days, and I think I want to revisit some of the deliberate differences from how GNU Bash et al. handle things. Specifically these two:

• Single-option expansions behave like strings, e.g. {x} is like 'x'.
• Zero-option expansions behave like empty strings, e.g. {} is like ''.

I'll frequently diff my local branch against upstream, e.g. after a complex interactive rebase to make sure I didn't introduce accidental changes. The easiest way I know of doing that is diff @{u} @. After this change, that's pretty cumbersome (either diff '@{u}' @ or diff @\{u\}).

There are other similar shorthands, which I use less often but others might not, like @{-1}.

Three solutions I can think of:

1. Do the Bash-like thing, and treat {} or {x} as literals, only doing expansion when there's at least one comma.
2. Introduce a magic variable for upstream, e.g. $_u, and advise gitsh users to use that.
3. Leave things as they are, alias diff @{u} @ to diffu for my own use case, and trust others will find similar work arounds.

Following the principal of least astonishment, I'm inclined to do the first one.

What do other gitsh users things? /cc @sharplet @mike-burns

[mike-burns]

Huh I had no idea:

~% echo a.{b,c}
a.b a.c
~% echo a.{b}
a.{b}
~% echo a.{} 
a.{}

(zsh)

I'm in favor of that, option (1).

[sharplet]

I’m also in favour of option 1. I regularly use this syntax to inspect my stash:

git show stash@{1} # show me the next stash below the top

[georgebrock]

Finally got back to this and (pairing with @seanpdoyle) figured out how to make this behave more like general-purpose shells. As of now:

• Two or more items in braces will expand, e.g. {a,b}1 is equivalent to a1 b1
• One item in braces will not expand, e.g. @{u} is a literal argument
• Empty braces will not expand, e.g. {} is a literal argument

We had to make some minor compromises to get there, specifically an unmatched brace is now a parse error, but it's possible to work around by using an escaped brace e.g.

gitsh@ :echo }
gitsh: parse error
gitsh@ :echo \}
}