No description
This repository has been archived on 2024-07-19. You can view files and clone it, but cannot push or open issues or pull requests.
Find a file
Gerry Agbobada 3a3c244723 TUI / GUI tooltip with content from ALEHover (#1556)
* Guard the ballooneval settings

* Mark main objectives to do to get nice Hover

* Make tweaks to make the tooltip work - See " XXX: comments

* Guard balloon_show call

* Use return instead of finish for functions

* ale#hover#show : Add optional arguments to specify arbtirary position

This change is requested to be able to call the function with mouse
position to enable hover information in vim's balloon

* ale#ballon#Disable : Remove feature guards

* ale#balloon : Show 'ALEHover' output on balloon if no diagnostic found

* ale#hover#HandleLSPResponse : remove the check for cursor position

This check prevented the 'ALEHover in balloon' feature, since mouse
position is almost never cursor position.

* ale#balloon#MessageForPos : Change the return of balloonexpr

balloonexpr evaluation now works even without balloon_show for basic
diagnostics, leaving the balloon_show call to ale#hover#Show, which can
then feature guard the call to avoid errors

* ale#hover#Response : Feature guard balloon_show calls

* ale#hover : always display 'Hover' information in messages

Also add a small comment to warn readers the different outputs the
ale#hover#Show will write to

* {LSP,TS}Response : use only variables from the Response

It is clearer that we only rely on l:options to get the relevant data to
build the LSP Response string

* hover#ShowDetails : fix an issue where not having focus broke balloons

The issue was caused by not using a buffer-specific version of getline()
to cap the value of the column sent in the message to LSP. Therefore a
cursor on column 10 in an inactive window could send a message with
column=0, if the active window had a buffer with too few lines

* {LSP,TS}Response : Remove redundant checks for balloon_show call

With the upcoming change in ale_set_balloons default value (see Pull
Request w0rp/ale#1565), this check will be useless

* balloonexpr? : Add a flag to separate hover#Show() calls

The goal of this flag is to make `:ALEHover` calls not pop a balloon
under the cursor, since the user has probably no interest in their
cursor while typing the command

The flag is a default argument which is overridden only in ballonexpr
call of ale#hover#Show, and stays set in the hover_map until the
callback for the LSP handles it.

There are no automated tests for this feature right now, and the nature
of the addition (one optional argument in the API) should make it
transparent to existing tests.

Since the differentiation is now possible, the check for moved cursor
has been put back in ale#hover#HandleLSPResponse

* ale#hover#hover_map : Protect accesses to hover_map

Using get() is safer than trying to access directly with ., as the tests
show.

* Raise timeout to try to get Appveyor happy

* Review : Fix comments

* Review : pass the optional argument 'called_from_balloonexpr' in a Dict

This optional dictionary has documentation just before the function
using it, ale#hover#Show, and allows easier extension in the future.
2018-05-16 21:23:48 +01:00
after/plugin Document conflicting plugins check 2017-03-30 01:16:40 -06:00
ale_linters Fix #1584 - Make duplicate msgfmt messages easier to navigate 2018-05-15 18:01:49 +01:00
autoload TUI / GUI tooltip with content from ALEHover (#1556) 2018-05-16 21:23:48 +01:00
doc Improve g:ale_set_balloons default value 2018-05-11 17:46:40 +09:00
ftplugin Implement a preview window for selecting locations to open 2018-04-22 15:53:01 +01:00
img Update the example GIF so it looks a bit nicer 2017-05-07 15:17:30 +01:00
plugin TUI / GUI tooltip with content from ALEHover (#1556) 2018-05-16 21:23:48 +01:00
syntax Implement a preview window for selecting locations to open 2018-04-22 15:53:01 +01:00
test TUI / GUI tooltip with content from ALEHover (#1556) 2018-05-16 21:23:48 +01:00
.appveyor.yml Get all tests to pass on Windows 2017-10-23 23:09:40 +01:00
.editorconfig Add editorconfig (#997) 2017-10-14 15:55:33 +01:00
.gitattributes Move scripts for tests into the test directory, and do not export the Batch script for running tests 2017-09-10 13:19:08 +01:00
.gitignore Close #1439 - Add an :ALEInfoToFile command 2018-04-08 19:04:07 +01:00
.travis.yml Drop "only master branch" travis restriction 2017-07-03 10:54:47 -05:00
CODE_OF_CONDUCT.md Add a non Code of Conduct 2017-06-18 18:24:44 +01:00
CONTRIBUTING.md Fix typo 2017-10-21 08:16:59 -04:00
Dockerfile Update the Dockerfile for experimenting with NeoVim testing 2017-05-11 08:32:45 +01:00
ISSUE_TEMPLATE.md Ask for the first two lines for :version in the issue template 2017-12-08 13:07:32 +00:00
LICENSE Update the licence year. 2018-03-04 11:50:39 +00:00
PULL_REQUEST_TEMPLATE.md Update the issue template to tell you where to find command callback tests 2018-05-15 13:14:28 +01:00
README.md Merge pull request #1555 from BobuSumisu/nasm-linter 2018-05-08 19:02:17 +01:00
run-tests Update run-tests to make use of /usr/bin/env (#1548) 2018-05-01 13:18:03 +01:00
run-tests.bat Add a Batch script for running tests on Windows 2017-09-08 22:15:39 +01:00

Asynchronous Lint Engine Travis CI Build Status AppVeyor Build Status

ALE Logo by Mark Grealish - https://www.bhalash.com/

ALE (Asynchronous Lint Engine) is a plugin for providing linting in NeoVim and Vim 8 while you edit your text files.

linting example

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 (let g:ale_completion_enabled = 1)
  • Finding references (:ALEFindReferences)
  • Hover information (:ALEHover)

Table of Contents

  1. Supported Languages and Tools
  2. Usage
    1. Linting
    2. Fixing
    3. Completion
    4. Go To Definition
    5. Find References
    6. Hovering
  3. Installation
    1. Installation with Vim package management
    2. Installation with Pathogen
    3. Installation with Vundle
  4. Contributing
  5. FAQ
    1. How do I disable particular linters?
    2. How can I keep the sign gutter open?
    3. How can I change the signs ALE uses?
    4. How can I change or disable the highlights ALE uses?
    5. How can I show errors or warnings in my statusline?
    6. How can I show errors or warnings in my lightline?
    7. How can I change the format for echo messages?
    8. How can I execute some code when ALE starts or stops linting?
    9. How can I navigate between errors quickly?
    10. How can I run linters only when I save files?
    11. How can I use the quickfix list instead of the loclist?
    12. How can I check JSX files with both stylelint and eslint?
    13. Will this plugin eat all of my laptop battery power?
    14. How can I configure my C or C++ project?
    15. How can I configure ALE differently for different buffers?
    16. How can I configure the height of the list in which ALE displays errors?

1. Supported Languages and Tools

This plugin supports the following languages and tools. All available tools will be run in combination, so they can be complementary.

Notes:

  • ^ No linters for text or Vim help filetypes are enabled by default.
  • !! These linters check only files on disk. See :help ale-lint-file-linters
Language Tools
ASM gcc
Ansible ansible-lint
API Blueprint drafter
AsciiDoc alex !!, proselint, redpen, write-good
Awk gawk
Bash 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 !!, flawfinder, gcc
CUDA nvcc
C# mcs see:help ale-cs-mcs for details, mcsc !! see:help ale-cs-mcsc for details and configuration
Chef foodcritic
Clojure joker
CMake cmakelint
CoffeeScript coffee, coffeelint
Crystal crystal !!
CSS csslint, prettier, stylelint
Cucumber cucumber
Cython (pyrex filetype) cython
D dmd
Dafny dafny !!
Dart dartanalyzer !!, language_server
Dockerfile hadolint
Elixir credo, dialyxir, dogma !!
Elm elm-format, elm-make
Erb erb, erubi, erubis
Erlang erlc, SyntaxErl
Fish fish -n flag
Fortran gcc
Fountain proselint
FusionScript fusion-lint
Git Commit Messages gitlint
GLSL glslang, glslls
Go gofmt, goimports, go vet !!, golint, gotype !!, gometalinter !!, go build !!, gosimple !!, staticcheck !!
GraphQL eslint, gqlint, prettier
Haml haml-lint
Handlebars ember-template-lint
Haskell brittany, ghc, stack-ghc, stack-build !!, ghc-mod, stack-ghc-mod, hlint, hdevtools, hfmt
HTML alex !!, HTMLHint, proselint, tidy, write-good
Idris idris
Java checkstyle, javac, google-java-format, PMD
JavaScript eslint, flow, jscs, jshint, prettier, prettier-eslint, prettier-standard, standard, xo
JSON fixjson, jsonlint, jq, prettier
Kotlin kotlinc !!, ktlint !! see :help ale-integration-kotlin for configuration instructions
LaTeX alex !!, chktex, lacheck, proselint, redpen, vale, write-good
Less lessc, prettier, stylelint
LLVM llc
Lua luac, luacheck
Mail alex !!, proselint, vale
Make checkmake
Markdown alex !!, markdownlint !!, mdl, prettier, proselint, redpen, remark-lint !!, textlint, vale, write-good
MATLAB mlint
Mercury mmc !!
NASM nasm !!
Nim nim check !!
nix nix-instantiate
nroff alex !!, proselint, write-good
Objective-C clang
Objective-C++ clang
OCaml merlin see :help ale-ocaml-merlin for configuration instructions, ols
Perl perl -c, perl-critic, perltidy
PHP hack, hackfmt, langserver, phan see :help ale-php-phan to instructions, php -l, phpcs, phpmd, phpstan, phpcbf, php-cs-fixer
PO alex !!, msgfmt, proselint, write-good
Pod alex !!, proselint, write-good
Pony ponyc
proto protoc-gen-lint
Pug pug-lint
Puppet puppet, puppet-lint
Python autopep8, black, flake8, isort, mypy, prospector, pycodestyle, pyls, pylint !!, yapf
QML qmlfmt, qmllint
R lintr
ReasonML merlin see :help ale-reasonml-ols for configuration instructions, ols, refmt
reStructuredText alex !!, proselint, redpen, rstcheck, vale, write-good
Re:VIEW redpen
RPM spec rpmlint (disabled by default; see :help ale-integration-spec)
Ruby brakeman !!, rails_best_practices !!, reek, rubocop, ruby, rufo
Rust cargo !! (see :help ale-integration-rust for configuration instructions), rls, rustc, rustfmt
SASS sass-lint, stylelint
SCSS prettier, sass-lint, scss-lint, stylelint
Scala fsc, scalac, scalastyle
Slim slim-lint
SML smlnj
Solidity solhint, solium
Stylus stylelint
SQL sqlint
Swift swiftlint, swiftformat
Tcl nagelfar !!
Terraform tflint
Texinfo alex !!, proselint, write-good
Text^ alex !!, proselint, redpen, textlint, vale, write-good
Thrift thrift
TypeScript eslint, prettier, tslint, tsserver, typecheck
Verilog iverilog, verilator
Vim vint
Vim help^ alex !!, proselint, write-good
Vue prettier
XHTML alex !!, proselint, write-good
XML xmllint
YAML swaglint, yamllint

2. Usage

2.i Linting

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 behaviour 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-linter-options for options specified to particular linters.

2.ii Fixing

ALE can fix files with the ALEFix command. Functions need to be configured for different filetypes with the g:ale_fixers variable. For example, the following code can be used to fix JavaScript code with ESLint:

" Put this in vimrc or a plugin file of your own.
" After this is configured, :ALEFix will try and fix your JS code with ESLint.
let g:ale_fixers = {
\   'javascript': ['eslint'],
\}

" Set this setting in vimrc if you want to fix files automatically on save.
" This is off by default.
let g:ale_fix_on_save = 1

The :ALEFixSuggest command will suggest some supported tools for fixing code, but fixers can be also implemented with functions, including lambda functions too. See :help ale-fix for detailed information.

2.iii Completion

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 TypeSript.

" Enable completion where available.
let g:ale_completion_enabled = 1

See :help ale-completion for more information.

2.iv Go To Definition

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.

2.v Find References

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.

2.vi Hovering

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.

See :help ale-hover for more information.

3. Installation

To install this plugin, you should use one of the following methods. For Windows users, replace usage of the Unix ~/.vim directory with %USERPROFILE%\vimfiles, or another directory if you have configured Vim differently. On Windows, your ~/.vimrc file will be similarly stored in %USERPROFILE%\_vimrc.

3.i. Installation with Vim package management

In Vim 8 and NeoVim, you can install plugins easily without needing to use any other tools. Simply clone the plugin into your pack directory.

Vim 8 on Unix

mkdir -p ~/.vim/pack/git-plugins/start
git clone https://github.com/w0rp/ale.git ~/.vim/pack/git-plugins/start/ale

NeoVim on Unix

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

Vim 8 on Windows

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

Generating Vim help files

You can add the following line to your vimrc files to generate documentation tags automatically, if you don't have something similar already, so you can use the :help command to consult ALE's online documentation:

" Put these lines at the very end of your vimrc file.

" Load all plugins now.
" Plugins need to be added to runtimepath before helptags can be generated.
packloadall
" Load all of the helptags now, after plugins have been loaded.
" All messages and errors will be ignored.
silent! helptags ALL

3.ii. Installation with Pathogen

To install this module with Pathogen, you should clone this repository to your bundle directory, and ensure you have the line execute pathogen#infect() in your ~/.vimrc file. You can run the following commands in your terminal to do so:

cd ~/.vim/bundle
git clone https://github.com/w0rp/ale.git

3.iii. Installation with Vundle

You can install this plugin using Vundle by using the path on GitHub for this repository.

Plugin 'w0rp/ale'

See the Vundle documentation for more information.

4. Contributing

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 the project more directly, check out the #vim-ale channel on Freenode. Web chat is available here.

5. FAQ

5.i. How do I disable particular linters?

By default, all available tools for all supported languages will be run. If you want to only select a subset of the tools, simply create a g:ale_linters dictionary in your vimrc file mapping filetypes to lists of linters to run.

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.

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.

5.ii. How can I keep the sign gutter open?

You can keep the sign gutter open at all times by setting the g:ale_sign_column_always to 1

let g:ale_sign_column_always = 1

5.iii. How can I change the signs ALE uses?

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

5.iv. How can I change or disable the highlights ALE uses?

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.

5.v. How can I show errors or warnings in my statusline?

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

If you don't want to use vim-airline, you can implement your own statusline function without adding any other plugins. ALE provides a function for counting the number of problems for this purpose, named ale#statusline#Count.

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() for more information.

5.vi. How can I show errors or warnings in my lightline?

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.

5.vii. How can I change the format for echo messages?

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:

Echoed message

See :help g:ale_echo_msg_format for more information.

5.viii. How can I execute some code when ALE starts or stops linting?

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

5.ix. How can I navigate between errors quickly?

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.

5.x. How can I run linters only when I save files?

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'
" 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.

5.xi. How can I use the quickfix list instead of the loclist?

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.

5.xii. How can I check JSX files with both stylelint and eslint?

If you configure ALE options correctly in your vimrc file, and install the right tools, you can check JSX files with stylelint and eslint.

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 your vimrc file:

let g:ale_linters = {'jsx': ['stylelint', 'eslint']}
let g:ale_linter_aliases = {'jsx': 'css'}

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.

5.xiii. Will this plugin eat all of my laptop battery power?

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 behaviour. Set g:ale_lint_on_text_changed to never or normal. 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.

5.xiv. How can I configure my C or C++ project?

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 and clangtidy 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.

You may also configure buffer-local settings for linters with project-specific vimrc files. local_vimrc can be used for executing local vimrc files which can be shared in your project.

5.xv. How can I configure ALE differently for different buffers?

ALE offers various ways to configure which linters or fixers are run, and other settings. For the majority of ALE's settings, they can either be configured globally with a g: variable prefix, or for a specific buffer with a b: variable prefix. For example, you can configure a Python ftplugin file like so.

" In ~/.vim/ftplugin/python.vim

" Check Python files with flake8 and pylint.
let b:ale_linters = ['flake8', 'pylint']
" Fix Python files with autopep8 and yapf.
let b:ale_fixers = ['autopep8', 'yapf']
" Disable warnings about trailing whitespace for Python files.
let b:ale_warn_about_trailing_whitespace = 0

For configuring files based on regular expression patterns matched against the absolute path to a file, you can use g:ale_pattern_options.

" Do not lint or fix minified files.
let g:ale_pattern_options = {
\ '\.min\.js$': {'ale_linters': [], 'ale_fixers': []},
\ '\.min\.css$': {'ale_linters': [], 'ale_fixers': []},
\}
" If you configure g:ale_pattern_options outside of vimrc, you need this.
let g:ale_pattern_options_enabled = 1

Buffer-local variables for settings always override the global settings.

5.xvi. How can I configure the height of the list in which ALE displays errors?

To set a default height for the error list, use the g:ale_list_window_size variable.

" Show 5 lines of errors (default: 10)
let g:ale_list_window_size = 5