mirror of
https://github.com/mhinz/vim-galore.git
synced 2025-02-24 01:59:28 +08:00
143 lines
5.4 KiB
Markdown
143 lines
5.4 KiB
Markdown
|
|
|
|
---
|
|
|
|
#### Basics
|
|
- [Buffers, windows, tabs?](#buffers-windows-tabs)
|
|
- [Active, loaded, listed, named buffers?](#active-loaded-listed-named-buffers)
|
|
- [Colorschemes?](#colorschemes)
|
|
|
|
#### Usage
|
|
- [Managing plugins](#managing-plugins)
|
|
|
|
#### Plugins
|
|
- [Fuzzy finders](#fuzzy-finders)
|
|
- [Version control](#version-control)
|
|
|
|
---
|
|
|
|
## Basics
|
|
|
|
#### Buffers, windows, tabs?
|
|
|
|
Vim is a text editor. Everytime text is shown, the text is part of a **buffer**.
|
|
Each file will be opened in its own buffer. Plugins show stuff in their own
|
|
buffers etc.
|
|
|
|
Buffers have many attributes, e.g. whether the text it contains is modifiable,
|
|
or whether it is associated with a file and thus needs to be synchronized to
|
|
disk on saving.
|
|
|
|
**Windows** are viewports _onto_ buffers. If you want to view several files at
|
|
the same time or even different locations of the same file, you use windows.
|
|
|
|
And please, please don't call them _splits_. You can split a window in two, but
|
|
that doesn't make them _splits_.
|
|
|
|
Windows can be split vertically or horizontally and the heights and widths of
|
|
existing windows can be altered, too. Therefore you can use whatever window
|
|
layout you prefer.
|
|
|
|
A **tab page** (or just tab) is a collection of windows. Thus, if you want to
|
|
use multiple window layouts, use tabs.
|
|
|
|
Putting it in a nutshell, if you start Vim without arguments, you'll have one
|
|
tab page that holds one window that shows one buffer.
|
|
|
|
By the way, the buffer list is global and you can access any buffer from any
|
|
tab.
|
|
|
|
#### Active, loaded, listed, named buffers?
|
|
|
|
Run Vim like this `vim file1`. The file's content will be loaded into a buffer.
|
|
You have a **loaded buffer** now. The content of the buffer is only synchronized
|
|
to disk (written back to the file) if you save it within Vim.
|
|
|
|
Since the buffer is also shown in a window, it's also an **active buffer**. Now
|
|
if you load another file via `:e file2`, `file1` will become a **hidden buffer**
|
|
and `file2` the active one.
|
|
|
|
Both buffers are also **listed**, thus they will get listed in the output of
|
|
`:ls`. Plugin buffers or help buffers are often marked as unlisted, since
|
|
they're not regular files you usually edit with a text editor. Listed and
|
|
unlisted buffers can be shown via `:ls!`.
|
|
|
|
**Unnamed buffers**, also often used by plugins, are buffers that don't have an
|
|
associated filename. E.g. `:enew` will create an unnamed scratch buffer. Add
|
|
some text and write it to disk via `:w /tmp/foo`, and it will become a named
|
|
buffer.
|
|
|
|
#### Colorschemes?
|
|
|
|
Colorschemes are the way to style your Vim. Vim consists of many components and
|
|
each of those can be customized with different colors for the foreground,
|
|
background and a few other attributes like bold text etc. They can be set like
|
|
this:
|
|
```viml
|
|
:highlight Normal ctermbg=1 guibg=red
|
|
```
|
|
This would paint the background of the editor red. See `:h :highlight` for more
|
|
information.
|
|
|
|
So, colorschemes are mostly a collection of `:highlight` commands.
|
|
|
|
Actually, most colorschemes are really 2 colorschemes! The example above sets
|
|
colors via `ctermbg` and `guibg`. The former definition will only be used if Vim
|
|
was started in a terminal emulator, e.g. xterm. The latter will be used in
|
|
graphical environements like gVim.
|
|
|
|
If you ever happen to use a certain colorscheme in Vim running in a terminal
|
|
emulator and the colors don't look like the colors in the screenshot at all,
|
|
chances are that the colorscheme only defined colors for the GUI.
|
|
|
|
Here's a list of commonly used colorschemes:
|
|
|
|
- [base16](https://github.com/chriskempson/base16-vim)
|
|
- [gotham](https://github.com/whatyouhide/vim-gotham)
|
|
- [gruvbox](https://github.com/morhetz/gruvbox)
|
|
- [jellybeans](https://github.com/nanotech/jellybeans.vim)
|
|
- [molokai](https://github.com/tomasr/molokai)
|
|
- [railscasts](https://github.com/jpo/vim-railscasts-theme)
|
|
- [solarized](https://github.com/altercation/vim-colors-solarized) (or a lighter variant of it: [flattened](https://github.com/romainl/flattened))
|
|
- [vividchalk](https://github.com/tpope/vim-vividchalk)
|
|
|
|
I use gruvbox for the GUI and [janah](https://github.com/mhinz/vim-janah) for
|
|
the terminal.
|
|
|
|
## Usage
|
|
|
|
#### Managing plugins
|
|
|
|
[Pathogen](https://github.com/tpope/vim-pathogen) was the first popular tool for
|
|
managing plugins. Actually it just adjusts the _runtimepath_ (`:h 'rtp'`) to
|
|
include all the things put under a certain directory. You have have to clone the
|
|
repositories of the plugins there yourself.
|
|
|
|
Real plugin managers expose commands that help you installing and updating
|
|
plugins from within Vim. Hereinafter is a list of commonly used plugin managers
|
|
in alphabetic sequence:
|
|
|
|
- [neobundle](https://github.com/Shougo/neobundle.vim)
|
|
- [plug](https://github.com/junegunn/vim-plug)
|
|
- [vim-addon-manager](https://github.com/MarcWeber/vim-addon-manager)
|
|
- [vundle](https://github.com/VundleVim/Vundle.vim)
|
|
|
|
Plug is my favorite, but your mileage may vary.
|
|
|
|
## Plugins
|
|
|
|
#### Fuzzy finders
|
|
|
|
- [command-t](https://github.com/wincent/Command-T)
|
|
- [ctrlp](https://github.com/ctrlpvim/ctrlp.vim.git)
|
|
- [fzf](https://github.com/junegunn/fzf)
|
|
- [unite](https://github.com/Shougo/unite.vim)
|
|
|
|
#### Version control
|
|
|
|
- [fugitive](https://github.com/tpope/vim-fugitive)
|
|
- [gitgutter](https://github.com/airblade/vim-gitgutter)
|
|
- [lawrencium](https://bitbucket.org/ludovicchabant/vim-lawrencium)
|
|
- [signify](https://github.com/mhinz/vim-signify)
|
|
- [vcscommand](https://github.com/vim-scripts/vcscommand.vim)
|