document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

翻译完成Learning Vim in 2014: Working with Files与删除原文

Browse Source 
添加Practical Lessons in Peer Code Review
This commit is contained in:
lihaiming 2014-10-04 22:29:08 +08:00
parent 9aa7e81907
commit faa9c9034d
3 changed files with 250 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

91
sources/tech/20140929 Learning Vim in 2014--Working with Files.md
View File

@ -1,91 +0,0 @@
Translating by haimingfg
Learning Vim in 2014: Working with Files
================================================================================
As a software developer, you shouldn't have to spend time thinking about how to get to the code you want to edit. One of the messiest parts of my transition to using Vim full time was its way of dealing with files. Coming to Vim after primarily using Eclipse and Sublime Text, it frustrated me that Vim doesn't bundle a persistent file system viewer, and the built-in ways of opening and switching files always felt extremely painful.
At this point I appreciate the depth of Vim's file management features. I've put together a system that works for me even better than more visual editors once did. Because it's purely keyboard based, it allows me to move through my code much faster. That took some time though, and involves several plugins. But the first step was me understanding Vim's built in options for dealing with files. This post will be looking at the most important structures Vim provides you for file management, with a quick peek at some of the more advanced features you can get through plugins.
### The Basics: Opening a new file ###
One of the biggest obstacles to learning Vim is its lack of visual affordances. Unlike modern GUI based editors, there is no obvious way to do anything when you open a new instance of Vim in the terminal. Everything is done through keyboard commands, and while that ends up being more efficient for experienced users, new Vim users will find themselves looking up even basic commands routinely. So lets start with the basics.
The command to open a new file in Vim is **:e <filename>. :e** opens up a new buffer with the contents of the file inside. If the file doesn't exist yet it opens up an empty buffer and will write to the file location you specify once you make changes and save. Buffers are Vim's term for a "block of text stored in memory". That text can be associated with an existing file or not, but there will be one buffer for each file you have open.
After you open a file and make changes, you can save the contents of the buffer back to the file with the write command **:w**. If the buffer is not yet associated with a file or you want to save to a different location, you can save to a specific file with **:w <filename>**. You may need to add a ! and use **:w! <filename>** if you're overwriting an existing file.
This is the survival level knowledge for dealing with Vim files. Plenty of developers get by with just these commands, and its technically all you need. But Vim offers a lot more for those who dig a bit deeper.
### Buffer Management ###
Moving beyond the basics, let's talk some more about buffers. Vim handles open files a bit differently than other editors. Rather than leaving all open files visible as tabs, or only allowing you to have one file open at a time, Vim allows you to have multiple buffers open. Some of these may be visible while others are not. You can view a list of all open buffers at any time with **:ls**. This shows each open buffer, along with their buffer number. You can then switch to a specific buffer with the **:b <buffer-number>** command, or move in order along the list with the **:bnext** and **:bprevious** commands. (these can be shortened to **:bn** and **:bp** respectively).
While these commands are the fundamental Vim solutions for managing buffers, I've found that they don't map well to my own way of thinking about files. I don't want to care about the order of buffers, I just want to go to the file I'm thinking about, or maybe to the file I was just in before the current one. So while its important to understand Vim's underlying buffer model, I wouldn't necessarily recommend its builtin commands as your main file management strategy. There are more powerful options available.
![](http://benmccormick.org/content/images/2014/Jul/skitch.jpeg)
### Splits ###
One of the best parts of managing files in Vim is its splits. With Vim, you can split your current window into 2 windows at any time, and then resize and arrange them into any configuration you like. Its not unusual for me to have 6 files open at a given time, each with its own small split of the window.
You can open a new split with **:sp <filename>** or **:vs <filename>**, for horizontal and vertical splits respectively. There are keyword commands you can use to then resize the windows the way you want them, but to be honest this is the one Vim task I prefer to do with my mouse. A mouse gives me more precision without having to guess the number of columns I want or fiddle back and forth between 2 widths.
After you create some splits, you can switch back and forth between them with **ctrl-w [h|j|k|l]**. This is a bit clunky though, and it's important for common operations to be efficient and easy. If you use splits heavily, I would personally recommend aliasing these commands to **ctrl-h** **ctrl-j** etc in your .vimrc using this snippet.
nnoremap <C-J> <C-W><C-J> "Ctrl-j to move down a split
nnoremap <C-K> <C-W><C-K> "Ctrl-k to move up a split
nnoremap <C-L> <C-W><C-L> "Ctrl-l to move right a split
nnoremap <C-H> <C-W><C-H> "Ctrl-h to move left a split
### The jumplist ###
Splits solve the problem of viewing multiple related files at a time, but we still haven't seen a satisfactory solution for moving quickly between open and hidden files. The jumplist is one tool you can use for that.
The jumplist is one of those Vim features that can appear weird or even useless at first. Vim keeps track of every motion command and file switch you make as you're editing files. Every time you "jump" from one place to another in a split, Vim adds an entry to the jumplist. While this may initially seem like a small thing, it becomes powerful when you're switching files a lot, or moving around in a large file. Instead of having to remember your place, or worry about what file you were in, you can instead retrace your footsteps quickly using some quick key commands. **Ctrl-o** allows you to jump back to your last jump location. Repeating it multiple times allows you to quickly jump back to the last file or code chunk you were working on, without having to keep the details of where that code is in your head. You can then move back up the chain with **ctrl-i**. This turns out to be immensely powerful when you're moving around in code quickly, debugging a problem in multiple files or flipping back and forth between 2 files. Instead of typing file names or remembering buffer numbers, you can just move up and down the existing path. It's not the answer to everything, but like other Vim concepts, it's a small focused tool that adds to the overall power of the editor without trying to do everything.
### Plugins ###
So let's be real, if you're coming to Vim from something like Sublime Text or Atom, there's a good chance all of this looks a bit arcane, scary, and inefficient. "Why would I want to type the full path to open a file when Sublime has fuzzy finding?" "How can I get a view of a project's structure without a sidebar to show the directory tree?" Legitimate questions. The good news is that Vim has solutions. They're just not baked into the Vim core. I'll touch more on Vim configuration and plugins in later posts, but for now here's a pointer to 3 helpful plugins that you can use to get Sublime-like file management.
- [CtrlP][1] is a fuzzy finding file search similar to Sublime's "Go to Anything" bar. It's lightning fast and pretty configurable. I use it as my main way of opening new files. With it I only need to know part of the file name and don't need to memorize my project's directory structure.
- [The NERDTree][2] is a "file navigation drawer" plugin that replicates the side file navigation that many editors have. I actually rarely use it, as fuzzy search always seems faster to me. But it can be useful coming into a project, when you're trying to learn the project structure and see what's available. NERDTree is immensely configurable, and also replaces Vim's built in directory tools when installed.
- [Ack.vim][3] is a code search plugin for Vim that allows you to search across your project for text expressions. It acts as a light wrapper around Ack or Ag, [2 great code search tools][4], and allows you to quickly jump to any occurrence of a search term in your project.
Between it's core and its plugin ecosystem, Vim offers enough tools to allow you to craft your workflow anyway you want. File management is a key part of a good software development system, and it's worth experimenting to get it right.
Start with the basics for long enough to understand them, and then start adding tools on top until you find a comfortable workflow. It will all be worth it when you're able to seamlessly move to the code you want to work on without the mental overhead of figuring out how to get there.
### More Resources ###
- [Seamlessly Navigate Vim & Tmux Splits][5] This is a must read for anyone who wants to use vim with [tmux][6]. It presents an easy system for treating Vim and Tmux splits as equals, and moving between them easily.
- [Using Tab Pages][7] One file management feature I didn't cover, since it's poorly named and a bit confusing to use, is Vim's "tab" feature. This post on the Vim wiki gives a good overview of how you can use "tab pages" to have multiple views of your current workspace
- [Vimcasts: The edit command][8] Vimcasts in general is a great resource for anyone learning Vim, but this screenshot does a good job of covering the file opening basics mentioned above, with some suggestions on improving the builtin workflow
### Subscribe ###
This was the third in a series of posts on learning Vim in a modern way. If you enjoyed the post consider subscribing to the [feed][8] or joining my [mailing list][10]. I'll be continuing with [a post on Vim configuration next week][11] after a brief JavaScript interlude later this week. You should also checkout the first 2 posts in this series, on [the basics of using Vim][12], and [the language of Vim and Vi][13].
--------------------------------------------------------------------------------
via: http://benmccormick.org/2014/07/07/learning-vim-in-2014-working-with-files/
作者：[Ben McCormick][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[a]:http://benmccormick.org/2014/07/07/learning-vim-in-2014-working-with-files/
[1]:https://github.com/kien/ctrlp.vim
[2]:https://github.com/scrooloose/nerdtree
[3]:https://github.com/mileszs/ack.vim
[4]:http://benmccormick.org/2013/11/25/a-look-at-ack/
[5]:http://robots.thoughtbot.com/seamlessly-navigate-vim-and-tmux-splits
[6]:http://tmux.sourceforge.net/
[7]:http://vim.wikia.com/wiki/Using_tab_pages
[8]:http://vimcasts.org/episodes/the-edit-command/
[9]:http://feedpress.me/benmccormick
[10]:http://eepurl.com/WFYon
[11]:http://benmccormick.org/2014/07/14/learning-vim-in-2014-configuring-vim/
[12]:http://benmccormick.org/2014/06/30/learning-vim-in-2014-the-basics/
[13]:http://benmccormick.org/2014/07/02/learning-vim-in-2014-vim-as-language/

137
sources/tech/20141004 Practical Lessons in Peer Code Review.md Normal file
View File

@ -0,0 +1,137 @@
# Practical Lessons in Peer Code Review #
Millions of years ago, apes descended from the trees, evolved opposable thumbs and—eventually—turned into human beings.
We see mandatory code reviews in a similar light: something that separates human from beast on the rolling grasslands of the software
development savanna.
Nonetheless, I sometimes hear comments like these from our team members:
"Code reviews on this project are a waste of time."
"I don't have time to do code reviews."
"My release is delayed because my dastardly colleague hasn't done my review yet."
"Can you believe my colleague wants me to change something in my code? Please explain to them that the delicate balance of the universe will
be disrupted if my pristine, elegant code is altered in any way."
### Why do we do code reviews? ###
Let us remember, first of all, why we do code reviews. One of the most important goals of any professional software developer is to
continually improve the quality of their work. Even if your team is packed with talented programmers, you aren't going to distinguish
yourselves from a capable freelancer unless you work as a team. Code reviews are one of the most important ways to achieve this. In
particular, they:
provide a second pair of eyes to find defects and better ways of doing something.
ensure that at least one other person is familiar with your code.
help train new staff by exposing them to the code of more experienced developers.
promote knowledge sharing by exposing both the reviewer and reviewee to the good ideas and practices of the other.
encourage developers to be more thorough in their work since they know it will be reviewed by one of their colleagues.
### Doing thorough reviews ###
However, these goals cannot be achieved unless appropriate time and care are devoted to reviews. Just scrolling through a patch, making sure
that the indentation is correct and that all the variables use lower camel case, does not constitute a thorough code review. It is
instructive to consider pair programming, which is a fairly popular practice and adds an overhead of 100% to all development time, as the
baseline for code review effort. You can spend a lot of time on code reviews and still use much less overall engineer time than pair
programming.
My feeling is that something around 25% of the original development time should be spent on code reviews. For example, if a developer takes
two days to implement a story, the reviewer should spend roughly four hours reviewing it.
Of course, it isn't primarily important how much time you spend on a review as long as the review is done correctly. Specifically, you must
understand the code you are reviewing. This doesn't just mean that you know the syntax of the language it is written in. It means that you
must understand how the code fits into the larger context of the application, component or library it is part of. If you don't grasp all the
implications of every line of code, then your reviews are not going to be very valuable. This is why good reviews cannot be done quickly: it
takes time to investigate the various code paths that can trigger a given function, to ensure that third-party APIs are used correctly
(including any edge cases) and so forth.
In addition to looking for defects or other problems in the code you are reviewing, you should ensure that:
All necessary tests are included.
Appropriate design documentation has been written.
Even developers who are good about writing tests and documentation don't always remember to update them when they change their code. A
gentle nudge from the code reviewer when appropriate is vital to ensure that they don't go stale over time.
### Preventing code review overload ###
If your team does mandatory code reviews, there is the danger that your code review backlog will build up to the point where it is
unmanageable. If you don't do any reviews for two weeks, you can easily have several days of reviews to catch up on. This means that your
own development work will take a large and unexpected hit when you finally decide to deal with them. It also makes it a lot harder to do
good reviews since proper code reviews require intense and sustained mental effort. It is difficult to keep this up for days on end.
For this reason, developers should strive to empty their review backlog every day. One approach is to tackle reviews first thing in the
morning. By doing all outstanding reviews before you start your own development work, you can keep the review situation from getting out of
hand. Some might prefer to do reviews before or after the midday break or at the end of the day. Whenever you do them, by considering code
reviews as part of your regular daily work and not a distraction, you avoid:
Not having time to deal with your review backlog.
Delaying a release because your reviews aren't done yet.
Posting reviews that are no longer relevant since the code has changed so much in the meantime.
Doing poor reviews since you have to rush through them at the last minute.
### Writing reviewable code ###
The reviewer is not always the one responsible for out-of-control review backlogs. If my colleague spends a week adding code willy-nilly
across a large project then the patch they post is going to be really hard to review. There will be too much to get through in one session.
It will be difficult to understand the purpose and underlying architecture of the code.
This is one of many reasons why it is important to split your work into manageable units. We use scrum methodology so the appropriate unit
for us is the story. By making an effort to organize our work by story and submit reviews that pertain only to the specific story we are
working on, we write code that is much easier to review. Your team may use another methodology but the principle is the same.
There are other prerequisites to writing reviewable code. If there are tricky architectural decisions to be made, it makes sense to meet
with the reviewer beforehand to discuss them. This will make it much easier for the reviewer to understand your code, since they will know
what you are trying to achieve and how you plan to achieve it. This also helps avoid the situation where you have to rewrite large swathes
of code after the reviewer suggests a different and better approach.
Project architecture should be described in detail in your design documentation. This is important anyway since it enables a new project
member to get up to speed and understand the existing code base. It has the further advantage of helping a reviewer to do their job
properly. Unit tests are also helpful in illustrating to the reviewer how components should be used.
If you are including third-party code in your patch, commit it separately. It is much harder to review code properly when 9000 lines of
jQuery are dropped into the middle.
One of the most important steps for creating reviewable code is to annotate your code reviews. This means that you go through the review
yourself and add comments anywhere you feel that this will help the reviewer to understand what is going on. I have found that annotating
code takes relatively little time (often just a few minutes) and makes a massive difference in how quickly and well the code can be
reviewed. Of course, code comments have many of the same advantages and should be used where appropriate, but often a review annotation
makes more sense. As a bonus, studies have shown that developers find many defects in their own code while rereading and annotating it.
### Large code refactorings ###
Sometimes it is necessary to refactor a code base in a way that affects many components. In the case of a large application, this can take
several days (or more) and result in a huge patch. In these cases a standard code review may be impractical.
The best solution is to refactor code incrementally. Figure out a partial change of reasonable scope that results in a working code base and
brings you in the direction you want to go. Once that change has been completed and a review posted, proceed to a second incremental change
and so forth until the full refactoring has been completed. This might not always be possible, but with thought and planning it is usually
realistic to avoid massive monolithic patches when refactoring. It might take more time for the developer to refactor in this way, but it
also leads to better quality code as well as making reviews much easier.
If it really isn't possible to refactor code incrementally (which probably says something about how well the original code was written and
organized), one solution might be to do pair programming instead of code reviews while working on the refactoring.
### Resolving disputes ###
Your team is doubtless made up of intelligent professionals, and in almost all cases it should be possible to come an agreement when
opinions about a specific coding question differ. As a developer, keep an open mind and be prepared to compromise if your reviewer prefers a
different approach. Don't take a proprietary attitude to your code and don't take review comments personally. Just because someone feels
that you should refactor some duplicated code into a reusable function, it doesn't mean that you are any less of an attractive, brilliant
and charming individual.
As a reviewer, be tactful. Before suggesting changes, consider whether your proposal is really better or just a matter of taste. You will
have more success if you choose your battles and concentrate on areas where the original code clearly requires improvement. Say things like
"it might be worth considering..." or "some people recommend..." instead of "my pet hamster could write a more efficient sorting algorithm
than this."
If you really can't find middle ground, ask a third developer who both of you respect to take a look and give their opinion.
--------------------------------------------------------------------------------
via: http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/
作者：[Matt][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出

113
translated/tech/[翻译完成]20140929 Learning Vim in 2014--Working with Files.md Normal file
View File

@ -0,0 +1,113 @@
2014年学习如何使用vim处理文件工作
================================================================================
作为一名开发者你不能够只化时间去写你想要的代码。其中最难以处理的部分是我的工作只使用vim来处理文本。我感觉到很无语与无比的蛋疼,vim没有自己额外文件查看系统与内部打开与切换文件功能。因此，继vim之后，我主要使用Eclipse 和 Sublime Text.
就此,我非常欣赏深度定制的vim文件管理功能。在工作环境上我已经装配了这些工具，甚至比起那些视觉编辑器好很多。因为这个是纯键盘操作，促使我可以更加快地移动我的代码。第一篇文章使我明白这个vim内建功能只是处理文件的另一选择。在这篇文章里我会带你去认识vim文件管理功能与使用更高级的插件。
### 基础篇:打开新文件 ###
学习vim其中最大的一个障碍是缺少可视提示，不像现在的GUI图形编辑器，当你在终端打开一个新的vim是没有明显的提示去提醒你去走什么，所有事情都是靠键盘输入，同时也没有更多更好的界面交互，vim新手需要习惯如何靠自己去查找一些基本的操作指令。好吧，让我开始学习基础吧。
创建新文件的命令是**:e <filename>或:e** 打开一个新缓冲区保存文件内容。如果文件不存在它会开辟一个缓冲区去保存与修改你指定文件。缓冲区是vim是术语，意为"保存文本块到内存"。文本是否能够与存在的文件关联，要看是否每个你打开的文件都对应一个缓冲区。
打开文件与修改文件之后，你可以使用**:w**命令来保存在缓冲区的文件内容到文件里面，如果缓冲区不能关联你的文件或者你想保存到另外一个地方，你需要使用**:w <filename>**来保存指定地方。
这些是vim处理文件的基本知识，很多的开发者都掌握了这些命令，这些技巧你都需要掌握。vim提供了很多技巧让人去深挖。
### 缓冲区管理 ###
基础掌握了，就让我来说更多关于缓冲区得东西，vim处理打开文件与其他编辑器有一点不同，打开的文件不会作为一个标签留在一个可视地方，而是只允许你同时只有一个文件在缓冲区打开，vim允许你多个缓存打开。一些会显示出来，另外一些就不会，你需要用**:ls**来查看已经打开的缓存，这个命令会显示每个打开的缓存区，同时会有它们的序码，你可以通过这些序码实用**:b <buffer-number>**来切换或者使用循序移动命令**:bnext** 和 **:bprevious** 也可以使用它们的缩写**:bn**和**:bp**。
这些命令是vim管理文件缓冲区的一个基础，我发现他们不会按照我的思维去映射出来。我不想关心缓冲区的顺序，我只想按照我的思维去到那个文件或者想在当前这个文件.因此必需了解vim更深的缓存模式，我不是推荐你必须内部命令来作为主要的文件管理方案。但这些的确是很强大可行的选择。
![](http://benmccormick.org/content/images/2014/Jul/skitch.jpeg)
### 分屏 ###
分屏是vim其中一个最好用的管理文件功能，在vim
你可以在当前窗同时分开2个窗口，可以按照你喜欢的配置去重设大小和分配,这个很特别可以在不同地方同时打开6文件每个文件都拥有自己的窗口大少
你可以通过命令**:sp <filename>**来新建水平分割窗口或者 **:vs <filename>**垂直分割窗口。你可以使用这些关键命令去重置你想要的窗口,
老实说，我喜欢用鼠标处理vim任务，因为鼠标能够给我更加准确的两列的宽度而不需要猜大概的宽度。
创建新的分屏后，你需要使用**ctrl-w
[h|j|k|l]**来向后向前切换。这个有少少笨拙，但这个确实很重要很普遍很容易很高效的操作.如果你经常使用分屏,我建议你去.vimrc使用以下代码q去设置别名为**ctrl-h** **ctrl-j** 等等。
nnoremap <C-J> <C-W><C-J> "Ctrl-j to move down a split
nnoremap <C-K> <C-W><C-K> "Ctrl-k to move up a split
nnoremap <C-L> <C-W><C-L> "Ctrl-l to move right a split
nnoremap <C-H> <C-W><C-H> "Ctrl-h to move left a split
### 跳转表 ###
分屏是解决多个关联文件同时查看问题,但我们仍然不能满足打开文件与隐藏文件之间快速移动。这时跳转表是一个能够解决的工具。
跳转表是众多插件中看其来奇怪而且很少使用。vim能够追踪每一步命令还有切换你正在修改的文件。每次从一个分屏窗口跳到另外一个，vim都会添加记录到跳转表里面。这个记录你去过的地方，这样就不需要担心之前的文件在哪里，你可以使用快捷键去快速追溯你的踪迹。**Ctrl-o**允许你返回你上一次地方。重复操作几次就能够返回到你最先编写的代码段地方。你可以使用**ctrl-i**来向前返回。当你在调试多个文件或两个文件之间切换能够发挥极大的快速移动功能。
### 插件 ###
如果你想vim像Sublime Text 或者Atom一样，我就让你认清一下，这里有很好的机会让你看到一些难懂，可怕和低效的事情。例如大家会发出"当Sublime有了模糊查找功能，为什么我一定要输入全路径才能够打开文件" "没有侧边栏显示目录树我怎样查看项目结构" 。但vim有了解决方案。这些方案不需要破坏vim的核心。我只需要经常修改vim配置与添加一些最新的插件，这里有3个有用的插件可以让你像Sublime管理文件
- [CtrlP][1] 是一个跟Sublime的"Go to Anything"栏一样模糊查找文件.它快如闪电并且非常可配置性。我使用它最主要打开文件。我只需知道部分的文件名字不需要记住整个项目结构就可以查找了
- [The NERDTree][2]
这个一个文件管理夹插件，它重复了很多编辑器的有的侧边文件管理夹功能。我实际上很少用它，对于我模糊查找会更加快。对于你接手一个项目，尝试学习项目结构与了解什么可以用是非常方便的，NERDTree是可以自己定制配置，安装它能够代替vim内置的目录工具。
- [Ack.vim][3] 是一个专为vim的代码搜索插件，它允许你跨项目搜索文本。通过Ack 或 Ag 去高亮查找
[第二个极其好用的搜索工具][4]，允许你在任何时候在你项目之间快速搜索跳转
在vim核心与它的插件生态系统之间，vim 提供足够的工具允许你构建你想要得工作环境。文件管理是软件开发系统的最核心部分并且你值得拥有体验的权利
开始是需要通过很长的时间去理解它们，然后才找到你感觉舒服的工作流程之后才开始添加工具在上面。但依然值得你去使用，当你不需要头爆去理解如何去使用就能够轻易编写你的代码。
### 更多插件资源 ###
- [Seamlessly Navigate Vim & Tmux Splits][5] 这个插件需要每一个想使用它的人都要懂得实用[tmux][6],这个跟vim的splits 一样简单好用
- [Using Tab Pages][7] 它是一个vim的标签功能插件，虽然它的名字用起来有一点疑惑，但我不能说它是文件管理器。
对如何在有多个工作可视区使用"tab
pages" 在vim wiki 网站上有更好的概述
- [Vimcasts: The edit command][8] 一般来说 Vimcasts
是大家学习vim的一个好资源。这个屏幕截图与一些内置工作流程是很好描述之前说得文件操作方面的知识
### 订阅 ###
这篇文章通过第三个方面介绍如何通过一些好的手法学习vim。如果你喜欢这篇文章你可以通过[feed][8]来订阅或email我[mailing
list][10]。在这个星期javascript小插曲之后，下星期我会继续介绍vim的配置方面的东西，你可以先看基础篇：使用vim
看我前2篇系列文章和vim与vi的语言
--------------------------------------------------------------------------------
via: http://benmccormick.org/2014/07/07/learning-vim-in-2014-working-with-files/
作者：[Ben McCormick][a]
译者：[译者ID](https://github.com/haimingfg)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[a]:http://benmccormick.org/2014/07/07/learning-vim-in-2014-working-with-files/
[1]:https://github.com/kien/ctrlp.vim
[2]:https://github.com/scrooloose/nerdtree
[3]:https://github.com/mileszs/ack.vim
[4]:http://benmccormick.org/2013/11/25/a-look-at-ack/
[5]:http://robots.thoughtbot.com/seamlessly-navigate-vim-and-tmux-splits
[6]:http://tmux.sourceforge.net/
[7]:http://vim.wikia.com/wiki/Using_tab_pages
[8]:http://vimcasts.org/episodes/the-edit-command/
[9]:http://feedpress.me/benmccormick
[10]:http://eepurl.com/WFYon
[11]:http://benmccormick.org/2014/07/14/learning-vim-in-2014-configuring-vim/
[12]:http://benmccormick.org/2014/06/30/learning-vim-in-2014-the-basics/
[13]:http://benmccormick.org/2014/07/02/learning-vim-in-2014-vim-as-language/