When within a git repository, doing a tab-autocomplete on a command results with the command becoming unreadable. The command still works but this is pretty annoying visually. Basically I 1. Navigate to a directory with a git repository in it. The prompt indicates the current branch properly 2. Next, type `git -` and hit tab The prompt now shows only part of branch's name with the first suggestion appended. After googling a bit I stumbled upon several pages describing a similar problem (most useful to me was http://stackoverflow.com/questions/23740862/issues-with-zsh-prompt). The culprit seems to be the git_prompt_info function escaping the `$current_branch` variable as if it is a color. As a result zsh is confused where the cursor is. After "unescaping" the variable everything seems to work fine. Using zsh 5.0.7 (x86_64-apple-darwin13.4.0).
From the [Zsh manual](http://zsh.sourceforge.net/Intro/intro_3.html): > '.zshenv' is sourced on all invocations of the shell, unless the -f option is > set. It should contain commands to set the command search path, plus other > important environment variables. `.zshenv' should not contain commands that > produce output or assume the shell is attached to a tty. Why is this important? [Alfred](http://www.alfredapp.com/) workflows run in non-interactive shells. When the `$PATH` is set, or `rbenv` is initialized, in `zshrc` instead of `zshenv`, those workflows will not use the correct Ruby version and might not have access to certain bin files, such as those from `$HOME/.bin/` or Homebrew.
Just before loading `~/.zshrc.local`, load: 1. `~/.zsh/configs/pre/**/*` 2. `~/.zsh/configs/**/*` # excluding pre and post 3. `~/.zsh/configs/post/**/*` About the zsh glob: - `.`: only produce normal files. - `-`: follow symlinks to their final file; skip any broken links. - `N`: do not complain about zero matches. Big ups to Pat Brisbin for finding `N`.
Our expected way of managing Rubies is with rbenv: https://github.com/thoughtbot/laptop/blob/master/common-components/ruby-environment This commit loads rbenv in `zshrc` as recommended by the rbenv docs: https://github.com/sstephenson/rbenv#basic-github-checkout Assuming the binstubs for a project are in the local bin/ directory, we can even go a step further to add the directory to shell $PATH so that rspec can be invoked without the bin/ prefix: export PATH="./bin:$PATH" Doing so on a system that other people have write access to (such as a shared host) is a security risk: sstephenson/rbenv#309 The `.git/safe` convention addresses the security problem: https://twitter.com/tpope/status/165631968996900865 This zsh fix may be necessary for OS users in order to fix a bug: https://github.com/thoughtbot/laptop/blob/master/mac-components/zsh-fix
There are many workarounds to the zsh: no matches found: ... issue, but let's just stop it at its core: turn off that `nomatch` functionality. Apologies to all who enjoy seeing the pun around: % got a light? zsh: no matches found: light? But all good shell puns must come to an end.  http://robots.thoughtbot.com/post/18129303042/how-to-use-arguments-in-a-rake-task  http://www-users.cs.york.ac.uk/susan/joke/unix.htm
* Use a regular alias to make `s` short for `rspec` * Use an `rspec` shell function to route to zeus when appropriate * Removes confusion from `s` working differently than `rspec` * Removes need to use a special alias to get zeus working