-
Notifications
You must be signed in to change notification settings - Fork 1.5k
/
Copy pathale.txt
5355 lines (4227 loc) · 234 KB
/
ale.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
*ale.txt* Plugin to lint and fix files asynchronously
*ale*
ALE - Asynchronous Lint Engine
===============================================================================
CONTENTS *ale-contents*
1. Introduction.........................|ale-introduction|
2. Supported Languages & Tools..........|ale-support|
3. Linting..............................|ale-lint|
3.1 Linting On Other Machines.........|ale-lint-other-machines|
3.2 Adding Language Servers...........|ale-lint-language-servers|
3.3 Other Sources.....................|ale-lint-other-sources|
4. Fixing Problems......................|ale-fix|
5. Language Server Protocol Support.....|ale-lsp|
5.1 LSP Neovim Integration............|ale-lsp-neovim|
5.2 Completion........................|ale-completion|
5.3 Go To Definition..................|ale-go-to-definition|
5.4 Go To Type Definition.............|ale-go-to-type-definition|
5.5 Go To Implementation..............|ale-go-to-implementation|
5.6 Find References...................|ale-find-references|
5.7 Hovering..........................|ale-hover|
5.8 Symbol Search.....................|ale-symbol-search|
5.9 Refactoring: Rename, Actions......|ale-refactor|
6. Global Options.......................|ale-options|
6.1 Highlights........................|ale-highlights|
7. Linter/Fixer Options.................|ale-integration-options|
7.1 Options for alex..................|ale-alex-options|
7.2 Options for cspell................|ale-cspell-options|
7.3 Options for languagetool..........|ale-languagetool-options|
7.4 Options for write-good............|ale-write-good-options|
7.5 Other Linter/Fixer Options........|ale-other-integration-options|
8. Commands/Keybinds....................|ale-commands|
9. API..................................|ale-api|
10. Special Thanks......................|ale-special-thanks|
11. Contact.............................|ale-contact|
===============================================================================
1. Introduction *ale-introduction*
ALE provides the means to run linters asynchronously in Vim in a variety of
languages and tools. ALE sends the contents of buffers to linter programs
using the |job-control| features available in Vim 8 and NeoVim. For Vim 8,
Vim must be compiled with the |+job| and |+channel| and |+timers| features
as a minimum.
ALE supports the following key features for linting:
1. Running linters when text is changed.
2. Running linters when files are opened.
3. Running linters when files are saved. (When a global flag is set.)
4. Populating the |location-list| with warning and errors.
5. Setting |signs| with warnings and errors for error markers.
6. Using `:echo` to show error messages when the cursor moves.
7. Setting syntax highlights for errors.
ALE can fix problems with files with the `:ALEFix` command, using the same job
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|
For configuring ALE in Neovim, you can use the |ale.setup| function to
configure ALE globally in `init.vim`. >
require("ale").setup({
completion_enabled = true,
maximum_file_size = 1024 * 1024,
warn_about_trailing_whitespace = false,
})
<
In |ftplugin| files you can customise behavior for different filetypes by
using the |ale.setup.buffer| function. >
-- In ftplugin/python.lua in &runtimepath
require("ale").setup.buffer({
linters = {"ruff", "pyright"},
fixers = {"ruff"}
})
<
Buffer local settings override global settings for that buffer.
===============================================================================
2. Supported Languages & Tools *ale-support*
ALE supports a wide variety of languages and tools. See |ale-supported-list|
for the full list.
===============================================================================
3. Linting *ale-lint*
ALE's primary focus is on checking for problems with your code with various
programs via some Vim code for integrating with those programs, referred to
as 'linters.' ALE supports a wide array of programs for linting by default,
but additional programs can be added easily by defining files in |runtimepath|
with the filename pattern `ale_linters/<filetype>/<filename>.vim`. For more
information on defining new linters, see the extensive documentation
for |ale#linter#Define()|.
Without any configuration, ALE will attempt to check all of the code for every
file you open in Vim with all available tools by default. To see what ALE
is doing, and what options have been set, try using the `:ALEInfo` command.
Most of the linters ALE runs will check the Vim buffer you are editing instead
of the file on disk. This allows you to check your code for errors before you
have even saved your changes. ALE will check your code in the following
circumstances, which can be configured with the associated options.
* When you modify a buffer - |g:ale_lint_on_text_changed|
* On leaving insert mode - |g:ale_lint_on_insert_leave|
* When you open a new or modified buffer - |g:ale_lint_on_enter|
* When you save a buffer - |g:ale_lint_on_save|
* When the filetype changes for a buffer - |g:ale_lint_on_filetype_changed|
* If ALE is used to check code manually - |:ALELint|
*ale-lint-settings-on-startup*
It is worth reading the documentation for every option. You should configure
which events ALE will use before ALE is loaded, so it can optimize which
autocmd commands to run. You can force autocmd commands to be reloaded with
`:ALEDisable | ALEEnable`
This also applies to the autocmd commands used for |g:ale_echo_cursor|.
*ale-lint-file-linters*
Some programs must be run against files which have been saved to disk, and
simply do not support reading temporary files or stdin, either of which are
required for ALE to be able to check for errors as you type. The programs
which behave this way are documented in the lists and tables of supported
programs. ALE will only lint files with these programs in the following
circumstances.
* When you open a new or modified buffer - |g:ale_lint_on_enter|
* When you save a buffer - |g:ale_lint_on_save|
* When the filetype changes for a buffer - |g:ale_lint_on_filetype_changed|
* If ALE is used to check code manually - |:ALELint|
ALE will report problems with your code in the following ways, listed with
their relevant options.
* Via Neovim diagnostics (On in Neovim 0.7+) - |g:ale_use_neovim_diagnostics_api|
* By updating loclist (On by default) - |g:ale_set_loclist|
* By updating quickfix (Off by default) - |g:ale_set_quickfix|
* By setting error highlights - |g:ale_set_highlights|
* By creating signs in the sign column - |g:ale_set_signs|
* By echoing messages based on your cursor - |g:ale_echo_cursor|
* By showing virtual text at your cursor - |g:ale_virtualtext_cursor|
* By previewing details at your cursor - |g:ale_cursor_detail|
* By showing balloons for your mouse cursor - |g:ale_set_balloons|
Please consult the documentation for each option, which can reveal some other
ways of tweaking the behavior of each way of displaying problems. You can
disable or enable whichever options you prefer.
Most settings can be configured for each buffer. (|b:| instead of |g:|),
including disabling ALE for certain buffers with |b:ale_enabled|. The
|g:ale_pattern_options| setting can be used to configure files differently
based on regular expressions for filenames. For configuring entire projects,
the buffer-local options can be used with external plugins for reading Vim
project configuration files. Buffer-local settings can also be used in
ftplugin files for different filetypes.
ALE offers several options for controlling which linters are run.
* Selecting linters to run. - |g:ale_linters|
* Aliasing filetypes for linters - |g:ale_linter_aliases|
* Only running linters you asked for. - |g:ale_linters_explicit|
* Disabling only a subset of linters. - |g:ale_linters_ignore|
* Disabling LSP linters and `tsserver`. - |g:ale_disable_lsp|
You can stop ALE any currently running linters with the `:ALELintStop` command.
Any existing problems will be kept.
-------------------------------------------------------------------------------
3.1 Linting On Other Machines *ale-lint-other-machines*
ALE offers support for running linters or fixers on files you are editing
locally on other machines, so long as the other machine has access to the file
you are editing. This could be a linter or fixer run inside of a Docker image,
running in a virtual machine, running on a remote server, etc.
In order to run tools on other machines, you will need to configure your tools
to run via scripts that execute commands on those machines, such as by setting
the ALE `_executable` options for those tools to a path for a script to run,
or by using |g:ale_command_wrapper| to specify a script to wrap all commands
that are run by ALE, before they are executed. For tools that ALE runs where
ALE looks for locally installed executables first, you may need to set the
`_use_global` options for those tools to `1`, or you can set
|g:ale_use_global_executables| to `1` before ALE is loaded to only use global
executables for all tools.
In order for ALE to properly lint or fix files which are running on another
file system, you must provide ALE with |List|s of strings for mapping paths to
and from your local file system and the remote file system, such as the file
system of your Docker container. See |g:ale_filename_mappings| for all of the
different ways these filename mappings can be configured.
For example, you might configure `pylint` to run via Docker by creating a
script like so. >
#!/usr/bin/env bash
exec docker run -i --rm -v "$(pwd):/data" cytopia/pylint "$@"
<
You will want to run Docker commands with `-i` in order to read from stdin.
With the above script in mind, you might configure ALE to lint your Python
project with `pylint` by providing the path to the script to execute, and
mappings which describe how to change between the two file systems in your
`python.vim` |ftplugin| file, like so: >
if expand('%:p') =~# '^/home/w0rp/git/test-pylint/'
let b:ale_linters = ['pylint']
let b:ale_python_pylint_use_global = 1
" This is the path to the script above.
let b:ale_python_pylint_executable = '/home/w0rp/git/test-pylint/pylint.sh'
" /data matches the path in Docker.
let b:ale_filename_mappings = {
\ 'pylint': [
\ ['/home/w0rp/git/test-pylint', '/data'],
\ ],
\}
endif
<
You might consider using a Vim plugin for loading Vim configuration files
specific to each project, if you have a lot of projects to manage.
-------------------------------------------------------------------------------
3.2 Adding Language Servers *ale-lint-language-servers*
ALE comes with many default configurations for language servers, so they can
be detected and run automatically. ALE can connect to other language servers
by defining a new linter for a filetype. New linters can be defined in |vimrc|,
in plugin files, or `ale_linters` directories in 'runtimepath'.
See |ale-linter-loading-behavior| for more information on loading linters.
A minimal configuration for a language server linter might look so. >
call ale#linter#Define('filetype_here', {
\ 'name': 'any_name_you_want',
\ 'lsp': 'stdio',
\ 'executable': '/path/to/executable',
\ 'command': '%e run',
\ 'project_root': '/path/to/root_of_project',
\})
<
For language servers that use a TCP or named pipe socket connection, you
should define the address to connect to instead. >
call ale#linter#Define('filetype_here', {
\ 'name': 'any_name_you_want',
\ 'lsp': 'socket',
\ 'address': 'servername:1234',
\ 'project_root': '/path/to/root_of_project',
\})
<
Most of the options for a language server can be replaced with a |Funcref| for
a function accepting a buffer number for dynamically computing values such as
the executable path, the project path, the server address, etc, most of which
can also be determined based on executing some other asynchronous task. See
|ale#command#Run()| for computing linter options based on asynchronous
results.
See |ale#linter#Define()| for a detailed explanation of all of the options for
configuring linters.
-------------------------------------------------------------------------------
3.3 Other Sources *ale-lint-other-sources*
Problems for a buffer can be taken from other sources and rendered by ALE.
This allows ALE to be used in combination with other plugins which also want
to display any problems they might find with a buffer. ALE's API includes the
following components for making this possible.
* |ale#other_source#StartChecking()| - Tell ALE that a buffer is being checked.
* |ale#other_source#ShowResults()| - Show results from another source.
* |ALEWantResults| - A signal for when ALE wants results.
Other resources can provide results for ALE to display at any time, following
ALE's loclist format. (See |ale-loclist-format|) For example: >
" Tell ALE to show some results.
" This function can be called at any time.
call ale#other_source#ShowResults(bufnr(''), 'some-linter-name', [
\ {'text': 'Something went wrong', 'lnum': 13},
\])
<
Other sources should use a unique name for identifying themselves. A single
linter name can be used for all problems from another source, or a series of
unique linter names can be used. Results can be cleared for that source by
providing an empty List.
|ale#other_source#StartChecking()| should be called whenever another source
starts checking a buffer, so other tools can know that a buffer is being
checked by some plugin. The |ALEWantResults| autocmd event can be used to
start checking a buffer for problems every time that ALE does. When
|ALEWantResults| is signaled, |g:ale_want_results_buffer| will be set to the
number of the buffer that ALE wants to check.
|ale#other_source#StartChecking()| should be called synchronously, and other
sources should perform their checks on a buffer in the background
asynchronously, so they don't interrupt editing.
|ale#other_source#ShowResults()| must not be called synchronously before
ALE's engine executes its code after the |ALEWantResults| event runs. If
there are immediate results to provide to ALE, a 0 millisecond timer with
|timer_start()| can be set instead up to call |ale#other_source#ShowResults()|
after ALE has first executed its engine code for its own sources.
A plugin might integrate its own checks with ALE like so: >
augroup SomeGroupName
autocmd!
autocmd User ALEWantResults call Hook(g:ale_want_results_buffer)
augroup END
function! DoBackgroundWork(buffer) abort
" Start some work in the background here.
" ...
" Then call WorkDone(a:buffer, results)
endfunction
function! Hook(buffer) abort
" Tell ALE we're going to check this buffer.
call ale#other_source#StartChecking(a:buffer, 'some-name')
call DoBackgroundWork(a:buffer)
endfunction
function! WorkDone(buffer, results) abort
" Send results to ALE after they have been collected.
call ale#other_source#ShowResults(a:buffer, 'some-name', a:results)
endfunction
<
===============================================================================
4. Fixing Problems *ale-fix*
ALE can fix problems with files with the `:ALEFix` command. `:ALEFix`
accepts names of fixers to be applied as arguments. Alternatively,
when no arguments are provided, the variable |g:ale_fixers| will be
read for getting a |List| of commands for filetypes, split on `.`, and
the functions named in |g:ale_fixers| will be executed for fixing the
errors.
The `:ALEFixSuggest` command can be used to suggest tools that be used to
fix problems for the current buffer.
The values for `g:ale_fixers` can be a list of |String|, |Funcref|, or
|lambda| values. String values must either name a function, or a short name
for a function set in the ALE fixer registry.
Each function for fixing errors must accept either one argument `(buffer)` or
two arguments `(buffer, lines)`, representing the buffer being fixed and the
lines to fix. The functions must return either `0`, for changing nothing, a
|List| for new lines to set, a |Dictionary| for describing a command to be
run in the background, or the result of |ale#command#Run()|.
Functions receiving a variable number of arguments will not receive the second
argument `lines`. Functions should name two arguments if the `lines` argument
is desired. This is required to avoid unnecessary copying of the lines of
the buffers being checked.
When a |Dictionary| is returned for an `:ALEFix` callback, the following keys
are supported for running the commands.
`cwd` An optional |String| for setting the working directory
for the command.
If not set, or `v:null`, the `cwd` of the last command
that spawn this one will be used.
`command` A |String| for the command to run. This key is required.
When `%t` is included in a command string, a temporary
file will be created, containing the lines from the file
after previous adjustment have been done.
See |ale-command-format-strings| for formatting options.
`read_temporary_file` When set to `1`, ALE will read the contents of the
temporary file created for `%t`. This option can be used
for commands which need to modify some file on disk in
order to fix files.
`process_with` An optional callback for post-processing.
The callback must accept arguments `(bufnr, output)`:
the buffer number undergoing fixing and the fixer's
output as a |List| of |String|s. It must return a |List|
of |String|s that will be the new contents of the
buffer.
This callback is useful to remove excess lines from the
command's output or apply additional changes to the
output.
`read_buffer` An optional key for disabling reading the buffer.
When set to `0`, ALE will not pipe the buffer's data
into the command via stdin. This option is ignored and
the buffer is not read when `read_temporary_file` is
`1`.
This option defaults to `1`.
*ale-fix-configuration*
Synchronous functions and asynchronous jobs will be run in a sequence for
fixing files, and can be combined. For example:
>
let g:ale_fixers = {
\ 'javascript': [
\ 'DoSomething',
\ 'eslint',
\ {buffer, lines -> filter(lines, 'v:val !=~ ''^\s*//''')},
\ ],
\}
ALEFix
<
The above example will call a function called `DoSomething` which could act
upon some lines immediately, then run `eslint` from the ALE registry, and
then call a lambda function which will remove every single line comment
from the file.
For buffer-local settings, such as in |g:ale_pattern_options| or in ftplugin
files, a |List| may be used for configuring the fixers instead.
>
" Same as the above, only a List can be used instead of a Dictionary.
let b:ale_fixers = [
\ 'DoSomething',
\ 'eslint',
\ {buffer, lines -> filter(lines, 'v:val !=~ ''^\s*//''')},
\]
ALEFix
<
For convenience, a plug mapping is defined for `:ALEFix`, so you can set up a
keybind easily for fixing files. >
" Bind F8 to fixing problems with ALE
nmap <F8> <Plug>(ale_fix)
<
Files can be fixed automatically with the following options, which are all off
by default.
|g:ale_fix_on_save| - Fix files when they are saved.
Fixers can be disabled on save with |g:ale_fix_on_save_ignore|. They will
still be run when you manually run `:ALEFix`.
Fixers can be run on another machines, just like linters, such as fixers run
from a Docker container, running in a virtual machine, running a remote
server, etc. See |ale-lint-other-machines|.
===============================================================================
5. Language Server Protocol Support *ale-lsp*
ALE integrates with Language Server Protocol (LSP) servers. LSP linters can be
used in combination with any other linter, and will automatically connect to
LSP servers when needed. ALE also supports `tsserver` for TypeScript, which
uses a different but very similar protocol.
If you want to use another plugin for LSP features and tsserver, you can use
the |g:ale_disable_lsp| setting to disable ALE's own LSP integrations, or
ignore particular linters with |g:ale_linters_ignore|. In ALE's default
configuration ALE will attempt to avoid conflicting with `nvim-lspconfig`.
ALE will integrate with Neovim's LSP client by default in Neovim 0.8+. This
functionality can be controlled with the |g:ale_use_neovim_lsp_api| setting.
See |ale-lsp-neovim| below for information about ALE's integration with
Neovim's LSP client.
If for any reason you want to stop a language server ALE starts, such as when
a project configuration has significantly changed, or new files have been
added the language server isn't aware of, use either `:ALEStopLSP` or
`:ALEStopAllLSPs` to stop the server until ALE automatically starts it again.
-------------------------------------------------------------------------------
5.1 LSP Neovim Integration *ale-lsp-neovim*
In Neovim 0.8+ ALE will integrate with Neovim's native LSP client by default,
unless disabled by setting |g:ale_use_neovim_lsp_api| to `0`. All built in
functionality for Neovim's LSP client should work as expected, and this
ensures ALE integrates well with other plugins that rely on Neovim's LSP
client.
NOTE: Neovim versions below `0.11.0` do not support socket connections to
language servers when the `address` defined in ALE uses a hostname instead of
an IP address. To work around this, configure language clients with an IP
address instead of a hostname, or revert back to ALE's custom LSP client.
See |lsp| for information on Neovim's built in LSP client.
For diagnostics, for computing problems to show via ALE, ALE overrides the
diagnostics handler for the LSP client launched by ALE, so all of the
functionality in ALE will work as expected. By default ALE will send
diagnostics back to Neovim's diagnostics API, which can be configured with the
|g:ale_use_neovim_diagnostics_api| setting. This ensures that all of the
functionality ALE adds on top for diagnostics will function, and that problems
from linters that don't use LSP can be combined with LSP servers. See the
diagram below. >
+-------------------+
| Language Server | (Sends diagnostics)
+-------------------+
|
+-------------------+
| Neovim LSP Client | (Receives diagnostics)
+-------------------+
|
+-------------------+
| ALE Processing | (Intercepts and processes diagnostics)
+-------------------+
|
+-------------------+
| Diagnostic engine | (Either Neovim's diagnostics or ALE's custom code)
+-------------------+
|
+-------------------+
| Neovim | (User sees formatted diagnostics)
+-------------------+
<
For LSP functionality executed via ALE's own functions, commands, and
keybinds, ALE will intercept requests and handle them in an entirely custom
way, ensuring ALE functionality should work largely the same between
different Vim versions. See the diagram below. >
+-------------------+
| Neovim | (User triggers LSP request via ALE)
+-------------------+
|
+-------------------+
| ALE | (ALE sends request to Neovim client)
+-------------------+
|
+-------------------+
| Neovim LSP Client | (Forwards request to language server)
+-------------------+
|
+-------------------+
| Language Server | (Processes request and sends response)
+-------------------+
|
+-------------------+
| Neovim LSP Client | (Receives response)
+-------------------+
|
+-------------------+
| ALE | (ALE Handles "raw" LSP response)
+-------------------+
|
+-------------------+
| Neovim | (User sees result)
+-------------------+
<
For LSP functionality built-in to Neovim, such as the |gd| keybind for jumping
to a definition, Neovim will bypass ALE entirely, ensuring that ALE does not
interfere with LSP functionality as expected by built-in Neovim tools or other
plugins. See the diagram below. >
+-------------------+
| Neovim | (User triggers LSP request)
+-------------------+
|
+-------------------+
| Neovim LSP Client | (Directly handles the request)
+-------------------+
|
+-------------------+
| Language Server | (Processes request and sends response)
+-------------------+
|
+-------------------+
| Neovim LSP Client | (Receives response and shows result)
+-------------------+
|
+-------------------+
| Neovim | (User sees result)
+-------------------+
<
-------------------------------------------------------------------------------
5.2 Completion *ale-completion*
In Neovim 0.8+ ALE's integration with its native LSP client will make it
possible to use other plugins that rely on Neovim's LSP client as a basis.
`nvim-cmp` is recommended as a completion plugin worth trying in Neovim.
See: https://github.com/hrsh7th/nvim-cmp
ALE offers support for automatic completion of code while you type.
Completion is only supported while at least one LSP linter is enabled. ALE
will only suggest symbols provided by the LSP servers.
*ale-deoplete-integration*
ALE integrates with Deoplete for offering automatic completion data. ALE's
completion source for Deoplete is named `'ale'`, and should enabled
automatically if Deoplete is enabled and configured correctly. Deoplete
integration should not be combined with ALE's own implementation.
*ale-asyncomplete-integration*
ALE additionally integrates with asyncomplete.vim for offering automatic
completion data. ALE's asyncomplete source requires registration with
defaults provided by the |asyncomplete#sources#ale#get_source_options| function >
" Use ALE's function for asyncomplete defaults
" Provide your own overrides here.
au User asyncomplete_setup call asyncomplete#register_source(
\ asyncomplete#sources#ale#get_source_options({
\ 'priority': 10,
\ })
\)
>
ALE also offers its own completion implementation, which does not require any
other plugins. Suggestions will be made while you type after completion is
enabled. ALE's own completion implementation can be enabled by setting
|g:ale_completion_enabled| to `true` or `1`. This setting must be set to
`true` or `1` before ALE is loaded. The delay for completion can be configured
with |g:ale_completion_delay|. This setting should not be enabled if you wish
to use ALE as a completion source for other plugins.
ALE automatic completion will not work when 'paste' is active. Only set
'paste' when you are copy and pasting text into your buffers.
ALE automatic completion will interfere with default insert completion with
`CTRL-N` and so on (|compl-vim|). You can write your own keybinds and a
function in your |vimrc| file to force insert completion instead, like so: >
function! SmartInsertCompletion() abort
" Use the default CTRL-N in completion menus
if pumvisible()
return "\<C-n>"
endif
" Exit and re-enter insert mode, and use insert completion
return "\<C-c>a\<C-n>"
endfunction
inoremap <silent> <C-n> <C-R>=SmartInsertCompletion()<CR>
<
ALE provides an 'omnifunc' function |ale#completion#OmniFunc| for triggering
completion manually with CTRL-X CTRL-O. |i_CTRL-X_CTRL-O| >
" Use ALE's function for omnicompletion.
set omnifunc=ale#completion#OmniFunc
<
*ale-completion-fallback*
You can write your own completion function and fallback on other methods of
completion by checking if there are no results that ALE can determine. For
example, for Python code, you could fall back on the `python3complete`
function. >
function! TestCompletionFunc(findstart, base) abort
let l:result = ale#completion#OmniFunc(a:findstart, a:base)
" Check if ALE couldn't find anything.
if (a:findstart && l:result is -3)
\|| (!a:findstart && empty(l:result))
" Defer to another omnifunc if ALE couldn't find anything.
return python3complete#Complete(a:findstart, a:base)
endif
return l:result
endfunction
set omnifunc=TestCompletionFunc
<
See |complete-functions| for documentation on how to write completion
functions.
ALE will only suggest so many possible matches for completion. The maximum
number of items can be controlled with |g:ale_completion_max_suggestions|.
If you don't like some of the suggestions you see, you can filter them out
with |g:ale_completion_excluded_words| or |b:ale_completion_excluded_words|.
The `:ALEComplete` command can be used to show completion suggestions manually,
even when |g:ale_completion_enabled| is set to `0`. For manually requesting
completion information with Deoplete, consult Deoplete's documentation.
ALE supports automatic imports from external modules. This behavior can be
disabled by setting the |g:ale_completion_autoimport| variable to `0`.
Disabling automatic imports can drop some or all completion items from
some LSP servers (e.g. eclipselsp).
You can manually request imports for symbols at the cursor with the
`:ALEImport` command. The word at the cursor must be an exact match for some
potential completion result which includes additional text to insert into the
current buffer, which ALE will assume is code for an import line. This command
can be useful when your code already contains something you need to import.
You can execute other commands whenever ALE inserts some completion text with
the |ALECompletePost| event.
When working with TypeScript files, ALE can remove warnings from your
completions by setting the |g:ale_completion_tsserver_remove_warnings|
variable to 1.
*ale-completion-completeopt-bug*
ALE Automatic completion implementation replaces |completeopt| before opening
the omnicomplete menu with <C-x><C-o>. In some versions of Vim, the value set
for the option will not be respected. If you experience issues with Vim
automatically inserting text while you type, set the following option in
vimrc, and your issues should go away. >
set completeopt=menu,menuone,preview,noselect,noinsert
<
Or alternatively, if you want to show documentation in popups: >
set completeopt=menu,menuone,popup,noselect,noinsert
<
*ale-symbols*
ALE provides a set of basic completion symbols. If you want to replace those
symbols with others, you can set the variable |g:ale_completion_symbols| with
a mapping of the type of completion to the symbol or other string that you
would like to use. An example here shows the available options for symbols >
let g:ale_completion_symbols = {
\ 'text': '',
\ 'method': '',
\ 'function': '',
\ 'constructor': '',
\ 'field': '',
\ 'variable': '',
\ 'class': '',
\ 'interface': '',
\ 'module': '',
\ 'property': '',
\ 'unit': 'unit',
\ 'value': 'val',
\ 'enum': '',
\ 'keyword': 'keyword',
\ 'snippet': '',
\ 'color': 'color',
\ 'file': '',
\ 'reference': 'ref',
\ 'folder': '',
\ 'enum member': '',
\ 'constant': '',
\ 'struct': '',
\ 'event': 'event',
\ 'operator': '',
\ 'type_parameter': 'type param',
\ '<default>': 'v'
\ }
<
-------------------------------------------------------------------------------
5.3 Go To Definition *ale-go-to-definition*
ALE supports jumping to the files and locations where symbols are defined
through any enabled LSP linters. The locations ALE will jump to depend on the
information returned by LSP servers. The `:ALEGoToDefinition` command will jump
to the definition of symbols under the cursor. See the documentation for the
command for configuring how the location will be displayed.
ALE will update Vim's |tagstack| automatically unless |g:ale_update_tagstack| is
set to `0`.
-------------------------------------------------------------------------------
5.4 Go To Type Definition *ale-go-to-type-definition*
ALE supports jumping to the files and locations where symbols' types are
defined through any enabled LSP linters. The locations ALE will jump to depend
on the information returned by LSP servers. The `:ALEGoToTypeDefinition`
command will jump to the definition of symbols under the cursor. See the
documentation for the command for configuring how the location will be
displayed.
-------------------------------------------------------------------------------
5.5 Go To Implementation *ale-go-to-implementation*
ALE supports jumping to the files and locations where symbols are implemented
through any enabled LSP linters. The locations ALE will jump to depend on the
information returned by LSP servers. The `:ALEGoToImplementation` command will
jump to the implementation of symbols under the cursor. See the documentation
for the command for configuring how the location will be displayed.
-------------------------------------------------------------------------------
5.6 Find References *ale-find-references*
ALE supports finding references for symbols though any enabled LSP linters
with the `:ALEFindReferences` command. See the documentation for the command
for a full list of options.
-------------------------------------------------------------------------------
5.7 Hovering *ale-hover*
ALE supports "hover" information for printing brief information about symbols
at the cursor taken from LSP linters. The following commands are supported:
`:ALEHover` - Print information about the symbol at the cursor.
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. You can disable
this behavior by setting |g:ale_hover_cursor| to `0`.
If |g:ale_set_balloons| is set to `true` or `1` and your version of Vim
supports the |balloon_show()| function, then "hover" information also show up
when you move the mouse over a symbol in a buffer. Diagnostic information will
take priority over hover information for balloons. If a line contains a
problem, that problem will be displayed in a balloon instead of hover
information.
Hover information can be displayed in the preview window instead by setting
|g:ale_hover_to_preview| to `true` or `1`.
When using Neovim or Vim with |popupwin|, if |g:ale_hover_to_floating_preview|
or |g:ale_floating_preview| is set to `true` or `1`, the hover information
will show in a floating window. The borders of the floating preview window can
be customized by setting |g:ale_floating_window_border|.
For Vim 8.1+ terminals, mouse hovering is disabled by default. Enabling
|balloonexpr| commands in terminals can cause scrolling issues in terminals,
so ALE will not attempt to show balloons unless |g:ale_set_balloons| is set to
`true` or `1` before ALE is loaded.
For enabling mouse support in terminals, you may have to change your mouse
settings. For example: >
" Example mouse settings.
" You will need to try different settings, depending on your terminal.
set mouse=a
set ttymouse=xterm
<
Documentation for symbols at the cursor can be retrieved using the
`:ALEDocumentation` command. This command is only available for `tsserver`.
-------------------------------------------------------------------------------
5.8 Symbol Search *ale-symbol-search*
ALE supports searching for workspace symbols via LSP linters with the
`:ALESymbolSearch` command. See the documentation for the command
for a full list of options.
-------------------------------------------------------------------------------
5.9 Refactoring: Rename, Actions *ale-refactor*
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.
Actions will appear in the right click mouse menu by default for GUI versions
of Vim, unless disabled by setting |g:ale_popup_menu_enabled| to `0`.
Make sure to set your Vim to move the cursor position whenever you right
click, and enable the mouse menu: >
set mouse=a
set mousemodel=popup_setpos
<
You may wish to remove some other menu items you don't want to see: >
silent! aunmenu PopUp.Select\ Word
silent! aunmenu PopUp.Select\ Sentence
silent! aunmenu PopUp.Select\ Paragraph
silent! aunmenu PopUp.Select\ Line
silent! aunmenu PopUp.Select\ Block
silent! aunmenu PopUp.Select\ Blockwise
silent! aunmenu PopUp.Select\ All
<
===============================================================================
6. Global Options *ale-options*
Options documented here can be configured either Vim variables, or via the
|ale.setup| and |ale.setup.buffer| functions in Lua. When configuring via
the Lua functions in Lua scripts, ALE will bridge types to Vim script in the
following ways.
1. Strings, numbers, booleans, and `nil` will be represented exactly.
2. Tables with no or only number keys will become a |List| in Vim.
3. Keys other than strings and numbers in tables cannot be represented.
4. Tables with special |metatable| properties cannot be represented.
5. Options accepting functions as values will automatically have Vim functions
created that bridge the function calls to and from Lua code.
*g:airline#extensions#ale#enabled*
g:airline#extensions#ale#enabled
Type: |Number|
Default: `1`
Enables or disables the |airline|'s native extension for ale, which displays
warnings and errors in the status line, prefixed by
|airline#extensions#ale#error_symbol| and
|airline#extensions#ale#warning_symbol|.
*ale-options.cache_executable_check_failures*
*g:ale_cache_executable_check_failures*
cache_executable_check_failures
g:ale_cache_executable_check_failures
Type: |Boolean| or |Number|
Default: `nil`
When set to `true` or `1`, ALE will cache failing executable checks for
linters. By default, only executable checks which succeed will be cached.
When this option is set to `true` or `1`, Vim will have to be restarted
after new executables are installed for ALE to be able to run linters for
those executables.
*ale-options.change_sign_column_color*
*g:ale_change_sign_column_color*
change_sign_column_color
g:ale_change_sign_column_color
Type: |Boolean| or |Number|
Default: `false`
When set to `true` or `1`, this option will set different highlights for the
sign column itself when ALE reports problems with a file. This option can be
combined with |g:ale_sign_column_always|.
ALE uses the following highlight groups for highlighting the sign column:
`:ALESignColumnWithErrors` - Links to `Error` by default.
`:ALESignColumnWithoutErrors` - Uses the value for `SignColumn` by default.
The sign column color can only be changed globally in Vim. The sign column
might produce unexpected results if editing different files in split
windows.
*ale-options.close_preview_on_insert*
*g:ale_close_preview_on_insert*
close_preview_on_insert
g:ale_close_preview_on_insert
Type: |Boolean| or |Number|
Default: `false`
When this option is set to `true` or `1`, ALE's |preview-window| will be
automatically closed upon entering Insert Mode. This option can be used in
combination with |g:ale_cursor_detail| for automatically displaying the
preview window on problem lines, and automatically closing it again when
editing text.
This setting must be set to `true` or `1` before ALE is loaded for this
behavior to be enabled. See |ale-lint-settings-on-startup|.
*ale-options.command_wrapper*
*g:ale_command_wrapper*
*b:ale_command_wrapper*
command_wrapper
g:ale_command_wrapper
Type: |String|
Default: `''`
An option for wrapping all commands that ALE runs, for linters, fixers,
and LSP commands. This option can be set globally, or for specific buffers.
This option can be used to apply nice to all commands. For example: >
" Prefix all commands with nice.
let g:ale_command_wrapper = 'nice -n5'
<
Use the `:ALEInfo` command to view the commands that are run. All of the
arguments for commands will be put on the end of the wrapped command by
default. A `%*` marker can be used to spread the arguments in the wrapped
command. >
" Has the same effect as the above.
let g:ale_command_wrapper = 'nice -n5 %*'
<
For passing all of the arguments for a command as one argument to a wrapper,
`%@` can be used instead. >
" Will result in say: /bin/bash -c 'other-wrapper -c "some command" -x'
let g:ale_command_wrapper = 'other-wrapper -c %@ -x'
<
For commands including `&&` or `;`, only the last command in the list will
be passed to the wrapper. `&&` is most commonly used in ALE to change the
working directory before running a command.