configs/scatterd-dotfiles
1
0
Fork 0
Code Issues 2 Pull requests 1 Projects Releases Packages Wiki Activity Actions
scatterd-dotfiles/vimrc.bundles

53 lines
1.1 KiB
Text
Raw Normal View History

Only set nocompatible once as early as possible * Setting nocompatible has side effects * Setting it again (even if set) repeats side effects * Settings like ruler will be reset if set again
2014-03-19 15:05:30 -04:00
if &compatible
set nocompatible
end
Move Bundles into a separate file 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.
2013-04-16 20:24:00 -04:00
Allow user to ignore some default vim plugins 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.
2016-10-31 21:21:40 -04:00
" Remove declared plugins
function! s:UnPlug(plug_name)
if has_key(g:plugs, a:plug_name)
call remove(g:plugs, a:plug_name)
endif
endfunction
command! -nargs=1 UnPlug call s:UnPlug(<args>)
Move definition of `has_async` 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.
2017-08-10 09:35:50 -04:00
let g:has_async = v:version >= 800 || has('nvim')
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
call plug#begin('~/.vim/bundle')
Move Bundles into a separate file 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.
2013-04-16 20:24:00 -04:00
" Define bundles via Github repos
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
Plug 'christoomey/vim-run-interactive'
Replace CtrlP with 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>
2019-07-12 17:09:20 -04:00
if executable('fzf')
Plug '/usr/local/opt/fzf'
else
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
endif
Plug 'junegunn/fzf.vim'
Add support for Elixir and EEx syntax highlighting
2017-02-17 15:24:47 -05:00
Plug 'elixir-lang/vim-elixir'
Add golang configuration samples 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.
2015-11-13 09:29:46 -06:00
Plug 'fatih/vim-go'
Use vim-test instead of vim-rspec 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
2016-02-11 22:03:38 -05:00
Plug 'janko-m/vim-test'
Add JavaScript syntax highlighting 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.
2017-05-08 10:36:07 -07:00
Plug 'pangloss/vim-javascript'
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
Plug 'pbrisbin/vim-mkdir'
Plug 'slim-template/vim-slim'
Plug 'tpope/vim-bundler'
Plug 'tpope/vim-endwise'
Plug 'tpope/vim-eunuch'
Plug 'tpope/vim-fugitive'
Use vim-projectionist and vim-rake 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.
2015-10-03 11:02:29 -04:00
Plug 'tpope/vim-projectionist'
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
Plug 'tpope/vim-rails'
Use vim-projectionist and vim-rake 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.
2015-10-03 11:02:29 -04:00
Plug 'tpope/vim-rake'
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
Plug 'tpope/vim-repeat'
Add rhubarb.vim for fugitive Github support 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]: https://github.com/tpope/vim-fugitive/blob/18d6d1ab82d9ac15586d7d3c1a36f9ef6fb50eae/doc/fugitive.txt
2016-02-18 09:23:50 -05:00
Plug 'tpope/vim-rhubarb'
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
Plug 'tpope/vim-surround'
Plug 'vim-ruby/vim-ruby'
Plug 'vim-scripts/tComment'
Require Vim 8 or NeoVim 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.
2017-08-07 20:36:01 -04:00
if g:has_async
Update ALE location on Github ALE has moved to an organization, so the old repository location gets redirected.
2019-07-29 15:49:37 -04:00
Plug 'dense-analysis/ale'
Require Vim 8 or NeoVim 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.
2017-08-07 20:36:01 -04:00
endif
Move Bundles into a separate file 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.
2013-04-16 20:24:00 -04:00
Adds local configuration file for vim bundles
2013-08-03 10:10:51 -04:00
if filereadable(expand("~/.vimrc.bundles.local"))
source ~/.vimrc.bundles.local
endif
Use vim-plug over vundle [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)
2015-02-18 21:29:50 -05:00
call plug#end()
Reference in a new issue Copy permalink