ld/amix-vimrc-mirror
1
0
Fork 0
mirror of https://github.com/amix/vimrc synced 2025-09-17 09:45:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Updated plugins

Browse Source
This commit is contained in:
Amir Salihefendic
2018-07-04 12:53:25 +02:00
parent 993ed55304
commit 2f164fee9b
70 changed files with 2044 additions and 761 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
sources_non_forked/ale/doc/ale-cloudformation.txt Normal file
View File

@ -0,0 +1,14 @@
===============================================================================
ALE CloudFormation Integration *ale-cloudformation-options*
===============================================================================
cfn-python-lint *ale-cloudformation-cfn-python-lint*
cfn-python-lint is a linter for AWS CloudFormation template file.
https://github.com/awslabs/cfn-python-lint
===============================================================================
vim:tw=78:ts=2:sts=2:sw=2:ft=help:norl:

33
sources_non_forked/ale/doc/ale-dart.txt
View File

@ -35,4 +35,37 @@ g:ale_dart_dartanalyzer_executable *g:ale_dart_dartanalyzer_executable*
===============================================================================
dartfmt *ale-dart-dartfmt*
Installation
-------------------------------------------------------------------------------
Installing Dart should probably ensure that `dartfmt` is in your `$PATH`.
In case it is not, try to set the executable option to its absolute path. : >
" Set the executable path for dartfmt to the absolute path to it.
let g:ale_dart_dartfmt_executable = '/usr/lib/dart/bin/dartfmt'
>
Options
-------------------------------------------------------------------------------
g:ale_dart_dartfmt_executable *g:ale_dart_dartfmt_executable*
*b:ale_dart_dartfmt_executable*
Type: |String|
Default: `''`
This variable can be set to specify an absolute path to the
dartfmt executable (or to specify an alternate executable).
g:ale_dart_dartfmt_options *g:ale_dart_dartfmt_options*
*b:ale_dart_dartfmt_options*
Type: |String|
Default: `''`
This variable can be set to pass additional options to the dartfmt fixer.
===============================================================================
vim:tw=78:ts=2:sts=2:sw=2:ft=help:norl:

223
sources_non_forked/ale/doc/ale-development.txt Normal file
View File

