[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
The `pre-commit` and `prepare-commit-msg` git hooks can be used
for some interesting things such as linting files.
For example, I need to format, vet, and lint Go files:
https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commithttps://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg
We've rejected Go-related pull requests to thoughtbot/dotfiles
due to not doing enough "official" Go work at the company.
This change helps me start with `.local` for now,
and then promote to "upstream" (thoughtbot/dotfiles) at some point
in the future if we do more "official" Go work.
I'm a believer in having linting done at VCS "commit time", either
locally in a pre-commit so I have a chance to fix things and not both my
teammates with linting issues, or at post-commit time via Hound comments
(also automated, but opportunity to ignore).
I've tried adding linting libraries to my editor, and found them too
slow, at least for Ruby. I've limited "editor-time" checking to just
syntax checking via Syntastic.
The downsides I see to adding linting to the test suite are:
* Style violations are not functional failures and logically shouldn't
fail a build.
* Adding code coverage, linting, etc. to a test suite slows down the
build.
* I only need to lint my diff (the commit), not the whole codebase, when I
make changes.
* Style violations should not prevent a user-facing, production deploy.
* Adding linting to the test suite can slow that process down
unnecessarily, particularly in continuous integration setups.
I see the appeal of linting in the test suite, particularly for
greenfield apps where we have total control, but I don't think it's a
practice that we can universally apply to our client projects who have
different deploy setups and existing codebases. So, I prefer the git
hooks + Hound approach as a pragmatic middle ground.
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`.
I wanted to add my own customizations after reading @mike-burns' post on
[`psqlrc`](http://robots.thoughtbot.com/an-explained-psqlrc).
As a result of this change, `.psqlrc` requires that a `.psqlrc.local`
exist in the home folder because `psql` cannot do conditional sourcing
of files in the style that we use in other foundation dotfiles. Touching
the file to ensure it exists (even if blank) prevents `psql` from
exiting with an error if the user does not provide their own custom
configuration.
Additional changes:
* Updating the documentation with regard to which files get excluded.
The rcm suite is designed to replace the `./install.sh` script found in
this and many other dotfiles repos across GitHub. By using rcm users can
combine multiple dotfiles repos, tag dotfiles, have host-specific
dotfiles, and other powerful features.
This commit removes `install.sh`, updates the README, adds a post-up
hook that vundles the vim bundles, and adds a `rcrc` configuration that
ignores `README.md` and `LICENSE` and sets the dotfiles directory to
just `dotfiles`.
