ALE (Asynchronous Lint Engine) is a plugin providing linting (syntax checking and semantic errors) in NeoVim 0.6.0+ and Vim 8.0+ while you edit your text files, and acts as a Vim Language Server Protocol client.

ALE makes use of NeoVim and Vim 8 job control functions and timers to run linters on the contents of text buffers and return errors as text is changed in Vim. This allows for displaying warnings and errors in files being edited in Vim before files have been saved back to a filesystem.

In other words, this plugin allows you to lint while you type.

ALE offers support for fixing code with command line tools in a non-blocking manner with the :ALEFix feature, supporting tools in many languages, like prettier, eslint, autopep8, and more.

ALE acts as a "language client" to support a variety of Language Server Protocol features, including:

• Diagnostics (via Language Server Protocol linters)
• Go To Definition (:ALEGoToDefinition)
• Completion (Built in completion support, or with Deoplete)
• Finding references (:ALEFindReferences)
• Hover information (:ALEHover)
• Symbol search (:ALESymbolSearch)

If you don't care about Language Server Protocol, ALE won't load any of the code for working with it unless needed. One of ALE's general missions is that you won't pay for the features that you don't use.

Help Wanted: If you would like to help maintain this plugin by managing the many issues and pull requests that are submitted, please send the author an email at [email protected].

If you enjoy this plugin, feel free to contribute or check out the author's other content at w0rp.com.

ALE has been around for many years, and there are many ways to run asynchronous linting and fixing of code in Vim. ALE offers the following.

• No dependencies for ALE itself
• Lightweight plugin architecture (No JavaScript or Python required)
• Low memory footprint
• Runs virtually everywhere, including remote shells, and in git commit
• Out of the box support for running particular linters and language servers
• Near-zero configuration with custom code for better defaults
• Highly customizable and well-documented (:help ale-options)
• Breaking changes for the plugin are extremely rare
• Support for older Vim and Neovim versions
• Windows support
• Well-integrated with other plugins

ALE supports a wide variety of languages and tools. See the full list in the Supported Languages and Tools page.

Once this plugin is installed, while editing your files in supported languages and tools which have been correctly installed, this plugin will send the contents of your text buffers to a variety of programs for checking the syntax and semantics of your programs. By default, linters will be re-run in the background to check your syntax when you open new buffers or as you make edits to your files.

The behavior of linting can be configured with a variety of options, documented in the Vim help file. For more information on the options ALE offers, consult :help ale-options for global options and :help ale-integration-options for options specified to particular linters.

ALE can fix files with the ALEFix command. Functions need to be configured either in each buffer with a b:ale_fixers, or globally with g:ale_fixers.

The recommended way to configure fixers is to define a List in an ftplugin file.

" In ~/.vim/ftplugin/javascript.vim, or somewhere similar.

" Fix files with prettier, and then ESLint.
let b:ale_fixers = ['prettier', 'eslint']
" Equivalent to the above.
let b:ale_fixers = {'javascript': ['prettier', 'eslint']}

You can also configure your fixers from vimrc using g:ale_fixers, before or after ALE has been loaded.

A * in place of the filetype will apply a List of fixers to all files which do not match some filetype in the Dictionary.

Note that using a plain List for g:ale_fixers is not supported.

" In ~/.vim/vimrc, or somewhere similar.
let g:ale_fixers = {
\   '*': ['remove_trailing_lines', 'trim_whitespace'],
\   'javascript': ['eslint'],
\}

If you want to automatically fix files when you save them, you need to turn a setting on in vimrc.

" Set this variable to 1 to fix files when you save them.
let g:ale_fix_on_save = 1

The :ALEFixSuggest command will suggest some supported tools for fixing code. Both g:ale_fixers and b:ale_fixers can also accept functions, including lambda functions, as fixers, for fixing files with custom tools.

See :help ale-fix for complete information on how to fix files with ALE.

ALE offers some support for completion via hijacking of omnicompletion while you type. All of ALE's completion information must come from Language Server Protocol linters, or from tsserver for TypeScript.

ALE integrates with Deoplete as a completion source, named 'ale'. You can configure Deoplete to only use ALE as the source of completion information, or mix it with other sources.

" Use ALE and also some plugin 'foobar' as completion sources for all code.
call deoplete#custom#option('sources', {
\ '_': ['ale', 'foobar'],
\})

ALE also offers its own automatic completion support, which does not require any other plugins, and can be enabled by changing a setting before ALE is loaded.