@ -0,0 +1,223 @@
*ale-development.txt* For Vim version 8.0.
*ale-development*
ALE Development Documentation
===============================================================================
CONTENTS *ale-development-contents*
1. Introduction.........................|ale-development-introduction|
2. Design Goals.........................|ale-design-goals|
3. Coding Standards.....................|ale-coding-standards|
4. Testing ALE..........................|ale-development-tests|
===============================================================================
1. Introduction *ale-development-introduction*
This document contains helpful information for ALE developers, including
design goals, information on how to run the tests, coding standards, and so
on. You should read this document if you want to get involved with ALE
development.
===============================================================================
2. Design Goals *ale-design-goals*
This section lists design goals for ALE, in no particular order. They are as
follows.
ALE code should be almost 100% VimL. This makes the plugin as portable as
possible.
ALE should run without needing any other plugins to be installed, to make
installation simple. ALE can integrate with other plugins for more advanced
functionality, non-essential functionality, or improving on basic first party
functionality.
ALE should check files with as many tools as possible by default, except where
they cause security issues or make excessive use of resources on modern
machines.
ALE should be free of breaking changes to the public API, which is comprised of
documented functions and options, until a major version is planned. Breaking
changes should be preceded by a deprecation phase complete with warnings.
Changes required for security may be an exception.
ALE supports Vim 8 and above, and NeoVim 0.2.0 or newer. These are the
earliest versions of Vim and NeoVim which support |job|, |timer|, |closure|,
and |lambda| features. All ALE code should be written so it is compatible with
these versions of Vim, or with version checks so particular features can
degrade or fail gracefully.
Just about everything should be documented and covered with tests.
By and large, people shouldn't pay for the functionality they don't use. Care
should be taken when adding new features, so supporting new features doesn't
degrade the general performance of anything ALE does.
LSP support will become more important as time goes on. ALE should provide
better support for LSP features as time goes on.
When merging pull requests, you should respond with `Cheers! :beers:`, purely
for comedy value.
===============================================================================
3. Coding Standards *ale-coding-standards*
The following general coding standards should be adhered to for Vim code.
* Check your Vim code with `Vint` and do everything it says. ALE will check
your Vim code with Vint automatically. See: https://github.com/Kuniwak/vint
Read ALE's `Dockerfile` to see which version of `Vint` it uses.
* Try to write descriptive and concise names for variables and functions.
Names shouldn't be too short or too long. Think about others reading your
code later on.
* Use `snake_case` names for variables and arguments, and `PascalCase` names
for functions. Prefix every variable name with its scope. (`l:`, `g:`, etc.)
* Try to keep lines no longer than 80 characters, but this isn't an absolute
requirement.
* Use 4 spaces for every level of indentation in Vim code.
* Add a blank line before every `function`, `if`, `for`, `while`, or `return`,
which doesn't start a new level of indentation. This makes the logic in
your code easier to follow.
* End every file with a trailing newline character, but not with extra blank
lines. Remove trailing whitespace from the ends of lines.
* Write the full names of commands instead of abbreviations. For example, write
`function` instead of `func`, and `endif` instead of `end`.
* Write functions with `!`, so files can be reloaded. Use the |abort| keyword
for all functions, so functions exit on the first error.
* Make sure to credit yourself in files you have authored with `Author:`
and `Description:` comments.
In addition to the above general guidelines for the style of your code, you
should also follow some additional rules designed to prevent mistakes. Some of
these are reported with ALE's `custom-linting-rules` script. See
|ale-development-tests|.
* Don't leave stray `:echo` lines in code. Use `execute 'echo' ...` if you must
echo something.
* For strings use |is#| instead of |==#|, `is?` instead of `==?`, `isnot#`
instead of `!=#`, and `isnot?` instead of `!=?`. This is because `'x' ==# 0`
returns 1, while `'x' is# 0` returns 0, so you will experience fewer issues
when numbers are compared with strings. `is` and `isnot` also do not throw
errors when other objects like List or Dictionaries are compared with
strings.
* Don't use the `getcwd()` function in the ALE codebase. Most of ALE's code
runs from asynchronous callback functions, and these functions can execute
from essentially random buffers. Therefore, the `getcwd()` output is
useless. Use `expand('#' . a:buffer . ':p:h')` instead. Don't use
`expand('%...')` for the same reason.
* Don't use the `simplify()` function. It doesn't simplify paths enough. Use
`ale#path#Simplify()` instead.
* Don't use the `shellescape()` function. It doesn't escape arguments properly
on Windows. Use `ale#Escape()` instead, which will avoid escaping where it
isn't needed, and generally escape arguments better on Windows.
Apply the following guidelines when writing Vader test files.
* Use 2 spaces for Vader test files, instead of the 4 spaces for Vim files.
* If you write `Before` and `After` blocks, you should typically write them at
the top of the file, so they run for all tests. There may be some tests
where it make sense to modify the `Before` and `After` code part of the way
through the file.
* If you modify any settings or global variables, reset them in `After`
blocks. The Vader `Save` and `Restore` commands can be useful for this
purpose.
* If you load or define linters in tests, write `call ale#linter#Reset()` in
an `After` block.
* Just write `Execute` blocks for Vader tests, and don't bother writing `Then`
blocks. `Then` blocks execute after `After` blocks in older versions, and
that can be confusing.
Apply the following rules when writing Bash scripts.
* Run `shellcheck`, and do everything it says.
See: https://github.com/koalaman/shellcheck
* Try to write scripts so they will run on Linux, BSD, or Mac OSX.
===============================================================================
4. Testing ALE *ale-development-tests*
ALE is tested with a suite of tests executed in Travis CI and AppVeyor. ALE
runs tests with the following versions of Vim in the following environments.
1. Vim 8.0.0027 on Linux via Travis CI.
2. NeoVim 0.2.0 on Linux via Travis CI.
3. NeoVim 0.3.0 on Linux via Travis CI.
4. Vim 8 (stable builds) on Windows via AppVeyor.
If you are developing ALE code on Linux, Mac OSX, or BSD, you can run ALEs
tests by installing Docker and running the `run-tests` script. Follow the
instructions on the Docker site for installing Docker.
See: https://docs.docker.com/install/
NOTE: Don't forget to add your user to the `docker` group on Linux, or Docker
just won't work. See: https://docs.docker.com/install/linux/linux-postinstall/
If you run simply `./run-tests` from the ALE repository root directory, the
latest Docker image for tests will be downloaded if needed, and the script
will run all of the tests in Vader, Vint checks, and several Bash scripts for
finding extra issues. Run `./run-tests --help` to see all of the options the
script supports. Note that the script supports selecting particular test files.
Generally write tests for any changes you make. The following types of tests
are recommended for the following types of code.
* New/edited error handler callbacks -> Write tests in `test/handler`
* New/edited command callbacks -> Write tests in `test/command_callback`
* New/edited fixer functions -> Write tests in `test/fixers`
Look at existing tests in the codebase for examples of how to write tests.
Refer to the Vader documentation for general information on how to write Vader
tests: https://github.com/junegunn/vader.vim
When you add new linters or fixers, make sure to add them into the table in
the README, and also into the |ale-support| list in the main help file. If you
forget to keep them both in sync, you should see an error like the following
in Travis CI. >
========================================
diff README.md and doc/ale.txt tables
========================================
Differences follow:
--- /tmp/readme.qLjNhJdB 2018-07-01 16:29:55.590331972 +0100
+++ /tmp/doc.dAi8zfVE 2018-07-01 16:29:55.582331877 +0100
@@ -1 +1 @@
- ASM: gcc, foobar
+ ASM: gcc
<
Make sure to list documentation entries for linters and fixers in individual
help files in the table of contents, and to align help tags to the right
margin. For example, if you add a heading for an `aardvark` tool to
`ale-python.txt` with a badly aligned doc tag, you will see errors like so. >
========================================
Look for badly aligned doc tags
========================================
Badly aligned tags follow:
doc/ale-python.txt:aardvark ...
========================================
Look for table of contents issues
========================================
Check for bad ToC sorting:
Check for mismatched ToC and headings:
--- /tmp/table-of-contents.mwCFOgSI 2018-07-01 16:33:25.068811878 +0100
+++ /tmp/headings.L4WU0hsO 2018-07-01 16:33:25.076811973 +0100
@@ -168,6 +168,7 @@
pyrex (cython), ale-pyrex-options
cython, ale-pyrex-cython
python, ale-python-options
+ aardvark, ale-python-aardvark
autopep8, ale-python-autopep8
black, ale-python-black
flake8, ale-python-flake8
<
Make sure to make the table of contents match the headings, and to keep the
doc tags on the right margin.
===============================================================================
vim:tw=78:ts=2:sts=2:sw=2:ft=help:norl:

