This allows people to incorporate the thoughtbot dotfiles into their own
dotfiles in a more fine-grained manner.
I left some things in zshrc that we should eventually handle more
precisely:
- Load `.zsh/functions/*`. This could instead be replaced with: `mv
.zsh/functions/* .zsh/configs`.
- Load `.aliases`. This could instead be replaced with: `mv .aliases
.zsh/configs/aliases.zsh`.
- Load `.zshrc.local`. This file can realistically go away entirely,
with people adding their own files to `.zsh/configs`.
A further refactoring, which I have done locally, is to introduce a
`~/.sh/configs` directory, in which people can put POSIX-specific
configuration that can be shared between GNU Bash, zsh, ksh, etc:
aliases, functions, paths, prompts, and so on. But one step at a time.
Other changes:
* Move aliases setup to occur after loading other config, as some of our
aliases depend on environment variables having been set, so alias
loading must come last after we've sourced `zsh/configs`.
* Move autocompletion for `g` function from the function definition to
to `zsh/completions/_g`
* Move `PATH` setup to `zsh/configs/post` to ensure it happens after
other configuration that might alter the `PATH`
Unfortunately, the convention for most JavaScript linters is to name
their configuration `.${TOOL}rc`.
In spite of this name, the configuration files are `JSON`. Forcing vim
to recognize them as JSON would enable syntax highlighting and linting
plugins (like syntastic) to recognize invalidly structured JSON.
The zsh-completions repository has some additional Bundler subcommands
in their completion since we first implemented it a couple years ago.
This change updates our `_bundle` autocompletion definition to include
the subcommands `outdated` and `platform`, as well as separating values
for `bundle help`.
Separating the individual commands when defining candidates for `bundle
help` allows tab-completion of those subcommands (e.g. hitting `<TAB>`
with `bundle help in` would suggest `init` and `install` and tab
complete either option.
Changes imported from
a59f5c3a0a/src/_bundle
**Bring executables into better shellcheck compliance**
While evaluating linting and testing options for our shell
configuration, a run of Shellcheck against our executables turned up
some places where we could use more consistent syntax across our
executables, such as always using a shebang or quoting `$HOME` when we
build up a larger directory.
**Update syntax for zsh functions and completions**
A few changes found while linting zsh configs with shellcheck:
* thoughtbot's [style guide] [guide] calls for `$(..)` over backticks
when capturing command output
* use `-gt` to test array length in arguments
[guide]: https://github.com/thoughtbot/guides/tree/master/best-practices
If `/etc/zshenv` that calls `path_helper` is found on the system, assume
OS X version pre-El Capitan and suggest that this file gets renamed to
`zprofile` so that it only gets sourced on login shells and doesn't mess
up PATH order on nested invocation of zsh.
Warn people who might have PATH and similar configuration in their
`~/.zshenv.local` that they should upgrade to `~/.zshrc.local` since
that's a much better phase for such configuration. This is for backwards
compatibility with people's personal configurations from pre-El Capitan
days.
The generic `.zshenv` file from zsh distribution[1] advises:
> .zshenv is sourced on ALL invocations of the shell, unless the -f
> option is set. It should NOT normally contain commands to set the
> command search path, or other common environment variables unless you
> really know what you're doing. E.g. running `PATH=/custom/path gdb program`
> sources this file (when gdb runs the program via $SHELL), so you want
> to be sure not to override a custom environment in such cases. Note
> also that .zshenv should not contain commands that produce output or
> assume the shell is attached to a tty.
[1]: http://sourceforge.net/p/zsh/code/ci/master/tree/StartupFiles/zshenv
`.zshenv` is executed for all zsh programs, even those run from
executables and not as an interactive shell, and furthermore due to
OS X's use of `path_helper` in `/etc/zprofile` which runs after that,
it's not a good place to configure additional PATH entries.
From zsh(1) man page:
> As /etc/zshenv is run for all instances of zsh, it is important that
> it be kept as small as possible.
So `.zshenv` is generally considered advanced usage and is not
recommended that people drop their casual login shell config in here.
Because of people's historical misuse of `.zshenv`, stop documenting it
in the README and suggest that people do their PATH and other
configuration in `.zshrc`.
Making tweaks such as setting EDITOR or changing PATH only makes sense
for interactive shells, e.g. those that open in your Terminal window or
when you log in to a server. Non-interactive shells (such as those
started by running `zsh myscript.zsh` or any executable with `zsh`
shebang) should instead inherit those values from the environment.
Furthermore, changing PATH in `~/.zshenv` is not advised since stock
OS X `/etc/zprofile` will reoder PATH by means of `path_helper`, so it's
better to make any additional PATH manipulation in `~/.zprofile` or
`~/.zshrc`.
For years, OS X has mistakently invoked `path_helper` in `/etc/zshenv`
(affecting all zsh runtimes, even non-interactive shells such as
scripts) instead of from `/etc/zprofile` where it should have been
because it needs to only run once for a login shell.
This frustrated a lot of users since `path_helper` would unexpectedly
reorder their PATH by putting system paths first during nested
invocations of zsh. Many have disabled their `path_helper` because they
believed it to be the culprit. Instead, what they should have done is
fixed the OS X configuration bug and renamed their `/etc/zshenv` to
`/etc/zprofile`.
Recently, El Capitan shipped and users of zsh rejoiced because it has
finally fixed its faulty zsh configuration: the `path_helper` is now
correctly invoked from `/etc/zprofile`. This was a deliberate change on
Apple's part and is a BUG FIX, NOT A REGRESSION.
However, now this project suggests the opposite: revert the El Capitan
fix and move `/etc/zprofile` to `/etc/zshenv`. This is unwise since it
teleports us to the olden days of broken zsh configuration. Please don't
instruct users to break their system.
This reverts commit 15de0bcfee.
Using `--force-with-lease` allows one to force push without the risk of
unintentionally overwriting someone else's work.
The git-push(1) man page states:
> Usually, "git push" refuses to update a remote ref that is not an
> ancestor of the local ref used to overwrite it.
>
> This option overrides this restriction if the current value of the
> remote ref is the expected value. "git push" fails otherwise.
>
> --force-with-lease alone, without specifying the details, will protect
> all remote refs that are going to be updated by requiring their
> current value to be the same as the remote-tracking branch we have for
> them.
>
> --@calleerlandsson
> -- https://github.com/thoughtbot/guides/pull/363
As reported in #405, the `jj` keybinding is problematic for some users
as it enters vi-mode whenever a user types a string that actually
contains two consecutive `j`s.
While consecutive `j`s are unusual in English, usernames with
consecutive `j`s such as that of the contributor who reported the
problem (@jjlangholtz) are common enough that we shouldn't force this
mapping on users.
Users can add their own keybinding to their local configuration or use
the already-provided `Esc` binding to enter vi-mode.
PR #405 contains other keybinding changes that we don't want to apply,
this commit addresses only the `jj` binding.
The `ranch` subcommand is annoying to skip and adds clutter to our
system, which only encourages people not to use our dotfiles as a base.
Remove it to get customizability back.
Sometimes when typing `git branch` I leave off the leading `b`, leading
to the boring message:
> git: 'ranch' is not a git command. See 'git --help'.
This adds a custom `git ranch` command with a friendlier funny message.
vim-projectionist provides vim-rails-like shortcuts for alternate and
related files. It allows users to provide a custom set of "projections"
that map filetypes to their alternate and related counterparts. Custom
mappings can be declared in a JSON-like syntax.
This change provides authors of gems and other non-Rails Ruby projects
with access to the alternate file `:A` shortcuts to navigate between
code and specs. vim-rake automatically maps code/spec mappings for Ruby
files if vim-projectionist is available.
Close#381.
OS X 10.11 changes the file where `path_helper` is invoked from
`/etc/zshenv` to `/etc/zprofile`. The change results in `path_helper`
rearranging the path in such a way that interferes with path changes
made in `.zshenv`.
This README update instructs users to rename `/etc/zprofile` to
`/etc/zshenv` so that `.zshenv` (and `.zshenv.local`) will be loaded
*after* `path_helper` is called, maintaining the desired precedence of
paths.
Thanks to @reshleman and @ventsislaf for investigating and offering
solutions.
In #408 a user reported errors after pulling down master and opening
Vim without having run `rcup`. This documentation change updates the
section on `rcup` to advise running the command after pulling from the
origin.
Other changes:
* Removed outdated references to `m` and `rk` aliases, which have been
removed from the repository.
* Added reference to `migrate` alias, which remains in the repository.
The following ERB generates a "Possibly useless use of variable in void
context" warning from Syntastic:
```erb
<%= comment %>
```
The warning can be eliminated by making it:
```erb
<%= comment.to_s %>
```
However, this behavior is the default and is redundant. There are other
cases where this warning pops up and in each case I've found it to be of
no use.
Third-party completions get added to
`/usr/local/share/zsh/site-functions`.
Standard `$fpath` contains `/usr/share/zsh/site-functions`
(not the missing `local`).
By adding this to the `$fpath` git subcommands get completed correctly.
Related to https://github.com/thoughtbot/dotfiles/pull/373.
C-a allow use to trigger tmux prefix more easily than C-b, at the cost
of overriding the readline beginning of line. This change remaps it to
C-s, which has the same effect without that drawback.
Remove last-pane bindings.
Map prefixes to underlying behavior
Quoting Chris Toomey:
> I'm wondering if we might want to take a different approach with these
> keys. last-pane is already bound to ; by default which is comfortably
> on the home row, and if using vim-tmux-navigator also bound to
> (unprefixed) C-\.
Xcode >=6.0.1 throws an error when creating a new git-tracked project
without an 'exclude' file. Created the exclude file to correspond to
the existing gitignore file.
More info about this file:
http://seejohncode.com/2012/02/29/git-info-exclude
* After removing the matchit.vim plugin from the vimrc.bundles file in
this pull request https://github.com/thoughtbot/dotfiles/pull/379. It
was brought to my attention that plugins in the macros directory are
not automatically loaded due to backwards compatibility issues.
* Add entry to vimrc to source the matchit.vim plugin from the macros
directory, if the user does not have it installed already. This is how
Tim Pope adds the matchit.vim plugin to vimrc in his vim-sensible plugin.
https://github.com/tpope/vim-sensible/blob/master/plugin/sensible.vim#L88
Bundler 1.8+ added support for git-style subcommands. Any scripts
starting with `bundler-` in your path are executable as bundler
subcommands.
This adds `search` as a subcommand that uses `ag` to search for a string
among all gems in your bundle (default) or optionally a specific gem.
I've found this useful for finding the source of puzzling deprecations,
finding what gem provides a method, and other various things.
* This plugin is no longer maintained and is included in vim by default.
* Per the docs at https://github.com/vim-scripts/matchit.zip
Since vim 6.0, matchit.vim has been included in the standard vim distribution,
under the macros/ directory; the version here may be more recent.
* The version included in the vim macros directory is the same version
being added in the vimrc.bundles file from github version 1.13.2
Autosquash makes it quicker and easier to squash or fixup commits during an
interactive rebase. It can be enabled for each rebase using `git rebase -i
--autosquash`, but it's easier to turn it on by default.
Say I have this history:
$ git log --oneline
aaa1111 A first commit
bbb2222 A second commit
ccc3333 A third commit
I make another change that I already know should be squashed into "A
second commit". I can do this:
$ git add .
$ git commit --squash bbb2222
[my-branch ddd4444] squash! A second commit
Then when I rebase:
$ git rebase -i origin/my-branch
The interactive rebase list will be set up ready to squash:
pick aaa1111 A first commit
pick bbb2222 A second commit
squash ddd4444 squash! A second commit
pick ccc3333 A third commit
Since it's unlikely that anyone will be writing a commit message that begins
`squash!` or `fixup!` when they don't want this behaviour, and the user
still has a chance to review what's going to happen with the rebase, it's
safe to have it always turned on.
[vim-plug](https://github.com/junegunn/vim-plug) has a number of
advantages over Vundle:
* Installs and updates plugins very quickly in parallel
* Can lock plugins at versions/tags
* Can rollbacks updates (useful if a plugin breaks) and take/reload
snapshots of current state
* Optionally lazily-load plugins when their relevant command is invoked
* Execute post-update hooks for plugins with compiled extensions, etc.
vim-plug uses a DSL very close to Vundle (simplest form is `Plug` vs.
`Plugin`), and here it is set to continue to use the same plugin
location that Vundle was using before.
After updating, users will need to
1. Rename `Plugin` lines in `.vimrc.bundles.local` to use `Plug`
2. Run `:PlugInstall` (the post-up hook does this)
* Every time I pull updates from this repo into my own dotfiles, I have to
reconfigure my preferred theme (solarized)
* Seems like there is not a majority or plurality of thoughbotters using a
single colorscheme
* Easiest to just not specify a colorscheme
* See https://forum.upcase.com/t/why-is-the-default-vim-theme-on-dotfiles-is-github/4232
I am constantly forgetting that I can't use `ctrl-p` to open
`.travis.yml` or any other file with a leading `.`. This change comes
about after some discussion in general on how to handle this. Passing
`--hidden` to the `ag` command allows it to find files with a leading
`.`.
Unfortunately, this also includes the content of your `.git`
directory. To overcome this, we add `/.git/` to `agignore`.