" Enable completion where available.
" This setting must be set before ALE is loaded.
"
" You should not turn this setting on if you wish to use ALE as a completion
" source for other completion plugins, like Deoplete.
let g:ale_completion_enabled = 1

ALE provides an omni-completion function you can use for triggering completion manually with <C-x><C-o>.

set omnifunc=ale#completion#OmniFunc

ALE supports automatic imports from external modules. This behavior is enabled by default and can be disabled by setting:

let g:ale_completion_autoimport = 0

Note that disabling auto import can result in missing completion items from some LSP servers (e.g. eclipselsp). See :help ale-completion for more information.

ALE supports jumping to the definition of words under your cursor with the :ALEGoToDefinition command using any enabled Language Server Protocol linters and tsserver.

See :help ale-go-to-definition for more information.

ALE supports finding references for words under your cursor with the :ALEFindReferences command using any enabled Language Server Protocol linters and tsserver.

See :help ale-find-references for more information.

ALE supports "hover" information for printing brief information about symbols at the cursor taken from Language Server Protocol linters and tsserver with the ALEHover command.

Truncated information will be displayed when the cursor rests on a symbol by default, as long as there are no problems on the same line.

The information can be displayed in a balloon tooltip in Vim or GVim by hovering your mouse over symbols. Mouse hovering is enabled by default in GVim, and needs to be configured for Vim 8.1+ in terminals.

See :help ale-hover for more information.

ALE supports searching for workspace symbols via Language Server Protocol linters with the ALESymbolSearch command.

Search queries can be performed to find functions, types, and more which are similar to a given query string.

See :help ale-symbol-search for more information.

ALE supports renaming symbols in code such as variables or class names with the ALERename command.

ALEFileRename will rename file and fix import paths (tsserver only).

ALECodeAction will execute actions on the cursor or applied to a visual range selection, such as automatically fixing errors.

See :help ale-refactor for more information.

Add ALE to your runtime path in the usual ways.

If you have trouble reading :help ale, try the following.

packloadall | silent! helptags ALL

mkdir -p ~/.vim/pack/git-plugins/start
git clone --depth 1 https://github.com/dense-analysis/ale.git ~/.vim/pack/git-plugins/start/ale

mkdir -p ~/.local/share/nvim/site/pack/git-plugins/start
git clone --depth 1 https://github.com/dense-analysis/ale.git ~/.local/share/nvim/site/pack/git-plugins/start/ale

# Run these commands in the "Git for Windows" Bash terminal
mkdir -p ~/vimfiles/pack/git-plugins/start
git clone --depth 1 https://github.com/dense-analysis/ale.git ~/vimfiles/pack/git-plugins/start/ale

Plug 'dense-analysis/ale'

Plugin 'dense-analysis/ale'

git clone https://github.com/dense-analysis/ale ~/.vim/bundle/ale

{
    'dense-analysis/ale',
    config = function()
        -- Configuration goes here.
        local g = vim.g

        g.ale_ruby_rubocop_auto_correct_all = 1

        g.ale_linters = {
            ruby = {'rubocop', 'ruby'},
            lua = {'lua_language_server'}
        }
    end
}

If you would like to see support for more languages and tools, please create an issue or create a pull request. If your tool can read from stdin or you have code to suggest which is good, support can be happily added for it.

If you are interested in the general direction of the project, check out the wiki home page. The wiki includes a Roadmap for the future, and more.

If you'd liked to discuss ALE and more check out the Dense Analysis Discord server here: https://discord.gg/5zFD6pQxDk

By default, all available tools for all supported languages will be run. If you want to only select a subset of the tools, you can define b:ale_linters for a single buffer, or g:ale_linters globally.

The recommended way to configure linters is to define a List in an ftplugin file.

" In ~/.vim/ftplugin/javascript.vim, or somewhere similar.

" Enable ESLint only for JavaScript.
let b:ale_linters = ['eslint']

" Equivalent to the above.
let b:ale_linters = {'javascript': ['eslint']}

You can also declare which linters you want to run in your vimrc file, before or after ALE has been loaded.

" In ~/.vim/vimrc, or somewhere similar.
let g:ale_linters = {
\   'javascript': ['eslint'],
\}

For all languages unspecified in the dictionary, all possible linters will be run for those languages, just as when the dictionary is not defined. Running many linters should not typically obstruct editing in Vim, as they will all be executed in separate processes simultaneously.

If you don't want ALE to run anything other than what you've explicitly asked for, you can set g:ale_linters_explicit to 1.