8
sources_non_forked/ale/doc/ale-html.txt
View File

@ -71,6 +71,14 @@ g:ale_html_tidy_options *g:ale_html_tidy_options*
(mac), sjis (shiftjis), utf-16le, utf-16, utf-8
g:ale_html_tidy_use_global *g:html_tidy_use_global*
Type: |Number|
Default: `get(g:, 'ale_use_global_executables', 0)`
See |ale-integrations-local-executables|
===============================================================================
write-good *ale-html-write-good*

25
sources_non_forked/ale/doc/ale-pyrex.txt Normal file
View File

@ -0,0 +1,25 @@
===============================================================================
ALE Pyrex (Cython) Integration *ale-pyrex-options*
===============================================================================
cython *ale-pyrex-cython*
g:ale_pyrex_cython_executable *g:ale_pyrex_cython_executable*
*b:ale_pyrex_cython_executable*
Type: |String|
Default: `'cython'`
This variable can be changed to use a different executable for cython.
g:ale_pyrex_cython_options *g:ale_pyrex_cython_options*
*b:ale_pyrex_cython_options*
Type: |String|
Default: `'--warning-extra --warning-errors'`
This variable can be changed to modify flags given to cython.
===============================================================================
vim:tw=78:ts=2:sts=2:sw=2:ft=help:norl:

