Gaze/SpaceVim
1
0
Fork 0
mirror of https://github.com/SpaceVim/SpaceVim.git synced 2025-02-02 22:20:06 +08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #1351 from floatval/floatval-branch

Browse Source 
Update translator
This commit is contained in:
Wang Shidong 2018-01-30 23:14:16 +08:00 committed by GitHub
commit bbcf120c91
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 208 additions and 206 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/cn/about.md
View File

@ -18,9 +18,10 @@ lang: cn
## 标准
- Do not regress from origin
- Decide outcomes by weighing cost and benefit
- prefer usability over tradition if the benefits are overwhelming
- Give usability a chance™
- 不要从 origin 回归.
- 通过权衡成本和收益来决定结果.
- 收益与传统相比较,当收益是压倒性的时候,我们选择收益,而非坚持传统.
- 给可用性一个机会.
## 鸣谢

263
docs/cn/conventions.md
View File

@ -10,29 +10,29 @@ lang: cn
- [Commit emoji 规范](#commit-emoji-规范)
- [vim 脚本代码规范](#vim-脚本代码规范)
- [Portability](#portability)
- [Strings](#strings)
- [Matching Strings](#matching-strings)
- [Regular Expressions](#regular-expressions)
- [Dangerous commands](#dangerous-commands)
- [Fragile commands](#fragile-commands)
- [Catching Exceptions](#catching-exceptions)
- [General Guidelines](#general-guidelines)
- [Messaging](#messaging)
- [Type checking](#type-checking)
- [可移植性](#可移植性)
- [字符串](#字符串)
- [匹配字符串](#匹配字符串)
- [正则表达式](#正则表达式)
- [危险命令](#危险命令)
- [脆弱命令](#脆弱命令)
- [捕获异常](#捕获异常)
- [引导总览](#引导总览)
- [信息](#信息)
- [类型检查](#类型检查)
- [Python](#python)
- [Other Languages](#other-languages)
- [Plugin layout](#plugin-layout)
- [Functions](#functions)
- [Commands](#commands)
- [Autocommands](#autocommands)
- [Mappings](#mappings)
- [Errors](#errors)
- [Settings](#settings)
- [Style](#style)
- [Whitespace](#whitespace)
- [Line Continuations](#line-continuations)
- [Naming](#naming)
- [其他语言](#其他语言)
- [插件布局](#插件布局)
- [功能](#功能)
- [命令](#命令)
- [自动命令](#autocommands)
- [映射](#映射)
- [错误](#错误)
- [设置](#设置)
- [风格](#风格)
- [空白行](#空白行)
- [连续行](#连续行)
- [命名](#命名)
- [markdown 代码规范](#markdown-代码规范)
- [感谢:](#感谢)
@ -50,181 +50,178 @@ lang: cn
## vim 脚本代码规范
### Portability
### 可移植性
Vim is highly configurable. Users can change many of the default settings, including the case sensitivity, the regular expression rules, the substitution rules, and more. In order for your vimscript to work for all users, follow these guidelines:
vim 具有高度可定制性. 用户可以更改很多的默认设置, 包括区分大小写, 正则表达式规则, 替换规则, 还有很多别的.为了让你的脚本可以适用于所有用户,请遵循下面的引导:
#### Strings
#### 字符串
**Prefer single quoted strings**
**推荐单引号字符串**
Double quoted strings are semantically different in vimscript, and you probably don't want them (they break regexes).
双引号字符串在vim脚本中的语义跟其他语言中不一样, 你可能并不需要他们.(他们打破了正则表达式)
Use double quoted strings when you need an escape sequence (such as "\\n") or if you know it doesn't matter and you need to embed single quotes.
当你需要转义时使用双引号(例如 "\\n") 或者 你需要嵌入单引号.(例如"Abce'a'")
#### Matching Strings
#### 匹配字符串
**Use the =~# or =~? operator families over the =~ family.**
**用 =~# 或者 =~? 操作符家族 替换=~家族.**
The matching behavior depends upon the user's ignorecase and smartcase settings and on whether you compare them with the =~, =~#, or =~? family of operators. Use the =~# and =~? operator families explicitly when comparing strings unless you explicitly need to honor the user's case sensitivity settings.
匹配行为取决于用户的忽略大小写设置(ignorecase)和智能大小写(smartcase)设置以及你是否将他们与 =~, =~# 或 =~?操作符家族进行比较.使用 =~# 和 =~? 操作符家族 显式的比较字符串,除非明确的要遵守用户的大小写语义设置.
#### Regular Expressions
**Prefix all regexes with one of \\m, \\v, \\M, or \\V.**
**所有的正则表达前缀都是 \\m, \\v, \\M, or \\V. 其中之一**
In addition to the case sensitivity settings, regex behavior depends upon the user's nomagic setting. To make regexes act like nomagic and noignorecase are set, prepend all regexes with one of \\m, \\v, \\M, or \\V.
在传统的大小写语义设置下,正则表达式的行为取决于用户的无魔法(nomagic)设置. 为了让正则表达式的行为像无魔法(nomagic)和 不忽略大小写(noignorecase)设置下一样, 在所有正则表达式前, 前置 \\m, \\v, \\M, or \\V.之一
You are welcome to use other magic levels (\\v) and case sensitivities (\\c) so long as they are intentional and explicit.
欢迎你使用其他等级的魔法(magic levels)(\\v) 和大小写敏感性(\\c) 只要确定了他们是你有意为之并且是明确的.
#### Dangerous commands
#### 危险命令
**Avoid commands with unintended side effects.**
**避免命令意想不到的副作用**
Avoid using :s[ubstitute] as it moves the cursor and prints error messages. Prefer functions (such as search()) better suited to scripts.
The meaning of the g flag depends upon the gdefault setting. If you do use :substitute you must save gdefault, set it to 0 or 1, perform the substitution, and then restore it.
避免使用 :s[ubtitute] 因为它引动光标并打印错误消息. 首选功能(例如 search()) 比s[ubtitute]更适用于脚本.
这意味着 g 标志取决于 上层中 gdefault 设置. 如果你用了 :subtitute 你必须要保存 gdefault, 把它设置为 0 或 1 预先生成替换并且在操作完成后还原它.
For many vim commands, functions exist that do the same thing with fewer side effects. See :help functions() for a list of built-in functions.
有很多内置的vim命令, 函数, 可以在更小的影响下完成同样的事情. 查看:help functions() 查看内置的函数表.
#### Fragile commands
#### 脆弱命令
**Avoid commands that rely on user settings.**
**避免依赖于用户设置的命令**
Always use normal! instead of normal. The latter depends upon the user's key mappings and could do anything.
一直使用普通模式(normal) 在普通模式下安装.后者取决于用户的按键映射,可以做任何事情.
Avoid :s[ubstitute], as its behavior depends upon a number of local settings.
避免 :s[ubtitute],因为它的行为取决于上层的一些运行设置.
The same applies to other commands not listed here.
其他同样的命令的应用,在此不再列出.
#### Catching Exceptions
#### 捕获异常
**Match error codes, not error text.**
**匹配异常代码,而非异常文本.**
Error text may be locale dependant.
错误文本可能与语言环境(local dependant)有关.
### General Guidelines
### 引导总览
#### Messaging
#### 信息
**Message the user infrequently.**
**罕见的用户信息.**
Loud scripts are annoying. Message the user only when:
提示信息多的脚本很容易让人厌烦. 信息只在以下情况中出现:
- A long-running process has kicked off.
- An error has occurred.
- 一个需要较长时间运行的进程开始时.
- 发生了某个错误.
#### Type checking
#### 类型检查
**Use strict and explicit checks where possible.**
**尽可能严格和明确的进行检查.**
Vimscript has unsafe, unintuitive behavior when dealing with some types. For instance, 0 == 'foo' evaluates to true.
vim脚本在处理一些类型(style)时有不安全,不直观的行为. 举个例子, 0 == 'foo' 认证为真.(evalutaes to true.)
Use strict comparison operators where possible. When comparing against a string literal, use the is# operator. Otherwise, prefer maktaba#value#IsEqual or check type() explicitly.
尽可能的用严格的比较操作. 当二次比较字母的时候用 is# 操作符. 除此之外, 更适合用 maktaba#value#IsEqual 或 明确使用 check htype().
Check variable types explicitly before using them. Use functions from maktaba#ensure, or check maktaba#value or type() and throw your own errors.
在使用变量前,明确检查变量的类型. 使用 maktaba#ensure 中的函数(functions from maktaba#ensure) 或 check maktaba#value 或 type() 找出你自己的错误.
Use :unlet for variables that may change types, particularly those assigned inside loops.
使用 :unlet 对变量使用(:unlet)可能更改变量的类型, 尤其是在循环中赋值的时候.
#### Python
**Use sparingly.**
**保守使用.**
Use python only when it provides critical functionality, for example when writing threaded code.
只在它提供关键功能时使用,例如在编写线程代码(threaded code)时.
#### Other Languages
#### 其他语言
**Use vimscript instead.**
**用vim脚本替代.**
Avoid using other scripting languages such as ruby and lua. We can not guarantee that the end user's vim has been compiled with support for non-vimscript languages.
避免使用其他的脚本语言,例如 ruby 和 lua. 我们不能保证,用户的vim已经完成了对 non-vimscript languages的支持.
#### 插件布局
#### Plugin layout
**将功能组织到模块化插件中**
**Organize functionality into modular plugins**
把你的功能组织成为一个插件,统一放在一个文件夹中(或者是代码仓库)分享你的插件名(用一个" vim- "前缀 或者需要的话使用 ".vim" 后缀).它应该可以被拆分到 plugin/, autoload/, 等等. 子目录应该以addon-info.json格式声明元数据(详情参见 VAM 文档).
Group your functionality as a plugin, unified in one directory (or code repository) which shares your plugin's name (with a "vim-" prefix or ".vim" suffix if desired). It should be split into plugin/, autoload/, etc. subdirectories as necessary, and it should declare metadata in the addon-info.json format (see the VAM documentation for details).
#### 功能
#### Functions
**在 autoload/ 目录中, 用 [!] 和 [abort]定义.**
**In the autoload/ directory, defined with [!] and [abort].**
自动加载允许按需加载函数,这使得启动时间更快,并且强制执行函数命名空间.(namespacing)
Autoloading allows functions to be loaded on demand, which makes startuptime faster and enforces function namespacing.
脚本本地函数(Script-local functions)是被欢迎的, 但是只应存活在 atuoload/ 和 被自动运行函数调用中.
Script-local functions are welcome, but should also live in autoload/ and be called by autoloaded functions.
非库函数(Non-library) 插件应该提供命令来代替函数. 命令逻辑应该被提取到功能和自动加载.
Non-library plugins should expose commands instead of functions. Command logic should be extracted into functions and autoloaded.
[!] 允许开发者无需申诉(complaint)便可重新加载他们的功能.
[!] allows developers to reload their functions without complaint.
[abort] 强制函数再遇到错误时停止.
[abort] forces the function to halt when it encounters an error.
#### 命令
#### Commands
**在 plugin/commands.vim 中 或 the ftplugin/ 目录中, 不用[!]定义.**
**In the plugin/commands.vim or under the ftplugin/ directory, defined without [!].**
General commands go in plugin/commands.vim. Filetype-specific commands go in ftplugin/.
一般命令(general commands)进入 plugin/commands.vim. 文件类型特殊命令(Filetype-specific) 进入 ftplugin/.
Excluding [!] prevents your plugin from silently clobbering existing commands. Command conflicts should be resolved by the user.
#### Autocommands
#### 自动命令
**Place them in plugin/autocmds.vim, within augroups.**
**在 plugin/autocmds.vim 中用参数组(augroups) 替换他们.**
Place all autocommands in augroups.
把所有的自动命令(autocommands)替换进参数组(augroups).
The augroup name should be unique. It should either be, or be prefixed with, the plugin name.
每个参数组都应当有一个独特的名字. 或许你应该给它加上插件名前缀.
Clear the augroup with autocmd! before defining new autocommands in the augroup. This makes your plugin re-entrable.
在定义一个新的自动命令(autocommands)前,用 autocmd! 清除参数组(augroup).这可以让你的插件复用(re-entrable).
#### Mappings
#### 映射
**Place them in plugin/mappings.vim, using maktaba#plugin#MapPrefix to get a prefix.**
**在 plugin/mappings.vim 中用 maktaba#plugin#MapPrefix 获取前缀.**
All key mappings should be defined in plugin/mappings.vim.
所有的按键映射都应当在 plugin/mappings.vim 中被定义.
Partial mappings (see :help using-<Plug>.) should be defined in plugin/plugs.vim.
练习映射(参看:help using-<Plugin>.)应当在 plugin/plugs.vim 中被定义.
**Always use the noremap family of commands.**
**一直使用 noremap family 命令.**
Your plugins generally shouldn't introduce mappings, but if they do, the map command respects the users existing mappings and could do anything.
一般你的插件不应引入映射, 但是你如果引入了映射的话,这个映射会取代用户现存的映射并且可以做任何事情.(could do anything.)
#### Errors
#### 错误
When using catch, match the error code rather than the error text.
当你需要捕获异常的时候,你应当匹配错误代码而不是匹配错误文本.
#### Settings
#### 设置
**Change settings locally**
**在本地更改设置**
Use :setlocal and &l: instead of :set and & unless you have explicit reason to do otherwise.
用 :setlocal 和 &l: 替代 :set 和 & 除非你有明确的原因不去使用他们.
### Style
### 风格
Follow google style conventions. When in doubt, treat vimscript style like
python style.
按照谷歌风格的约定. 有疑惑时请参照 python 的风格来修改 vimscript 的风格.
#### Whitespace
#### 空白行
**Similar to python.**
**类似python.**
- Use two spaces for indents
- Do not use tabs
- Use spaces around operators
- 缩进使用两个空格
- 不要使用tabs
- 在操作符(operators)前后使用空格
This does not apply to arguments to commands.
不要以参数列表(arguments)的形式来使用命令.
let s:variable = "concatenated " . "strings"
command -range=% MyCommand
- Do not introduce trailing whitespace
- 不要在空白行处留下空白字符
You need not go out of your way to remove it.
你无需用自己的方法去清除它.
Trailing whitespace is allowed in mappings which prep commands for user input,
such as "noremap <leader>gf :grep -f ".
准备获取用户输入的命令映射中允许留空白字符, 例如 "noremap <leader>gf :grep -f "
- Restrict lines to 80 columns wide
- Indent continued lines by four spaces
- Do not align arguments of commands
- 每行限制80个字符的宽度
- 缩进保持4个空格
- 不要对齐命令的参数列表
```diff
+command -bang MyCommand call myplugin#foo()
@ -233,9 +230,9 @@ such as "noremap <leader>gf :grep -f ".
-command MyCommand2 call myplugin#bar()
```
#### Line Continuations
#### 连续行
- Prefer line continuations on semantic boundaries.
- 尽量在单词语义的边界分割连续行
```diff
+command SomeLongCommand
@ -244,9 +241,9 @@ such as "noremap <leader>gf :grep -f ".
- \ some#function()
```
- Place one space after the backslash denoting a line continuation.
- 反斜杠后添加一个空格代表续行.
When continuing a multi-line command a pipe can be substituted for this space as necessary, as follows:
如果需要连续使用多行命令,可以使用管道符来代替空格, 就像下面这样:
```viml
autocommand BufEnter <buffer>
@ -257,33 +254,33 @@ autocommand BufEnter <buffer>
\|endif
```
- Do not continue multi-line commands when you can avoid it. Prefer function calls.
- 你应该尽量避免使用多行命令,可以用函数调用来替代它.
#### Naming
#### 命名
In general, use plugin-names-like-this, FunctionNamesLikeThis, CommandNamesLikeThis, augroup_names_like_this, variable_names_like_this.
Always prefix variables with their scope.
总的来说,使用像这样的插件名 plugin-names-like-this , 像这样的函数名 FunctionNamesLikeThis , 像这样的命令名 CommandNamesLikeThis, 像这样的参数组 augroup_names_like_this , 像这样的变量名 variable_names_like_this.
总是在变量名前加上他们的范围前缀
- plugin-names-like-this
Keep them short and sweet.
保持简单易于理解.
- FunctionNamesLikeThis
- Prefix script-local functions with s:
- Autoloaded functions may not have a scope prefix.
- Do not create global functions. Use autoloaded functions instead.
- 本地脚本函数的前缀为s:
- 自动运行函数(autoload functions)可以没有范围前缀.
- 不要编写(creat)全局函数. 用自动运行函数(autoloaded functions)来替代全局函数.
- CommandNamesLikeThis
Prefer succinct command names over common command prefixes.
通用命令优先于一般的前缀.
- variable_names_like_this
Augroup names count as variables for naming purposes.
- Prefix all variables with their scope.
- Global variables with g:
- Script-local variables with s:
- Function arguments with a:
- Function-local variables with l:
- Vim-predefined variables with v:
- Buffer-local variables with b:
- g:, s:, and a: must always be used.
- b: changes the variable semantics; use it when you want buffer-local semantics.
参数组(augroup)名字计数作为变量的命名方向.
- 所有的变量据需要加上他们的范围前缀.
- 全局变量的前置为 g:
- 本地脚本变量的前置为 s:
- 函数的参数前置为 a:
- 本地函数的变量前缀为 l:
- Vim预定义(Vim-predefinded)变量前缀为 v:
- 本地缓冲区(Buffer-local)变量的前缀为 b:
- g:, s:, 和 a: 前缀必须使用.
- b: 当你想要改变本地缓冲区(buffer-local)的变量的语义时前置为 b:
- l: and v: should be used for consistency, future proofing, and to avoid subtle bugs. They are not strictly required. Add them in new code but don’t go out of your way to add them elsewhere.
## markdown 代码规范

136
docs/cn/development.md
View File

@ -8,8 +8,8 @@ lang: cn
<!-- vim-markdown-toc GFM -->
- [Asking for help](#asking-for-help)
- [Reporting issues](#reporting-issues)
- [寻求帮助](#寻求帮助)
- [Reporting issues](#反馈错误)
- [Contributing code](#contributing-code)
- [License](#license)
- [Conventions](#conventions)
@ -29,40 +29,43 @@ lang: cn
<!-- vim-markdown-toc -->
SpaceVim is an effort of all the volunteers, we encourage you to pitch in. The community makes SpaceVim what it is.
We have a few guidelines, which we ask all contributors to follow.
SpaceVim 是每个志愿者的努力的结晶,我们鼓励你参与进来. SpaceVim 是由社区驱动的.
下面是关于每个贡献者都应当遵守的简单规则的引导.
Development happens in the GitHub repository. here is a throughput graph of the repository for the last few weeks:
在GitHub 仓库上进行开发. 下面是最近几周的仓库快照:
[![Throughput Graph](https://graphs.waffle.io/SpaceVim/SpaceVim/throughput.svg)](https://waffle.io/SpaceVim/SpaceVim/metrics/throughput)
You can only consider reading the sections relevant to what you are going to do:
你可以只阅读下面内容中的,你需要用到的部分:
- [Asking for help](#asking-for-help) if you are about to open an issue to ask a question.
- [Reporting issues](#reporting-issues) if you are about to open a new issue.
- [Contributing code](#contributing-code) if you are about to send a pull-request.
- [Asking for help](#寻求帮助) 建立issue的帮助
- [Reporting issues](#反馈错误) 反馈问题的帮助
- [Contributing code](#贡献代码) 建立PR的帮助
## Asking for help
## 寻求帮助
If you want to ask an usage question, be sure to look first into some places as it may hold the answers:
在你建立issue 之前,先确认你已经浏览过下面的faq以及SpaceVim文档
- <kbd>:h SpaceVim-faq</kbd>: Some of the most frequently asked questions are answered there.
- [SpaceVim documentation](https://spacevim.org/documentation): It is the general documentation of SpaceVim.
- <kbd>:h SpaceVim-faq</kbd>: 一些常见问题及解决方法
- [SpaceVim documentation](https://spacevim.org/documentation): SpaceVim的官方文档
## Reporting issues
## 反馈问题
Issues have to be reported on [issues tracker](https://github.com/SpaceVim/SpaceVim/issues), Please:
请先阅读下面内容,再通过 [issues tracker](https://github.com/SpaceVim/SpaceVim/issues)进行反馈:
- Check that there is no duplicate issue in the issues tracker, you can search for keywords in the issues tracker.
- Check that the issue has not been fixed in latest version of SpaceVim, please update your SpaceVim, and try to reproduce the bug here.
- Use a clear title and follow the issue template.
- Include details on how to reproduce it, just like a step by step guide.
## Contributing code
- 检查错误追踪中是否存在重复的问题, 你可以通过在错误追踪中搜索关键词来确认,错误追踪中是否存在重复的问题
Code contributions are welcome. Please read the following sections carefully. In any case, feel free to join us on the [gitter chat](https://gitter.im/SpaceVim/SpaceVim) to ask questions about contributing!
- 检查问题是否在最新版的SpaceVim中修复, 请更新你的SpaceVim, 然后进行bug重现操作.
### License
- 按照下面的问题格式,建立清晰的问题标题
- 包括bug出现的细节, 一步一步重现bug出现的操作
## 贡献代码
我们非常期待您的贡献. 在此之前,请您认真阅读下面的内容. 在任何情况下,都可以轻松的加入我们[gitter chat](https://gitter.im/SpaceVim/SpaceVim)进行提问和贡献代码.
### 证书
The license is MIT for all the parts of SpaceVim. this includes:
@ -71,58 +74,58 @@ The license is MIT for all the parts of SpaceVim. this includes:
For files not belonging to SpaceVim like local packages and libraries, refer to the header file. Those files should not have an empty header, we may not accept code without a proper header file.
### Conventions
### 公约
SpaceVim is based on conventions, mainly for naming functions, keybindings definition and writing documentation. Please read the [conventions](https://spacevim.org/conventions/) before your first contribution to get to know them.
SpaceVim 建立在下面的公约上: 该公约主要包括了 函数的命名, 按键绑定的定义以及文档的写法. 请阅读下面的公约: [conventions](https://spacevim.org/conventions/) 在您进行贡献前,请确认您已经了解了以上公约的内容.
### Pull Request
#### Rebase your pr Branch on top of upstream master:
#### 在上游的主分支顶部压缩你的PR分支
- fork SpaceVim repository
- clone your repository
- fork SpaceVim 仓库
- 克隆你自己的仓库
```sh
git clone ${YOUR_OWN_REPOSITORY_URL}
```
- add upstream remote
- 添加远程上游
```sh
git remote add upstream https://github.com/SpaceVim/SpaceVim.git
```
- fetch upstream and rebase on top of upstream master
- 在上游的主分支中取回并且重新定位上游
```sh
git fetch upstream
git rebase upstream master
git rebase upstream/master
```
#### Ideally for simple PRs (most of them):
#### 抽象化的简单 PRs(绝大多数PRs都是这样的):
- Branch from `master`
- One topic per PR
- One commit per PR
- If you have several commits on different topics, close the PR and create one PR per topic
- If you still have several commits, squash them into only one commit
- 'master'中的分支
- 每个PR一个主题
- 每个PR一个提交
- 如果你有一些不同主题的提交, 请关闭PR 然后为每个主题创建一个新的PR.
- 如果你仍然有很多提交, 请把他们打包成一个提交
#### For complex PRs (big refactoring, etc):
Squash only the commits with uninteresting changes like typos, syntax fixes, etc… and keep the important and isolated steps in different commits.
#### 复杂的PRs (大的重构, 等):
只打包一些枯燥的提交,比如修改错别字,语法修复,等等... 把重要和独立的步骤分别放在不同的提交中.
Those PRs are merged and explicitly not fast-forwarded.
这些PRs被合并并且非明试快速转发.
提交信息
根据编写的内容提交信息 [Tim Pope’s guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html):
Commit messages
- 用现在时和祈使句: 例如"Fix bug", 而不是"fixed bug" 或者"fixes bug".
- 以大写字母开头,短摘要开头(72个字符或者更少),以空行结尾.
- 如果需要的话,可以用每行72个字符的格式添加一个或多个详细的段落.
- 每个独立的段落以空行结尾.
Write commit messages according to adapted [Tim Pope’s guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html):
- Use present tense and write in the imperative: “Fix bug”, not “fixed bug” or “fixes bug”.
- Start with a capitalized, short (72 characters or less) summary, followed by a blank line.
- If necessary, add one or more paragraphs with details, wrapped at 72 characters.
- Separate paragraphs by blank lines.
This is a model commit message:
这是一个提交信息的模版:
```gitcommit
Capitalized, short (72 chars or less) summary
@ -150,15 +153,16 @@ Further paragraphs come after blank lines.
[Gita] provide vim mode for Git commit messages, which helps you to comply to these guidelines.
### Contributing a layer
### Contributing a layer 贡献层
Please read the layers documentation first.
请先阅读层文档
Layer with no associated configuration will be rejected. For instance a layer with just a package and a hook can be easily replaced by the usage of the variable `g:spacevim_custom_plugins`.
未关联配置的层将会被拒绝.举个例子一个只有包和钩子的层,很简单的就能被替换为变量 `g:spacevim_custom_plugins`.
#### 文件头
#### File header
The file header for vim script should look like the following template:
vim 脚本的文件头,应该按照下面的格式:
```viml
"=============================================================================
@ -171,12 +175,12 @@ The file header for vim script should look like the following template:
```
You should replace FILENAME by the name of the file (e.g. foo.vim) and NAME by the name of the layer you are creating, don’t forget to replace **YOUR NAME** and **YOUR EMAIL** also.
你可以用文件(比如: foo.vim)来替换掉 FILENAME, 把NAME 用你编写的layer来代替, 同时不要忘了替换 **YOUR NAME** 和 **YOUR EMAIL**
#### 新layer的作者
#### Author of a new layer
把文件头中的默认作者名字(Shidong Wang)改为你自己的名字.
In the files header, change the default author name (Shidong Wang) to your name.
here is an example for creating a new layer names `foo`:
下面是一个创建一个名字为`foo`的新的layer的实例
1. fork SpaceVim repo
2. add a layer file `autoload/SpaceVim/layers/foo.vim` for `foo` layer.
@ -223,7 +227,6 @@ function! SpaceVim#layers#foo#plugins() abort
let plugins = []
call add(plugins, ['Shougo/foo.vim', {'option' : 'value'}])
call add(plugins, ['Shougo/foo_test.vim', {'option' : 'value'}])
return plugins
endfunction
@ -239,25 +242,25 @@ endfunction
5. Open `docs/layers/index.md`, run `:call SpaceVim#dev#layers#update()` to update layer list.
6. send PR to SpaceVim.
#### Contributor to an existing layer
#### 对现有的layer进行贡献
If you are contributing to an already existing layer, you should not modify any header file.
如果你正在对一个已经存在的layer进行贡献的话, 你不能修改文件头的任意地方
#### Contributing a keybinding
#### 贡献按键绑定
Mappings are an important part of SpaceVim.
按键映射是 SpaceVim 中非常重要的一部分.
First if you want to have some personal mappings, This can be done in your `~/.SpaceVim.d/init.vim` file.
如果你只想要拥有自己的按键映射的话, 你可以在`~/.SpaceVim.d/init.vim`文件中进行修改.
If you think it worth contributing a new mappings then be sure to read the documentation to find the best mappings, then create a Pull-Request with your changes.
如果你认为贡献一个新的按键映射有必要,那么请首先阅读文档,把自己的按键映射调整为最佳状态,然后用你更改后的按键映射进行提交PR.
ALWAYS document your new mappings or mappings changes inside the relevant documentation file. It should be the the layer file and the [documentation.md](https://spacevim.org/documentation).
始终牢记,在相关文档中记录新的按键映射或者是按键映射更改. 他应该是层文件和 [documentation.md](https://spacevim.org/documentation).
##### Language specified key bindings
All language specified key bindings are started with `SPC l` prefix.
##### 特定语言的按键绑定
we recommended to keep same language specified key bindings for different languages:
所有语言的特殊按键绑定都是以 `SPC l`前缀开始的.
| Key Binding | Description |
| ----------- | ------------------------------------------------ |
@ -271,7 +274,8 @@ we recommended to keep same language specified key bindings for different langua
| SPC l s l | send line and keep code buffer focused |
| SPC l s s | send selection text and keep code buffer focused |
All of these above key bindings are just recommended as default, but it also base on the language layer itself.
上面所有的按键绑定都是默认的建议, 但是它同样是基于自身的语言层的.
#### Contributing a banner

8
docs/cn/faq.md
View File

@ -1,10 +1,10 @@
### Where should I put my configration?
### 我应该把我的配置文件放到什么位置?
SpaceVim load custom configuration from `~/.SpaceVim.d/init.vim`.
SpaceVim 默认从 ~/.SpaceVim.d/init.vim 中加载配置文件.
1. E492: Not an editor command: ^M
1. E492: 未编辑的命令: ^M
The problem was git auto added ^M when cloning, solved by:
这个问题是git在克隆过程中,自动添加了^M, 可以通过下面的方法来解决:
```sh
git config --global core.autocrlf input