Support backslash commands

[georgebrock]

Mike's original spike supported the following backslash commands:

• \e Open editor
• \! Run in shell
• \? Help (for gitsh)
• \h Help (for git commands)
• \c Change directory
• \q Quit

[mike-burns]

Also fun: something to make pairing easier.

[georgebrock]

Would something similar to environment variables solve this? They would be session-level overrides for git config parameters.

export user.name = "George Brocklehurst & Mike Burns"
export user.email = pair+george+mike@thoughtbot.com
commit -m foo
commit -m bar

Would execute:

git -c user.name=… user.email=… commit -m foo
git -c user.name=… user.email=… commit -m bar

(We could also support $var for reading from config variables, which would make variables in scripts quite simple)

[georgebrock]

All git config variables have a section (user.email, core.editor, etc.) so having a shared namespace for config variables and script variables seems reasonable. Anything that doesn't have a section won't be visible to git commands anyway:

$ git -c foo=1 config foo
error: key does not contain a section: foo
$ git -c foo.bar=1 config foo.bar
1

For variables with a prefix, an :export (\export?) command could have similar semantics to the sh export command: the exported variable would be added to the environment of subsequently executed commands. Exporting a variable with no prefix could cause an error.

I'm picturing something like this:

gitsh@ foo.bar=1
gitsh@ status
# Executes `git status`
gitsh@ :export bar=1
error: key does not contain a section: bar
gitsh@ status
# Executes `git status`
gitsh@ :export foo.bar
gitsh@ status
# Executes `git -c foo.bar=1 status`

[mike-burns]

Will there also be a way to set a variable that is not exported to git?

gitsh@ :export gitsh.format="%p "
@ :set project=rcm
@ add ${project}*tar.gz

[georgebrock]

I was thinking that a Unix-shell-like project=rcm (with no colon command) would suffice.

[mike-burns]

OK yeah, that'd be fine too, though a little inconsistent: "you must precede your gitsh-specific command with : unless it contains other characters that could make it unambiguous".

[pbrisbin]

Why do we need the colon?

@ project=rcm
@ export foo.bar=1
@ status
(git -c foo.bar=1 status)
@ project
"rcm"
@ foo.bar
1
@ flimflop
Unrecognized error...

Otherwise, I'd favor explicit :set (or maybe :let?) and :export commands.

[georgebrock]

More thoughts from the whiteboard with @mike-burns. Here's what we think we want:

• gitsh supports variables ($foo) and backticks (echo Hello) as part of any command.

• All other instructions to gitsh are prefixed with colons (including things like conditional statements and function definition).

• The :set command and $ can set and read both gitsh variables and git config variables, the difference is whether the variable name contains a dot ($foo is a gitsh variable, $foo.bar is a git config variable).

• Anything set with :set works like a session variable; when you close the shell it no longer applies.

• There should be functions:

  :function pair name nick {
    :set user.name "George Brocklehurst and $name"
    :set user.email "support+george+$nick@thoughtbot.com"
    :set gitsh.prompt "$nick+$gitsh.prompt"
  }
  
  # usage:
  # gitsh@ pair "Mike Burns" mburns
  # mike+gitsh@
  

[mike-burns]

@pbrisbin the issue is that we want to support two kids of statements: git-defined/user-defined statements, and gitsh statements. The first type are e.g. commit, add, but also lg and up (aliases), and the second are :set, :exit. Ideally these two will never conflict.

[pbrisbin]

I understand the colon as disambiguator; however, I consider it a viable approach to just let user-defined statements shadow git-defined in the case of conflicts. If I do commit=1, then a bare commit will return 1 rather than run git commit -- I don't feel strongly at all either way, was just mentioning it as an option.

[georgebrock]

I've had a lot of fun this weekend implementing :set variable value and $variable. You can see it on the gb-parser branch (if you want a usage example, spec/integration/variables_spec.rb is a good place to start).

Commands a no longer blindly passed to git: input is parsed by a parslet-based Gitsh::Parser, and then run through a Gitsh::Transformer, which spits out an object with a #execute method (a Gitsh::GitCommand or a Gitsh::InternalCommand::Set, so far)

There's a bit of work still to do:

• Unknown internal commands (i.e. anything that starts with a : and isn't :set) cause an exception
• The autotools based distribution doesn't install parslet
• :set and $var aren't documented anywhere
• Parse errors (e.g. unbalanced quotes, git commands containing underscores) cause an exception (this was already true, it's just a different exception now)
• Escaped quotes and dollars in strings don't work
• Tab completion for built in commands
• Replace exit special case with a :exit command
• Support multi-line strings

[mike-burns]

As discussed with George on a fika walk: the autotools shouldn't install parslet as part of the build process, but it should instead vendor parslet while making the dist tarball. Or something thereabouts.

[georgebrock]

@mike-burns @pbrisbin: I've opened PRs for internal command support and the new parsing model (#37) and an install process with vendorized gems (#38). I've tried to break everything else we've discussed here into other issues (#31, #32, #33, #34, #35, #36) so we can tackle them one at a time. I'm beginning to think this project needs a Trello board or something.