" Only run linters named in ale_linters settings.
let g:ale_linters_explicit = 1

This plugin will look for linters in the ale_linters directory. Each directory within corresponds to a particular filetype in Vim, and each file in each directory corresponds to the name of a particular linter.

Warnings and errors should be configured in project configuration files for the relevant tools. ALE supports disabling only warnings relating to trailing whitespace, which Vim users often fix automatically.

" Disable whitespace warnings
let g:ale_warn_about_trailing_whitespace = 0

Users generally should not ignore warnings or errors in projects by changing settings in their own editor. Instead, configure tools appropriately so any other user of the same project will see the same problems.

Run the following to see what is currently configured:

:ALEInfo

By default, ALE displays errors and warnings with virtual text. The problems ALE shows appear with comment-like syntax after every problem found. You can set ALE to only show problems where the cursor currently lies like so.

let g:ale_virtualtext_cursor = 'current'

If you want to disable virtual text completely, apply the following.

let g:ale_virtualtext_cursor = 'disabled'

Use these options to specify what text should be used for signs:

let g:ale_sign_error = '>>'
let g:ale_sign_warning = '--'

ALE sets some background colors automatically for warnings and errors in the sign gutter, with the names ALEErrorSign and ALEWarningSign. These colors can be customised, or even removed completely:

highlight clear ALEErrorSign
highlight clear ALEWarningSign

You can configure the sign gutter open at all times, if you wish.

let g:ale_sign_column_always = 1

ALE's highlights problems with highlight groups which link to SpellBad, SpellCap, error, and todo groups by default. The characters that are highlighted depend on the linters being used, and the information provided to ALE.

Highlighting can be disabled completely by setting g:ale_set_highlights to 0.

" Set this in your vimrc file to disabling highlighting
let g:ale_set_highlights = 0

You can control all of the highlights ALE uses, say if you are using a different color scheme which produces ugly highlights. For example:

highlight ALEWarning ctermbg=DarkMagenta

See :help ale-highlights for more information.

There are 3 global options that allow customizing the echoed message.

• g:ale_echo_msg_format where:
  • %s is the error message itself
  • %...code...% is an optional error code, and most characters can be written between the % characters.
  • %linter% is the linter name
  • %severity% is the severity type
• g:ale_echo_msg_error_str is the string used for error severity.
• g:ale_echo_msg_warning_str is the string used for warning severity.

So for example this:

let g:ale_echo_msg_error_str = 'E'
let g:ale_echo_msg_warning_str = 'W'
let g:ale_echo_msg_format = '[%linter%] %s [%severity%]'

Will give you:

See :help g:ale_echo_msg_format for more information.

lightline does not have built-in support for ALE, nevertheless there is a plugin that adds this functionality: maximbaz/lightline-ale.

For more information, check out the sources of that plugin, :help ale#statusline#Count() and lightline documentation.

vim-airline integrates with ALE for displaying error information in the status bar. If you want to see the status for ALE in a nice format, it is recommended to use vim-airline with ALE. The airline extension can be enabled by adding the following to your vimrc:

" Set this. Airline will handle the rest.
let g:airline#extensions#ale#enabled = 1

You can implement your own statusline function without adding any other plugins. ALE provides some functions to assist in this endeavour, including:

• ale#statusline#Count: Which returns the number of problems found by ALE for a specified buffer.
• ale#statusline#FirstProblem: Which returns a dictionary containing the full loclist details of the first problem of a specified type found by ALE in a buffer. (e.g. The first style warning in the current buffer.) This can be useful for displaying more detailed information such as the line number of the first problem in a file.

Say you want to display all errors as one figure, and all non-errors as another figure. You can do the following:

function! LinterStatus() abort
    let l:counts = ale#statusline#Count(bufnr(''))

    let l:all_errors = l:counts.error + l:counts.style_error
    let l:all_non_errors = l:counts.total - l:all_errors

    return l:counts.total == 0 ? 'OK' : printf(
    \   '%dW %dE',
    \   all_non_errors,
    \   all_errors
    \)
endfunction

set statusline=%{LinterStatus()}

See :help ale#statusline#Count() or :help ale#statusline#FirstProblem() for more information.

Borders for floating preview windows are enabled by default. You can use the g:ale_floating_window_border setting to configure them.

You could disable the border with an empty list.

let g:ale_floating_window_border = []

If the terminal supports Unicode, you might try setting the value like below, to make it look nicer.