24
sources_non_forked/ale/doc/ale-python.txt
View File

@ -363,6 +363,30 @@ g:ale_python_pyls_use_global *g:ale_python_pyls_use_global*
See |ale-integrations-local-executables|
===============================================================================
pyre *ale-python-pyre*
`pyre` will be run from a detected project root, per |ale-python-root|.
g:ale_python_pyre_executable *g:ale_python_pyre_executable*
*b:ale_python_pyre_executable*
Type: |String|
Default: `'pyre'`
See |ale-integrations-local-executables|
Set this to `'pipenv'` to invoke `'pipenv` `run` `pyre'`.
g:ale_python_pyre_use_global *g:ale_python_pyre_use_global*
*b:ale_python_pyre_use_global*
Type: |Number|
Default: `get(g:, 'ale_use_global_executables', 0)`
See |ale-integrations-local-executables|
===============================================================================
yapf *ale-python-yapf*

9
sources_non_forked/ale/doc/ale-rust.txt
View File

@ -108,6 +108,15 @@ g:ale_rust_cargo_include_features *g:ale_rust_cargo_include_features*
When defined, ALE will set the `--features` option when invoking `cargo` to
perform the lint check. See |g:ale_rust_cargo_default_feature_behavior|.
g:ale_rust_cargo_avoid_whole_workspace *g:ale_rust_cargo_avoid_whole_workspace*
*b:ale_rust_cargo_avoid_whole_workspace*
Type: |Number|
Default: `1`
When set to 1, and ALE is used to edit a crate that is part of a Cargo
workspace, avoid building the entire entire workspace by invoking
`cargo` directly in the crate's directory. Otherwise, behave as usual.
===============================================================================
rls *ale-rust-rls*

19
sources_non_forked/ale/doc/ale-sh.txt
View File

@ -2,6 +2,25 @@
ALE Shell Integration *ale-sh-options*
===============================================================================
sh-language-server *ale-sh-language-server*
g:ale_sh_language_server_executable *g:ale_sh_language_server_executable*
*b:ale_sh_language_server_executable*
Type: |String|
Default: `'bash-language-server'`
See |ale-integrations-local-executables|
g:ale_sh_language_server_use_global *g:ale_sh_language_server_use_global*
*b:ale_sh_language_server_use_global*
Type: |Number|
Default: `get(g:, 'ale_use_global_executables', 0)`
See |ale-integrations-local-executables|
===============================================================================
shell *ale-sh-shell*

88
sources_non_forked/ale/doc/ale.txt
View File

