Brace expansions #366
Brace expansions #366
Conversation
| :LEFT_BRACE | ||
| end | ||
| end | ||
| rule(/#{BRACE_EXPANSION_ESCAPABLES.to_negative_regexp}+/, :brace_expansion) do |t| |
There was a problem hiding this comment.
Metrics/LineLength: Line is too long. [86/80]
| gitsh.type(':echo f{{e,i,o}e,um}') | ||
|
|
||
| expect(gitsh).to output_no_errors | ||
| expect(gitsh).to output(/fee fie foe fum/) |
df856ec
to
feeb859
Compare
6876bde
to
eb0f483
Compare
feeb859
to
d36d4c1
Compare
|
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:
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 There are other similar shorthands, which I use less often but others might not, like Three solutions I can think of:
Following the principal of least astonishment, I'm inclined to do the first one. What do other gitsh users things? /cc @sharplet @mike-burns |
|
Huh I had no idea: (zsh) I'm in favor of that, option (1). |
|
I’m also in favour of option 1. I regularly use this syntax to inspect my |
d36d4c1
to
a01b038
Compare
eb0f483
to
a9bb2ad
Compare
|
Finally got back to this and (pairing with @seanpdoyle) figured out how to make this behave more like general-purpose shells. As of now:
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. |
c19ced0
to
bff4228
Compare
Expect the first param of a multi-line call to be indented one step more than the previous line.
Let's stick with `[:foo, :bar]`; I find it easier to read than `%i[foo bar]`
This commit 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.
This change paves the way for various kinds of globbing and argument
expansion which could allow a single argument to produce multiple values.
For example, in GNU Bash the argument `h{i,o}p` would be expanded to the two
arguments `hip hop`.
bff4228
to
d411f54
Compare
| mv foo_{old,new}.txt | ||
| mv foo_old.txt foo_new.txt | ||
| .Ed | ||
| . |
There was a problem hiding this comment.
Should we mention the special cases in here?
e.g. `:echo h{i,o}p` produces `hip hop`.
This is similar to GNU Bash and other general-purpose shells:
- Expansions can be nested.
- Braces with one option do not expand, e.g. `{x}` is a literal.
- Empty braces to not expand, i.e. `{}` is a literal.
And different in a few ways:
- Spaces inside of expansions don't need to be escaped.
- Quotes inside of expansions are literals, not string delimiters.
- $s inside of expansions are literals, not variable delimiters.
- Expansions can't be used inside of variable names.
- Un-matched braces must be escaped.
6a28ae2
to
770d59d
Compare
e.g.
:echo h{i,o}pproduceship 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:
{x}is like'x'.{}is like''.There are also a couple of differences that we might want to consider changing:
echo $FOO{1,2}is likeecho $FOO1 $FOO2(butecho ${FOO1,FOO2}is an error).To support this new behaviour this PR also updates all of the various
Gitsh::Arguments::*classes'#valuemethods to produce Arrays instead of single values. TheGitsh::ArgumentListclass takes on the responsibility of flattening the results.Begins to address #145