let g:ale_floating_window_border = ['│', '─', '╭', '╮', '╯', '╰', '│', '─']

Since vim's default uses nice Unicode characters when possible, you can trick ale into using that default with

let g:ale_floating_window_border = repeat([''], 8)

ALE takes advantage of the power of various tools to check your code. This of course means that CPU time will be used to continuously check your code. If you are concerned about the CPU time ALE will spend, which will of course imply some cost to battery life, you can adjust your settings to make your CPU do less work.

First, consider increasing the delay before which ALE will run any linters while you type. ALE uses a timeout which is cancelled and reset every time you type, and this delay can be increased so linters are run less often. See :help g:ale_lint_delay for more information.

If you don't wish to run linters while you type, you can disable that behavior. Set g:ale_lint_on_text_changed to never. You won't get as frequent error checking, but ALE shouldn't block your ability to edit a document after you save a file, so the asynchronous nature of the plugin will still be an advantage.

If you are still concerned, you can turn the automatic linting off altogether, including the option g:ale_lint_on_enter, and you can run ALE manually with :ALELint.

ALE offers an API for letting any other plugin integrate with ALE. If you are interested in writing an integration, see :help ale-lint-other-sources.

If you're running ALE in Neovim with nvim-lspconfig for configuring particular language servers. ALE will automatically disable its LSP functionality for any language servers configured with nvim-lspconfig by default. The following setting is applied by default:

let g:ale_disable_lsp = 'auto'

If you are running ALE in combination with another LSP client, you may wish to disable ALE's LSP functionality entirely. You can change the setting to 1 to always disable all LSP functionality.

let g:ale_disable_lsp = 1

You can also use b:ale_disable_lsp in your ftplugin files to enable or disable LSP features in ALE for different filetypes.

If you are running Neovim 0.6 or later, you can make ALE display errors and warnings via the Neovim diagnostics API.

let g:ale_use_neovim_diagnostics_api = 1

coc.nvim is a popular Vim plugin written in TypeScript and dependent on the npm ecosystem for providing full IDE features to Vim. Both ALE and coc.nvim implement Language Server Protocol (LSP) clients for supporting diagnostics (linting with a live server), and other features like auto-completion, and others listed above.

ALE is primarily focused on integrating with external programs through virtually any means, provided the plugin remains almost entirely written in Vim script. coc.nvim is primarily focused on bringing IDE features to Vim. If you want to run external programs on your files to check for errors, and also use the most advanced IDE features, you might want to use both plugins at the same time.

The easiest way to get both plugins to work together is to configure coc.nvim to send diagnostics to ALE, so ALE controls how all problems are presented to you, and to disable all LSP features in ALE, so ALE doesn't try to provide LSP features already provided by coc.nvim, such as auto-completion.

Open your coc.nvim configuration file with :CocConfig and add "diagnostic.displayByAle": true to your settings.

vim-lsp is a popular plugin as implementation of Language Server Protocol (LSP) client for Vim. It provides all the LSP features including auto completion, diagnostics, go to definitions, etc.

vim-lsp-ale is a bridge plugin to solve the problem when using both ALE and vim-lsp. With the plugin, diagnostics are provided by vim-lsp and ALE can handle all the errors. Please read vim-lsp-ale's documentation for more details.

ALE runs its own autocmd events when a lint or fix cycle are started and stopped. There is also an event that runs when a linter job has been successfully started. These events can be used to call arbitrary functions during these respective parts of the ALE's operation.

augroup YourGroup
    autocmd!
    autocmd User ALELintPre    call YourFunction()
    autocmd User ALELintPost   call YourFunction()

    autocmd User ALEJobStarted call YourFunction()

    autocmd User ALEFixPre     call YourFunction()
    autocmd User ALEFixPost    call YourFunction()
augroup END

ALE offers some commands with <Plug> keybinds for moving between warnings and errors quickly. You can map the keys Ctrl+j and Ctrl+k to moving between errors for example:

nmap <silent> <C-k> <Plug>(ale_previous_wrap)
nmap <silent> <C-j> <Plug>(ale_next_wrap)

For more information, consult the online documentation with :help ale-navigation-commands.

ALE offers an option g:ale_lint_on_save for enabling running the linters when files are saved. This option is enabled by default. If you only wish to run linters when files are saved, you can turn the other options off.

" Write this in your vimrc file
let g:ale_lint_on_text_changed = 'never'
let g:ale_lint_on_insert_leave = 0
" You can disable this option too
" if you don't want linters to run on opening a file
let g:ale_lint_on_enter = 0