@ -35,6 +35,8 @@ CONTENTS *ale-contents*
foodcritic..........................|ale-chef-foodcritic|
clojure...............................|ale-clojure-options|
joker...............................|ale-clojure-joker|
cloudformation........................|ale-cloudformation-options|
cfn-python-lint.....................|ale-cloudformation-cfn-python-lint|
cmake.................................|ale-cmake-options|
cmakelint...........................|ale-cmake-cmakelint|
cpp...................................|ale-cpp-options|
@ -57,6 +59,7 @@ CONTENTS *ale-contents*
nvcc................................|ale-cuda-nvcc|
dart..................................|ale-dart-options|
dartanalyzer........................|ale-dart-dartanalyzer|
dartfmt.............................|ale-dart-dartfmt|
dockerfile............................|ale-dockerfile-options|
hadolint............................|ale-dockerfile-hadolint|
elixir................................|ale-elixir-options|
@ -183,6 +186,8 @@ CONTENTS *ale-contents*
puglint.............................|ale-pug-puglint|
puppet................................|ale-puppet-options|
puppetlint..........................|ale-puppet-puppetlint|
pyrex (cython)........................|ale-pyrex-options|
cython..............................|ale-pyrex-cython|
python................................|ale-python-options|
autopep8............................|ale-python-autopep8|
black...............................|ale-python-black|
@ -194,6 +199,7 @@ CONTENTS *ale-contents*
pyflakes............................|ale-python-pyflakes|
pylint..............................|ale-python-pylint|
pyls................................|ale-python-pyls|
pyre................................|ale-python-pyre|
yapf................................|ale-python-yapf|
qml...................................|ale-qml-options|
qmlfmt..............................|ale-qml-qmlfmt|
@ -226,6 +232,7 @@ CONTENTS *ale-contents*
prettier............................|ale-scss-prettier|
stylelint...........................|ale-scss-stylelint|
sh....................................|ale-sh-options|
sh-language-server..................|ale-sh-language-server|
shell...............................|ale-sh-shell|
shellcheck..........................|ale-sh-shellcheck|
shfmt...............................|ale-sh-shfmt|
@ -302,6 +309,9 @@ control functionality used for checking for problems. Try using the
|ALEFixSuggest| command for browsing tools that can be used to fix problems
for the current buffer.
If you are interested in contributing to the development of ALE, read the
developer documentation. See |ale-development|
===============================================================================
2. Supported Languages & Tools *ale-support*
@ -317,7 +327,7 @@ Notes:
* API Blueprint: `drafter`
* AsciiDoc: `alex`!!, `proselint`, `redpen`, `write-good`
* Awk: `gawk`
* Bash: `shell` (-n flag), `shellcheck`, `shfmt`
* Bash: `language-server`, `shell` (-n flag), `shellcheck`, `shfmt`
* Bourne Shell: `shell` (-n flag), `shellcheck`, `shfmt`
* C: `cppcheck`, `cpplint`!!, `clang`, `clangtidy`!!, `clang-format`, `flawfinder`, `gcc`
* C++ (filetype cpp): `clang`, `clangcheck`!!, `clangtidy`!!, `clang-format`, `cppcheck`, `cpplint`!!, `cquery`, `flawfinder`, `gcc`
@ -325,6 +335,7 @@ Notes:
* C#: `mcs`, `mcsc`!!
* Chef: `foodcritic`
* Clojure: `joker`
* CloudFormation: `cfn-python-lint`
* CMake: `cmakelint`
* CoffeeScript: `coffee`, `coffeelint`
* Crystal: `crystal`!!
@ -333,9 +344,9 @@ Notes:
* Cython (pyrex filetype): `cython`
* D: `dmd`
* Dafny: `dafny`!!
* Dart: `dartanalyzer`!!, `language_server`
* Dart: `dartanalyzer`!!, `language_server`, dartfmt!!
* Dockerfile: `hadolint`
* Elixir: `credo`, `dialyxir`, `dogma`!!
* Elixir: `credo`, `dialyxir`, `dogma`, `mix`!!
* Elm: `elm-format, elm-make`
* Erb: `erb`, `erubi`, `erubis`
* Erlang: `erlc`, `SyntaxErl`
@ -380,7 +391,7 @@ Notes:
* proto: `protoc-gen-lint`
* Pug: `pug-lint`
* Puppet: `puppet`, `puppet-lint`
* Python: `autopep8`, `black`, `flake8`, `isort`, `mypy`, `prospector`, `pycodestyle`, `pyls`, `pylint`!!, `yapf`
* Python: `autopep8`, `black`, `flake8`, `isort`, `mypy`, `prospector`, `pycodestyle`, `pyls`, `pyre`, `pylint`!!, `yapf`
* QML: `qmlfmt`, `qmllint`
* R: `lintr`
* ReasonML: `merlin`, `ols`, `refmt`
@ -935,6 +946,14 @@ g:ale_fixers *g:ale_fixers*
`b:ale_fixers` can be set to a |List| of callbacks instead, which can be
more convenient.
A special `'*'` key be used as a wildcard filetype for configuring fixers
for every other type of file. For example: >
" Fix Python files with 'bar'.
" Don't fix 'html' files.
" Fix everything else with 'foo'.
let g:ale_fixers = {'python': ['bar'], 'html': [], '*': ['foo']}
<
g:ale_fix_on_save *g:ale_fix_on_save*
b:ale_fix_on_save *b:ale_fix_on_save*
@ -1114,6 +1133,7 @@ g:ale_linter_aliases *g:ale_linter_aliases*
\ 'csh': 'sh',
\ 'plaintex': 'tex',
\ 'systemverilog': 'verilog',
\ 'verilog_systemverilog': ['verilog_systemverilog', 'verilog'],
\ 'vimwiki': 'markdown',
\ 'zsh': 'sh',
\}
@ -1219,6 +1239,32 @@ g:ale_linters_explicit *g:ale_linters_explicit*
as possible, unless otherwise specified.
g:ale_linters_ignore *g:ale_linters_ignore*
*b:ale_linters_ignore*
Type: |Dictionary| or |List|
Default: `{}`
Linters to ignore. Commands for ignored linters will not be run, and
diagnostics for LSP linters will be ignored. (See |ale-lsp|)
This setting can be set to a |Dictionary| mapping filetypes to linter names,
just like |g:ale_linters|, to list linters to ignore. Ignore lists will be
applied after everything else. >
" Select flake8 and pylint, and ignore pylint, so only flake8 is run.
let g:ale_linters = {'python': ['flake8', 'pylint']}
let g:ale_linters_ignore = {'python': ['pylint']}
<
This setting can be set to simply a |List| of linter names, which is
especially more convenient when using the setting in ftplugin files for
particular buffers. >
" The same as above, in a ftplugin/python.vim.
let b:ale_linters = ['flake8', 'pylint']
let b:ale_linters_ignore = ['pylint']
<
g:ale_list_vertical *g:ale_list_vertical*
*b:ale_list_vertical*
Type: |Number|
@ -1967,9 +2013,13 @@ ALEDisableBuffer *ALEDisableBuffer*
*:ALEDetail*
ALEDetail *ALEDetail*
Show the full linter message for the current line in the preview window.
This will only have an effect on lines that contain a linter message. The
preview window can be easily closed with the `q` key.
Show the full linter message for the problem nearest to the cursor on the
given line in the preview window. The preview window can be easily closed
with the `q` key. If there is no message to show, the window will not be
opened.
If a loclist item has a `detail` key set, the message for that key will be
preferred over `text`. See |ale-loclist-format|.
A plug mapping `<Plug>(ale_detail)` is defined for this command.
@ -2153,13 +2203,16 @@ ale#linter#Define(filetype, linter) *ale#linter#Define()*
This argument is required, unless the linter is an
LSP linter. In which case, this argument must not be
defined, as LSP linters handle diangostics
defined, as LSP linters handle diagnostics
automatically. See |ale-lsp-linters|.
The keys for each item in the List will be handled in
the following manner:
*ale-loclist-format*
`text` - This error message is required.
`detail` - An optional, more descriptive message.
This message can be displayed with the |ALEDetail|
command instead of the message for `text`, if set.
`lnum` - The line number is required. Any strings
will be automatically converted to numbers by
using `str2nr()`.
@ -2319,8 +2372,16 @@ ale#linter#Define(filetype, linter) *ale#linter#Define()*
When this argument is set to `'stdio'`, then the
linter will be defined as an LSP linter which keeps a
process for a language server runnning, and
process for a language server running, and
communicates with it directly via a |channel|.
`executable` or `executable_callback` must be set,
and `command` or `command_callback` must be set.
When this argument is set to `'socket'`, then the
linter will be defined as an LSP linter via a TCP
socket connection. `address_callback` must be set
with a callback returning an address to connect to.
ALE will not start a server automatically.
When this argument is not empty, only one of either
`language` or `language_callback` must be defined,
@ -2336,6 +2397,13 @@ ale#linter#Define(filetype, linter) *ale#linter#Define()*
`initialization_options_callback` may be defined to
pass initialization options to the LSP.
`address_callback` A |String| or |Funcref| for a callback function
accepting a buffer number. A |String| should be
returned with an address to connect to.
This argument must only be set if the `lsp` argument
is set to `'socket'`.
`project_root_callback` A |String| or |Funcref| for a callback function
accepting a buffer number. A |String| should be
returned representing the path to the project for the
@ -2564,5 +2632,5 @@ free to send an email to devw0rp@gmail.com.
Please drink responsibly, or not at all, which is ironically the preference
of w0rp, who is teetotal.
===============================================================================
vim:tw=78:ts=2:sts=2:sw=2:ft=help:norl: