Summary:
Using CtrlP has proven to be slower and has fewer features. We've been
switching over to FZF on a frequent enough basis that it feels
appropriate to make FZF the new default for fuzzy searching.
By swapping out Ctrlp in favor of FZF, this should not break anyone's
fuzzy search but it will replace the tool that executes the search.
Co-authored-by: Chris Toomey <chris@ctoomey.com>
ASDF has plugins for Ruby, Node, Elixir, Haskell, Scala, Go, etc.
Instead of finding and installing a new tool each time we have need for
a version manager in a new tools, we can use the same tool we already
know, adding a new plugin.
This change is the result of a successful [research card][1] and has a
corresponding change to [laptop][2].
[1]: https://trello.com/c/MVbfz8e5/676-asdf-for-tool-management
[2]: https://github.com/thoughtbot/laptop/pull/502
Thanks to rcm and the `post-up` hook file, the dotfiles do a great job
of keeping things up to date.
This change adds a bit of detail and specificity to the README around
updating, specifically clarifying the need to run `rcup` after pulling
to link new files and install new vim plugins.
To [append a project's local `bin/` directory to `$PATH`][dotfiles],
the dotfiles check for the existence of a special directory: `git/.safe`.
This commit is inspired by [thoughtbot/suspenders#837][#837]:
> The idea behind the .git/safe is that I run it manually and explicitly
> after I trust the directoy and the team behind the project.
> Creating it as part of the setup script defeats the point of that. Doing
> so without explcitly telling the user comes across as sneaky, perhaps.
> (I do expect all devs to read setup scripts before running them -- but I
> also know that they do not!)
> Switch this script to inform the user that they have no `.git/safe`
> directory but might like to make one.
Since suspenders may no longer mark projects safe by default, this
commit introduces the `git trust-bin` command to do so.
[dotfiles]: af75a673b1/zsh/configs/post/path.zsh (L9-L10)
[#837]: https://github.com/thoughtbot/suspenders/pull/837
It seems like JavaScript/ES6 is becoming more common for us to run into
in the wild compared to CoffeeScript
with the advent of Babel / transpiling.
Eventually, we'll probably want to remove kchmck/vim-coffee-script.
Users working on CoffeeScript applications would need to move that
plugin into their personal dotfiles.
The `UnPlug` command allows a user to remove a plugin from vim-plug's
list of plugins to install/activate. This command can be used to
selectively ignore shared plugins from `vimrc.bundles` without needing
to overwrite the entire file with a personal replacement.
This change is dependent on vim-plug continuing to use the `g:plugs`
global variable.
I added this four years ago but haven't been using it.
Not common enough to be included in company-wide dotfiles?
Can move to personal dotfiles if desired.
In #488 there was some confusion over where to clone the dotfiles
repository before running `rcm`. While the repository can be placed
anywhere, by default users should be placing it in `~/dotfiles` if they
are using the default installation instructions and an unmodified
`.rcrc`.
Close#488.
vim-rspec is an excellent Vim plugin for running RSpec tests but there
are many of us who run different kinds of tests on any given day.
vim-test is built to support a wide array of test frameworks and
strategies for executing those tests.
vim-test ships with support for several languages and frameworks in use
on thoughtbot projects today:
* Ruby (both RSpec and Minitest)
* Elixir (ExUnit and espec)
* Go (gotest)
* Python (nose, pytest, djangotest, djangonose)
* JavaScript (jasmine, mocha)
It also supports several execution strategies I have seen people use at
thoughtbot:
* Dispatch
* vim-tmux-runner
* Tslime
* Terminal.app/iTerm.app tabs
* neovim's native terminal
* `:!`
vim-test is extensible, both for additional languages/frameworks and for
execution contexts. See: https://github.com/janko-m/vim-test
`.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`.
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.
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.
[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.