If for whatever reason you don't wish to run linters again when you save files, you can set g:ale_lint_on_save to 0.

The quickfix list can be enabled by turning the g:ale_set_quickfix option on. If you wish to also disable the loclist, you can disable the g:ale_set_loclist option.

" Write this in your vimrc file
let g:ale_set_loclist = 0
let g:ale_set_quickfix = 1

If you wish to show Vim windows for the loclist or quickfix items when a file contains warnings or errors, g:ale_open_list can be set to 1. g:ale_keep_list_window_open can be set to 1 if you wish to keep the window open even after errors disappear.

let g:ale_open_list = 1
" Set this if you want to.
" This can be useful if you are combining ALE with
" some other plugin which sets quickfix errors, etc.
let g:ale_keep_list_window_open = 1

You can also set let g:ale_list_vertical = 1 to open the windows vertically instead of the default horizontally.

First, install eslint and install stylelint with stylelint-processor-styled-components.

Supposing you have installed both tools correctly, configure your .jsx files so jsx is included in the filetype. You can use an autocmd for this.

augroup FiletypeGroup
    autocmd!
    au BufNewFile,BufRead *.jsx set filetype=javascript.jsx
augroup END

Supposing the filetype has been set correctly, you can set the following options in a jsx.vim ftplugin file.

" In ~/.vim/ftplugin/jsx.vim, or somewhere similar.
let b:ale_linter_aliases = ['css', 'javascript']
let b:ale_linters = ['stylelint', 'eslint']

Or if you want, you can configure the linters from your vimrc file.

" In ~/.vim/vimrc, or somewhere similar.
let g:ale_linter_aliases = {'jsx': ['css', 'javascript']}
let g:ale_linters = {'jsx': ['stylelint', 'eslint']}

ALE will alias the jsx filetype so it uses the css filetype linters, and use the original Array of selected linters for jsx from the g:ale_linters object. All available linters will be used for the filetype javascript, and no linter will be run twice for the same file.

To check Vue files with ESLint, your ESLint project configuration file must be configured to use the Vue plugin. After that, you need to configure ALE so it will run the JavaScript ESLint linter on your files. The settings you need are similar to the settings needed for checking JSX code with both stylelint and ESLint, in the previous section.

" In ~/.vim/ftplugin/vue.vim, or somewhere similar.

" Run both javascript and vue linters for vue files.
let b:ale_linter_aliases = ['javascript', 'vue']
" Select the eslint and vls linters.
let b:ale_linters = ['eslint', 'vls']

Run :ALEInfo to see which linters are available after telling ALE to run JavaScript linters on Vue files. Not all linters support checking Vue files.

If you don't want to configure your linters in ftplugin files for some reason, you can configure them from your vimrc file instead.

" In ~/.vim/vimrc, or somewhere similar.
let g:ale_linter_aliases = {'vue': ['vue', 'javascript']}
let g:ale_linters = {'vue': ['eslint', 'vls']}

The structure of C and C++ projects varies wildly from project to project, with many different build tools being used for building them, and many different formats for project configuration files. ALE can run compilers easily, but ALE cannot easily detect which compiler flags to use.

Some tools and build configurations can generate compile_commands.json files. The cppcheck, clangcheck, clangtidy and cquery linters can read these files for automatically determining the appropriate compiler flags to use.

For linting with compilers like gcc and clang, and with other tools, you will need to tell ALE which compiler flags to use yourself. You can use different options for different projects with the g:ale_pattern_options setting. Consult the documentation for that setting for more information. b:ale_linters can be used to select which tools you want to run, say if you want to use only gcc for one project, and only clang for another.

ALE will attempt to parse compile_commands.json files to discover compiler flags to use when linting code. See :help g:ale_c_parse_compile_commands for more information. See Clang's documentation for compile_commands.json files. You should strongly consider generating them in your builds, which is easy to do with CMake.

You can also configure ALE to automatically run make -n to run dry runs on Makefiles to discover compiler flags. This can execute arbitrary code, so the option is disabled by default. See :help g:ale_c_parse_makefile.

ALE supports running linters or fixers via Docker, virtual machines, or in combination with any remote machine with a different file system, so long as the tools are well-integrated with ALE, and ALE is properly configured to run the correct commands and map filename paths between different file systems. See :help ale-lint-other-machines for the full documentation on how to configure ALE to support this.