Summary:
This change addresses an error that occurs when we've instructed vim to
reference the wrong path for an existing FZF executable.
Additional Details:
In the previous approach, when checking if FZF has already been
installed, we make the assumption that if FZF is `executable` it was
installed via Homebrew. Then, based on that assumption, we set vim's
`runtimepath` to reference the directory where Homebrew creates symlinks
for installed packages (`/user/local/opt`).
Because of this assumption, anyone that has FZF installed in a different
directory, and available as an executable in their $PATH, attempting to
use FZF within vim will result in an error. The reason vim errors is
because `Plug` has instructed vim's `runtimepath` to look in the wrong
location for FZF (in this case, we told vim to look for FZF within
`/user/local/opt` when the FZF executable lives somewhere else).
The revised approach still attempts to find an existing FZF package
before proceeding with installing FZF.
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>
With the popularity of Babel and ES6, it seems like Coffeescript is no
longer a standard, frequently-used part of the thoughtbot toolset. This
change removes the vim-coffeescript plugin from our default set. Users
who want to retain it can add it back to their `vimrc.bundles.local`.
We've been using vim-plug over Vundle since 5724d12 (April 2015). Users
have had long enough to migrate their `vimrc.bundles.local` to use
vim-plug's `Plug` command.
We have an rcm `post-up` hook that installs plugins after running
`rcup`. It does this by directly loading the `.vimrc.bundles` file,
which means our regular `.vimrc` file is not sourced. This lead to
`has_async` being undefined.
By moving the definition into the `vimrc.bundles` we ensure it's
available when that `post-up` hook runs. It remains available when
needed in `vimrc` because we use it there *after* sourcing the bundles.
Now that we're using `ALE`, we're making use of the async features
available in Vim8 and NeoVim. If you try to use these dotfiles on Vim 7,
you'll get a host of errors from ALE.
This change does two things:
1. It writes an error when starting in an unsupported vim version.
2. It skips loading ALE in those versions.
The thinking behind the second change is to leave vim in a more usable
state with minimal annoyance after the initial error.
ALE is an Asynchronous Linting Engine which works with Vim 8 and NeoVim
to lint your code "as you type". It does so without blocking the main
thread by using the asynchronous features of both of those Vim versions.
A number of us in Boston have been using ALE for some time now with
great success. The asynchronous nature means linting does not block
other interactions with Vim and it's been nice to get linting feedback
more often than buffer write.
Many of us find the "as-you-type" linting to be performant enough to
actually be a distraction, so this PR tones that down some. With this
configuration, ALE will lint on cursor hold durations of 1 second and
when leaving insert mode in addition to buffer write, buffer read, and
file type change.
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.
We do most of our client work on Github,
and a large portion of our personal projects
are hosted there.
fugitive.vim currently supports
opening the current file in the current branch
in a browser at Github through the `Gbrowse` command.
That command is [slated to be removed to make fugitive
agnostic about coding sites](fugitive-docs).
The capability to quickly generate or view a Github URL
specific to the current branch
can be useful in PR reviews
or other discussions about code.
This change adds rhubarb.vim,
a plugin that implements the slated-to-be-removed
functionality of fugitive that works with Github.
It also provides the user with omni-completion (`<C-x><C-o>`)
to autocomplete Github issues, issue URLs, and collaborators.
[fugitive-docs]: 18d6d1ab82/doc/fugitive.txt
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
Add suggested Go configuration for Vim into the `ftplugin` folder and
the vim-go plugin. We may use this as a template for adding further
language-specific settings in the future for languages that aren't
universally used by the team.
* `fatih/vim-go`: The de-facto Golang Vim plugin.
* `softtabstop=2`: As a side effect of setting how "large" a tab is in
insert mode, Vim is able to delete tabs with the backspace key in
Insert mode.
* `compiler go`: Necessary for plugins using the `make` command, such as
vim-dispatch.
* `listchars=tab:\ \ `: Don't highlight tabs as "»·" as if they were
problem characters in go files. Also recommended for *sh files and any
others which which should also be using tabs.
* `go_fmt_command = "goimports"`: Tell vim-go to use the `goimports`
command rather than `gofmt`, which attempts to find dependencies and
adds them to your import statement.
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.
* 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
[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
Does what rename.vim does (`:Move` or `:Rename`) **plus**:
* Adds `:Unlink` or `:Remove` to delete the current buffer + file
* Adds `:Mkdir` (with no argument, create the current file's containing
directory)
* Adds `:SudoWrite` if you forget to edit a file as root
* Automatically chmods a file to `+x` if it starts with `#!`
* Tim Pope! ❤️
Removal in deb7ee5948
was accidental.
Also, removes `vim/bundle` directory as it is no longer useful to us, since
`vundle` creates it when it needs to.
`:e some/non_existent_directory/new_file.txt` usually errors out because
the directory does not exist, but with `vim-mkdir` the non-existent
directory will be created automatically.
* haml, html and markdown highlight still work without these plugins
* treetop and textile are likely very situational
* unsure if anyone is using greplace
I've had this in [my own dotfiles] for a while now, and really like
having the separation of what I consider to be code/configuration from
what to me feels more like a Gemfile, in that it lists out all of the
external dependencies in a single place.
[my own dotfiles](https://github.com/calebthompson/dotfiles/blob/master/vim/vimrc.bundles.symlink)
* Awesomer vundle integration:
* Refactor .vimrc and .vimrc.bundles to support standalone
BundleInstall.
* Install vim bundles as part of install.sh without sourcing the
normal vimrc, which prevents error messages from uninstalled
plugins referenced in the main vimrc.
