-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Expand file tree
/
Copy pathlsp.txt
More file actions
3240 lines (2647 loc) · 140 KB
/
lsp.txt
File metadata and controls
3240 lines (2647 loc) · 140 KB
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
*lsp.txt* LSP
NVIM REFERENCE MANUAL
LSP client/framework *lsp* *LSP*
Nvim supports the Language Server Protocol (LSP), which means it acts as
a client to LSP servers and includes a Lua framework `vim.lsp` for building
enhanced LSP tools.
https://microsoft.github.io/language-server-protocol/
LSP facilitates features like go-to-definition, find references, hover,
completion, rename, format, refactor, etc., using semantic whole-project
analysis (unlike |ctags|).
Type |gO| to see the table of contents.
==============================================================================
QUICKSTART *lsp-quickstart*
Nvim provides an LSP client, but the servers are provided by third parties.
Follow these steps to get LSP features:
1. Install language servers using your package manager or by following the
upstream installation instructions. You can find language servers here:
https://microsoft.github.io/language-server-protocol/implementors/servers/
2. Define a new config |lsp-new-config| (or install https://github.com/neovim/nvim-lspconfig).
Example: >lua
vim.lsp.config['lua_ls'] = {
-- Command and arguments to start the server.
cmd = { 'lua-language-server' },
-- Filetypes to automatically attach to.
filetypes = { 'lua' },
-- Sets the "workspace" to the directory where any of these files is found.
-- Files that share a root directory will reuse the LSP server connection.
-- Nested lists indicate equal priority, see |vim.lsp.Config|.
root_markers = { { '.luarc.json', '.luarc.jsonc' }, '.git' },
-- Specific settings to send to the server. The schema is server-defined.
-- Example: https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json
settings = {
Lua = {
runtime = {
version = 'LuaJIT',
}
}
}
}
3. Use |vim.lsp.enable()| to enable the config.
Example: >lua
vim.lsp.enable('lua_ls')
4. Open a code file matching one of the `filetypes` specified in the config.
Note: Depending on the LSP server, you may need to ensure your project has
a |lsp-root_markers| file so the workspace can be recognized.
5. Check that LSP is active ("attached") for the buffer: >vim
:checkhealth vim.lsp
6. Note: some LSP features are disabled by default, you can enable them
manually:
- |lsp-codelens|
- |lsp-linked_editing_range|
- |lsp-inlay_hint|
- |lsp-inline_completion|
7. (Optional) Configure keymaps and autocommands to use LSP features.
|lsp-attach|
==============================================================================
DEFAULTS *lsp-defaults*
When LSP activates, by default it enables various LSP features and sets
options and keymaps, listed below, if (1) the language server supports the
functionality and (2) the options are empty or were set by the builtin runtime
(ftplugin) files. The options are not restored when the LSP client is stopped
or detached.
GLOBAL DEFAULTS *gra* *gri* *grn* *grr* *grt* *grx* *i_CTRL-S*
These GLOBAL keymaps are created unconditionally when Nvim starts:
- "gra" (Normal and Visual mode) is mapped to |vim.lsp.buf.code_action()|
- "gri" is mapped to |vim.lsp.buf.implementation()|
- "grn" is mapped to |vim.lsp.buf.rename()|
- "grr" is mapped to |vim.lsp.buf.references()|
- "grt" is mapped to |vim.lsp.buf.type_definition()|
- "grx" is mapped to |vim.lsp.codelens.run()|
- "gO" is mapped to |vim.lsp.buf.document_symbol()|
- CTRL-S (Insert mode) is mapped to |vim.lsp.buf.signature_help()|
- |v_an| and |v_in| fall back to LSP |vim.lsp.buf.selection_range()| if
treesitter is not active.
- |gx| handles `textDocument/documentLink`. Example: with gopls, invoking gx
on "os" in this Go code will open documentation externally: >
package nvim
import (
"os"
)
<
These LSP features are enabled by default:
- Diagnostics |lsp-diagnostic|. See |vim.diagnostic.config()| to customize.
- `workspace/didChangeWatchedFiles` (except on Linux). If you see poor
performance in big workspaces, run `:checkhealth vim.lsp` and look for "file
watching". Try disabling file-watching: >lua
local capabilities = vim.lsp.protocol.make_client_capabilities()
if capabilities.workspace then
capabilities.workspace.didChangeWatchedFiles = nil
end
vim.lsp.config('*', {
capabilities = capabilities,
})
<
BUFFER-LOCAL DEFAULTS
- 'omnifunc' is set to |vim.lsp.omnifunc()|, use |i_CTRL-X_CTRL-O| to trigger
completion.
- 'tagfunc' is set to |vim.lsp.tagfunc()|. This enables features like
go-to-definition, |:tjump|, and keymaps like |CTRL-]|, |CTRL-W_]|,
|CTRL-W_}| to utilize the language server.
- 'formatexpr' is set to |vim.lsp.formatexpr()|, so you can format lines via
|gq| if the language server supports it.
- To opt out of this use |gw| instead of gq, or clear 'formatexpr' on |LspAttach|.
- |K| is mapped to |vim.lsp.buf.hover()| unless 'keywordprg' is customized or
a custom keymap for `K` exists.
- Document colors are enabled for highlighting color references in a document.
- To opt out call `vim.lsp.document_color.enable(false, { bufnr = ev.buf })` on |LspAttach|.
DISABLING DEFAULTS *lsp-defaults-disable*
You can remove GLOBAL keymaps at any time using |vim.keymap.del()| or
|:unmap|. See also |gr-default|.
To remove or override BUFFER-LOCAL defaults, define a |LspAttach| handler: >lua
vim.api.nvim_create_autocmd('LspAttach', {
callback = function(ev)
-- Unset 'formatexpr'
vim.bo[ev.buf].formatexpr = nil
-- Unset 'omnifunc'
vim.bo[ev.buf].omnifunc = nil
-- Unmap K
vim.keymap.del('n', 'K', { buf = ev.buf })
-- Disable document colors
vim.lsp.document_color.enable(false, { bufnr = ev.buf })
end,
})
<
==============================================================================
COMMANDS *:lsp* *lsp-commands* *E5800*
*E5801*
The following commands operate on |lsp-config|s:
*:lsp-enable* *E5802* *E5803*
:lsp enable [config_name]
Activates LSP for current and future buffers. See |vim.lsp.enable()|.
*:lsp-disable* *E5804*
:lsp disable [config_name]
Disables LSP (and stops if running) for current and future buffers.
See |vim.lsp.enable()|.
*E5805* *E5806*
The following commands operate on running clients:
*:lsp-restart*
:lsp restart [client_name]
Restarts LSP clients and servers. If no client names are given, all active
clients attached to the current buffer are restarted.
*:lsp-stop*
:lsp stop [client_name]
Stops LSP clients and servers. If no client names are given, all active
clients attached to the current buffer are stopped. Use |Client:stop()| for
non-interactive use.
==============================================================================
CONFIG *lsp-config*
You can configure LSP behavior statically via vim.lsp.config(), and
dynamically via |lsp-attach| or |Client:on_attach()|.
Use |vim.lsp.config()| to define or modify LSP configurations, and
|vim.lsp.enable()| to auto-activate them. This is basically a wrapper around
|vim.lsp.start()| which allows you to share and merge configs (provided by
Nvim, plugins, and your local config).
NEW CONFIG *lsp-new-config*
To create a new config you can either use `vim.lsp.config()` or create
a `lsp/<config-name>.lua` file.
EXAMPLE: DEFINE A CONFIG AS CODE ~
1. Run `:lua vim.lsp.config('foo', {cmd={'true'}})`
2. Run `:lua vim.lsp.enable('foo')`
3. Run `:checkhealth vim.lsp`, check "Enabled Configurations". 😎
EXAMPLE: DEFINE A CONFIG AS A FILE ~
1. Create a file `lsp/foo.lua` somewhere on your 'runtimepath'. >
:exe 'edit' stdpath('config') .. '/lsp/foo.lua'
2. Add this code to the file (or copy an example from
https://github.com/neovim/nvim-lspconfig): >
return {
cmd = { 'true' },
}
3. Save the file (with `++p` to ensure its parent directory is created). >
:write ++p
4. Enable the config. >
:lua vim.lsp.enable('foo')
5. Run `:checkhealth vim.lsp`, check "Enabled Configurations". 🌈
HOW CONFIGS ARE MERGED *lsp-config-merge*
When an LSP client starts, it resolves its configuration by merging the
following sources (merge semantics defined by |vim.tbl_deep_extend()| with
"force" behavior), in order of increasing priority:
1. Configuration defined for the `'*'` name.
2. The merged configuration of all `lsp/<config>.lua` files in 'runtimepath'
for the config named `<config>`.
3. The merged configuration of all `after/lsp/<config>.lua` files in
'runtimepath'.
- This behavior of the "after/" directory is a standard Vim feature
|after-directory| which allows you to override `lsp/*.lua` configs
provided by plugins (such as nvim-lspconfig).
4. Configurations defined anywhere else.
Example: given the following configs... >lua
-- Defined in init.lua
vim.lsp.config('*', {
capabilities = {
textDocument = {
semanticTokens = {
multilineTokenSupport = true,
}
}
},
root_markers = { '.git' },
})
-- Defined in <rtp>/lsp/clangd.lua
return {
cmd = { 'clangd' },
root_markers = { '.clangd', 'compile_commands.json' },
filetypes = { 'c', 'cpp' },
}
-- Defined in init.lua
vim.lsp.config('clangd', {
filetypes = { 'c' },
})
<
...the merged result is: >lua
{
-- From the clangd configuration in <rtp>/lsp/clangd.lua
cmd = { 'clangd' },
-- From the clangd configuration in <rtp>/lsp/clangd.lua
-- Overrides the "*" configuration in init.lua
root_markers = { '.clangd', 'compile_commands.json' },
-- From the clangd configuration in init.lua
-- Overrides the clangd configuration in <rtp>/lsp/clangd.lua
filetypes = { 'c' },
-- From the "*" configuration in init.lua
capabilities = {
textDocument = {
semanticTokens = {
multilineTokenSupport = true,
}
}
}
}
<
CONFIGURE ON ATTACH *lsp-attach*
To use LSP features beyond those provided by Nvim (see |lsp-buf|), you can set
keymaps and options on |Client:on_attach()| or |LspAttach|. Not all language
servers provide the same capabilities; check `supports_method()` in your
LspAttach handler.
*lsp-lint* *lsp-format*
Example: Enable auto-completion and auto-formatting ("linting"): >lua
vim.api.nvim_create_autocmd('LspAttach', {
group = vim.api.nvim_create_augroup('my.lsp', {}),
callback = function(ev)
local client = assert(vim.lsp.get_client_by_id(ev.data.client_id))
if client:supports_method('textDocument/implementation') then
-- Create a keymap for vim.lsp.buf.implementation ...
end
-- Enable auto-completion. Note: Use CTRL-Y to select an item. |complete_CTRL-Y|
if client:supports_method('textDocument/completion') then
-- Optional: trigger autocompletion on EVERY keypress. May be slow!
-- local chars = {}; for i = 32, 126 do table.insert(chars, string.char(i)) end
-- client.server_capabilities.completionProvider.triggerCharacters = chars
vim.lsp.completion.enable(true, client.id, ev.buf, {autotrigger = true})
end
-- Auto-format ("lint") on save.
-- Usually not needed if server supports "textDocument/willSaveWaitUntil".
if not client:supports_method('textDocument/willSaveWaitUntil')
and client:supports_method('textDocument/formatting') then
vim.api.nvim_create_autocmd('BufWritePre', {
group = vim.api.nvim_create_augroup('my.lsp', {clear=false}),
buffer = ev.buf,
callback = function()
vim.lsp.buf.format({ bufnr = ev.buf, id = client.id, timeout_ms = 1000 })
end,
})
end
end,
})
<
To see the capabilities for a given server, try this in a LSP-enabled buffer: >vim
:lua =vim.lsp.get_clients()[1].server_capabilities
================================================================================
FAQ *lsp-faq*
- Q: How to force-reload LSP?
- A: Use `:lsp restart`. You can also stop all clients, then reload the buffer: >vim
:lsp stop
:edit
<
- Q: Why isn't completion working?
- A: In the buffer where you want to use LSP, check that 'omnifunc' is set to
"v:lua.vim.lsp.omnifunc": `:verbose set omnifunc?`
- Some other plugin may be overriding the option. To avoid that you could
set the option in an |after-directory| ftplugin, e.g.
"after/ftplugin/python.vim".
- Q: How do I run a request synchronously (e.g. for formatting on file save)?
- A: Check if the function has an `async` parameter and set the value to
false. E.g. code formatting: >vim
" Auto-format *.rs (rust) files prior to saving them
" (async = false is the default for format)
autocmd BufWritePre *.rs lua vim.lsp.buf.format({ async = false })
<
- Q: How to avoid my own lsp/ folder being overridden?
- A: Place your configs under "after/lsp/". Files in "after/lsp/" are loaded
after those in "nvim/lsp/", so your settings will take precedence over
the defaults provided by nvim-lspconfig. See also: |after-directory|
*lsp-vs-treesitter*
- Q: How do LSP, Treesitter and Ctags compare?
- A: LSP requires a client and language server. The language server uses
semantic analysis to understand code at a project level. This provides
language servers with the ability to rename across files, find
definitions in external libraries and more.
|treesitter| is a language parsing library that provides excellent tools
for incrementally parsing text and handling errors. This makes it a great
fit for editors to understand the contents of the current file for things
like syntax highlighting, simple goto-definitions, scope analysis and
more.
A |ctags|-like program can generate a |tags| file that allows Nvim to
jump to definitions, provide simple completions via |i_CTRL-X_CTRL-]|
command. It is not as featureful and doesn't have semantic understanding,
but it is fast, lightweight and useful for navigating polyglot projects.
================================================================================
LSP API *lsp-api*
The |lsp-core| API provides core functions for creating and managing clients,
You can even create creating custom (in-process) |lsp-server|s.
The |lsp-buf| functions operate LSP clients attached to the current buffer.
------------------------------------------------------------------------------
CONCEPTS
*lsp-method*
Requests and notifications defined by the LSP specification are referred to as
"LSP methods". These are handled by |lsp-handler| functions.
*lsp-handler*
LSP handlers are functions that handle |lsp-response|s to requests made by Nvim
to the server. (Notifications, as opposed to requests, are fire-and-forget:
there is no response, so they can't be handled. |lsp-notification|)
Each handler has the following signature: >
vim.lsp.ResponseHandler:
fun(err, result, ctx)
vim.lsp.NotificationHandler:
fun(err, params, ctx)
vim.lsp.RequestHandler:
fun(err, params, ctx): Result?, lsp.ResponseError?
Each response handler has this signature: >
function(err, result, ctx)
<
Parameters: ~
• {err} (`table|nil`) Error info dict, or `nil` if the request
completed.
• {result} (`Result|Params|nil`) `result` key of the |lsp-response| or
`nil` if the request failed.
• {ctx} (`table`) Table of calling state associated with the
handler, with these keys:
• {method} (`string`) |lsp-method| name.
• {client_id} (`number`) |vim.lsp.Client| identifier.
• {bufnr} (`Buffer`) Buffer handle.
• {params} (`table|nil`) Request parameters table.
• {version} (`number`) Document version at time of
request. Handlers can compare this to the
current document version to check if the
response is "stale". See also |b:changedtick|.
Return (multiple): ~
• (`Result?`) `result` on success, or `nil` on error.
• (`lsp.ResponseError?`) `error` on failure, or `nil` on success.
RPC error shape: >
{ code, message, data? }
< You can use |vim.lsp.rpc.rpc_response_error()| to create this object.
|lsp-response| and |lsp-notification| handlers do not have return
values.
*lsp-handler-resolution*
Handlers can be set by (in increasing priority):
*vim.lsp.handlers*
- Directly calling a LSP method via |Client:request()|. This is the only way
to "override" the default client-to-server request handling (by
side-stepping `vim.lsp.buf` and related interfaces). >lua
local client = assert(vim.lsp.get_clients()[1])
client:request('textDocument/definition')
- Setting a field in `vim.lsp.handlers`. This global table contains the
default mappings of |lsp-method| names to handlers. (Note: only for
server-to-client requests/notifications, not client-to-server.)
Example: >lua
vim.lsp.handlers['textDocument/publishDiagnostics'] = my_custom_diagnostics_handler
- Passing a {handlers} parameter to |vim.lsp.start()|. This sets the default
|lsp-handler| for a specific server. (Note: only for server-to-client
requests/notifications, not client-to-server.)
Example: >lua
vim.lsp.start {
..., -- Other configuration omitted.
handlers = {
['textDocument/publishDiagnostics'] = my_custom_diagnostics_handler
},
}
- Passing a {handler} parameter to |vim.lsp.buf_request_all()|. This sets the
|lsp-handler| ONLY for the given request(s).
Example: >lua
vim.lsp.buf_request_all(
0,
'textDocument/publishDiagnostics',
my_request_params,
my_handler
)
<
*vim.lsp.log_levels*
Log levels are defined in |vim.log.levels|
------------------------------------------------------------------------------
PROTOCOL *vim.lsp.protocol*
Module `vim.lsp.protocol` defines constants dictated by the LSP specification,
and helper functions for creating protocol-related objects.
https://github.com/microsoft/language-server-protocol/raw/gh-pages/_specifications/specification-3-14.md
For example `vim.lsp.protocol.ErrorCodes` allows reverse lookup by number or
name: >lua
vim.lsp.protocol.TextDocumentSyncKind.Full == 1
vim.lsp.protocol.TextDocumentSyncKind[1] == "Full"
<
*lsp-request*
LSP request shape: >
{ id: integer|string, method: string, params?: Params }
<
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#requestMessage
*lsp-response*
LSP response shape: >
{ id: integer|string|nil, result: Result, error: nil } (on success)
{ id: integer|string|nil, result: nil, error: ResponseError } (on error)
<
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#responseMessage
*lsp-notification*
LSP notification shape: >
{ method: string, params?: Params }
<
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#notificationMessage
------------------------------------------------------------------------------
IN-PROCESS LSP SERVER *lsp-server*
For maximum flexibility you may want to create your own server. This allows
you to hook into Nvim LSP features automatically. The "server" can be an
in-process Lua function instead of an external process. For example see
`runtime/lua/vim/pack/_lsp.lua` which provides features like "docs
hover" in the vim.pack "Confirm Updates" UI.
This is possible because |vim.lsp.start()| accepts `cmd` as a Lua function.
The function must accept `vim.lsp.rpc.Dispatchers` and return a table in the
form of |vim.lsp.rpc.Client|. Use `dispatchers.on_exit()` to signal that the
server has stopped.
Example (select and run the code with `:lua`, then check `:che vim.lsp` and
look for "my-server"): >lua
--- @return vim.lsp.rpc.Client
local function cmd_fn(dispatchers)
local closing = false
local request_id = 0
local srv = {} --[[@type vim.lsp.rpc.Client]]
function srv.request(method, params, callback)
if method == 'initialize' then
callback(nil, {
capabilities = {
hoverProvider = true,
},
})
elseif method == 'shutdown' then
callback(nil, nil)
end
request_id = request_id + 1
return true, request_id
end
function srv.notify(method, params)
if method == 'exit' then
dispatchers.on_exit(0, 15)
end
end
function srv.is_closing()
return closing
end
function srv.terminate()
closing = true
end
return srv
end
-- Define a config for the server, then enable it...
vim.lsp.config['my-server'] = {
cmd = cmd_fn,
filetypes = { 'lua' },
root_markers = { '.git' },
}
vim.lsp.enable('my-server')
-- ...or call start() directly.
vim.lsp.start(
{ cmd = cmd_fn, name = 'my-server', root_dir = vim.uv.cwd() },
{ attach = true })
<
================================================================================
LSP HIGHLIGHT *lsp-highlight*
Reference Highlights:
Highlight groups that are meant to be used by |vim.lsp.buf.document_highlight()|.
You can see more about the differences in types here:
https://microsoft.github.io/language-server-protocol/specification#textDocument_documentHighlight
*hl-LspReferenceText*
LspReferenceText used for highlighting "text" references
*hl-LspReferenceRead*
LspReferenceRead used for highlighting "read" references
*hl-LspReferenceWrite*
LspReferenceWrite used for highlighting "write" references
*hl-LspReferenceTarget*
LspReferenceTarget used for highlighting reference targets (e.g. in a
hover range)
*hl-LspInlayHint*
LspInlayHint used for highlighting inlay hints
*lsp-highlight-codelens*
Highlight groups related to |lsp-codelens| functionality.
*hl-LspCodeLens*
LspCodeLens
Used to color the virtual text of the codelens. See
|nvim_buf_set_extmark()|.
LspCodeLensSeparator *hl-LspCodeLensSeparator*
Used to color the separator between two or more code lenses.
*lsp-highlight-signature*
Highlight groups related to |vim.lsp.handlers.signature_help()|.
*hl-LspSignatureActiveParameter*
LspSignatureActiveParameter
Used to highlight the active parameter in the signature help. See
|vim.lsp.handlers.signature_help()|.
------------------------------------------------------------------------------
LSP SEMANTIC HIGHLIGHTS *lsp-semantic-highlight*
When available, the LSP client highlights code using |lsp-semantic_tokens|,
which are another way that LSP servers can provide information about source
code. Note that this is in addition to treesitter syntax highlighting;
semantic highlighting does not replace syntax highlighting.
The server will typically provide one token per identifier in the source code.
The token will have a `type` such as "function" or "variable", and 0 or more
`modifier`s such as "readonly" or "deprecated." The standard types and
modifiers are described here:
https://microsoft.github.io/language-server-protocol/specification/#textDocument_semanticTokens
LSP servers may also use off-spec types and modifiers.
The LSP client adds one or more highlights for each token. The highlight
groups are derived from the token's type and modifiers:
• `@lsp.type.<type>.<ft>` for the type
• `@lsp.mod.<mod>.<ft>` for each modifier
• `@lsp.typemod.<type>.<mod>.<ft>` for each modifier
Use |:Inspect| to view the highlights for a specific token. Use |:hi| or
|nvim_set_hl()| to change the appearance of semantic highlights: >vim
hi @lsp.type.function guifg=Yellow " function names are yellow
hi @lsp.type.variable.lua guifg=Green " variables in lua are green
hi @lsp.mod.deprecated gui=strikethrough " deprecated is crossed out
hi @lsp.typemod.function.async guifg=Blue " async functions are blue
<
The value |vim.hl.priorities|`.semantic_tokens` is the priority of the
`@lsp.type.*` highlights. The `@lsp.mod.*` and `@lsp.typemod.*` highlights
have priorities one and two higher, respectively.
You can disable semantic highlights by clearing the highlight groups: >lua
-- Hide semantic highlights for functions
vim.api.nvim_set_hl(0, '@lsp.type.function', {})
-- Hide all semantic highlights
for _, group in ipairs(vim.fn.getcompletion("@lsp", "highlight")) do
vim.api.nvim_set_hl(0, group, {})
end
<
You probably want these inside a |ColorScheme| autocommand.
Use |LspTokenUpdate| and |vim.lsp.semantic_tokens.highlight_token()| for more
complex highlighting.
The following is a list of standard captures used in queries for Nvim,
highlighted according to the current colorscheme (use |:Inspect| on one to see
the exact definition):
@lsp.type.class Identifiers that declare or reference a class type
@lsp.type.comment Tokens that represent a comment
@lsp.type.decorator Identifiers that declare or reference decorators and annotations
@lsp.type.enum Identifiers that declare or reference an enumeration type
@lsp.type.enumMember Identifiers that declare or reference an enumeration property, constant, or member
@lsp.type.event Identifiers that declare an event property
@lsp.type.function Identifiers that declare a function
@lsp.type.interface Identifiers that declare or reference an interface type
@lsp.type.keyword Tokens that represent a language keyword
@lsp.type.macro Identifiers that declare a macro
@lsp.type.method Identifiers that declare a member function or method
@lsp.type.modifier Tokens that represent a modifier
@lsp.type.namespace Identifiers that declare or reference a namespace, module, or package
@lsp.type.number Tokens that represent a number literal
@lsp.type.operator Tokens that represent an operator
@lsp.type.parameter Identifiers that declare or reference a function or method parameters
@lsp.type.property Identifiers that declare or reference a member property, member field, or member variable
@lsp.type.regexp Tokens that represent a regular expression literal
@lsp.type.string Tokens that represent a string literal
@lsp.type.struct Identifiers that declare or reference a struct type
@lsp.type.type Identifiers that declare or reference a type that is not covered above
@lsp.type.typeParameter Identifiers that declare or reference a type parameter
@lsp.type.variable Identifiers that declare or reference a local or global variable
@lsp.mod.abstract Types and member functions that are abstract
@lsp.mod.async Functions that are marked async
@lsp.mod.declaration Declarations of symbols
@lsp.mod.defaultLibrary Symbols that are part of the standard library
@lsp.mod.definition Definitions of symbols, for example, in header files
@lsp.mod.deprecated Symbols that should no longer be used
@lsp.mod.documentation Occurrences of symbols in documentation
@lsp.mod.modification Variable references where the variable is assigned to
@lsp.mod.readonly Readonly variables and member fields (constants)
@lsp.mod.static Class members (static members)
==============================================================================
EVENTS *lsp-events*
LspAttach *LspAttach*
After an LSP client performs "initialize" and attaches to a buffer. The
|autocmd-pattern| is the buffer name. The |event-data| (type:
`vim.event.lspattach.data`) has the client ID.
Example: >lua
vim.api.nvim_create_autocmd('LspAttach', {
callback = function(ev)
local client = vim.lsp.get_client_by_id(ev.data.client_id)
-- ...
end
})
<
Note: If the LSP server performs dynamic registration, capabilities may be
registered any time _after_ LspAttach. In that case you may want to handle
the "registerCapability" event.
Example: >lua
vim.lsp.handlers['client/registerCapability'] = (function(overridden)
return function(err, res, ctx)
local result = overridden(err, res, ctx)
local client = vim.lsp.get_client_by_id(ctx.client_id)
if not client then
return
end
for bufnr, _ in pairs(client.attached_buffers) do
-- Call your custom on_attach logic...
-- my_on_attach(client, bufnr)
end
return result
end
end)(vim.lsp.handlers['client/registerCapability'])
LspDetach *LspDetach*
Just before an LSP client detaches from a buffer. The |autocmd-pattern| is
the buffer name. The |event-data| (type: `vim.event.lspdetach.data`) has
the client ID.
Example: >lua
vim.api.nvim_create_autocmd('LspDetach', {
callback = function(ev)
-- Get the detaching client
local client = vim.lsp.get_client_by_id(ev.data.client_id)
-- Remove the autocommand to format the buffer on save, if it exists
if client:supports_method('textDocument/formatting') then
vim.api.nvim_clear_autocmds({
event = 'BufWritePre',
buffer = ev.buf,
})
end
end,
})
<
LspNotify *LspNotify*
This event is triggered after each successful notification sent to an
LSP server.
The |event-data| (type: `vim.event.lspnotify.data`) has the client_id, LSP
method, and parameters.
Example: >lua
vim.api.nvim_create_autocmd('LspNotify', {
callback = function(ev)
local bufnr = ev.buf
local client_id = ev.data.client_id
local method = ev.data.method
local params = ev.data.params
-- do something with the notification
if method == 'textDocument/...' then
update_buffer(bufnr)
end
end,
})
<
LspProgress *LspProgress*
Upon receipt of a progress notification from the server. Notifications can
be polled from a `progress` ring buffer of a |vim.lsp.Client| or use
|vim.lsp.status()| to get an aggregate message.
If the server sends a "work done progress", the `pattern` is set to `kind`
(one of `begin`, `report` or `end`).
The |event-data| (type: `vim.event.lspprogress.data`) has `client_id` and
`params` properties, where `params` is the request params sent by the
server (see `lsp.ProgressParams`).
Examples:
Redraw the statusline whenever an LSP progress message arrives: >vim
autocmd LspProgress * redrawstatus
<
Emit a |progress-message| on LSP progress events: >lua
vim.api.nvim_create_autocmd('LspProgress', { buffer = buf, callback = function(ev)
local value = ev.data.params.value
vim.api.nvim_echo({ { value.message or 'done' } }, false, {
id = 'lsp.' .. ev.data.params.token,
kind = 'progress',
source = 'vim.lsp',
title = value.title,
status = value.kind ~= 'end' and 'running' or 'success',
percent = value.percentage,
})
end,
})
<
See also: ~
• https://github.com/MicrosoftDocs/terminal/blob/main/TerminalDocs/tutorials/progress-bar-sequences.md
LspRequest *LspRequest*
For each request sent to an LSP server, this event is triggered for
every change to the request's status. The status can be one of
`pending`, `complete`, or `cancel` and is sent as the {type} on the
"data" table passed to the callback function.
It triggers when the initial request is sent ({type} == `pending`) and
when the LSP server responds ({type} == `complete`). If a cancellation
is requested using `client.cancel_request(request_id)`, then this event
will trigger with {type} == `cancel`.
The |event-data| (type: `vim.event.lsprequest.data`) has the client ID,
request ID, and request (described at |vim.lsp.Client|, {requests} field).
If the request type is `complete`, the request will be deleted from the
client's pending requests table after processing the event handlers.
Example: >lua
vim.api.nvim_create_autocmd('LspRequest', {
callback = function(ev)
local bufnr = ev.buf
local client_id = ev.data.client_id
local request_id = ev.data.request_id
local request = ev.data.request
if request.type == 'pending' then
-- do something with pending requests
track_pending(client_id, bufnr, request_id, request)
elseif request.type == 'cancel' then
-- do something with pending cancel requests
track_canceling(client_id, bufnr, request_id, request)
elseif request.type == 'complete' then
-- do something with finished requests. this pending
-- request entry is about to be removed since it is complete
track_finish(client_id, bufnr, request_id, request)
end
end,
})
<
LspTokenUpdate *LspTokenUpdate*
When a visible semantic token is sent or updated by the LSP server, or
when an existing token becomes visible for the first time. The
|autocmd-pattern| is the buffer name. The |event-data| (type:
`vim.event.lsptokenupdate.data`) has the client ID and token (see
|vim.lsp.semantic_tokens.get_at_pos()|).
Example: >lua
vim.api.nvim_create_autocmd('LspTokenUpdate', {
callback = function(ev)
local token = ev.data.token
if token.type == 'variable' and not token.modifiers.readonly then
vim.lsp.semantic_tokens.highlight_token(
token, ev.buf, ev.data.client_id, 'MyMutableVariableHighlight'
)
end
end,
})
<
Note: doing anything other than calling
|vim.lsp.semantic_tokens.highlight_token()| is considered experimental.
==============================================================================
Lua module: vim.lsp *lsp-core*
*vim.lsp.Config*
Extends: |vim.lsp.ClientConfig|
Fields: ~
• {cmd}? (`string[]|fun(dispatchers: vim.lsp.rpc.Dispatchers, config: vim.lsp.ClientConfig): vim.lsp.rpc.Client`)
See `cmd` in |vim.lsp.ClientConfig|. See also
`reuse_client` to dynamically decide (per-buffer)
when `cmd` should be re-invoked.
• {filetypes}? (`string[]`) Filetypes the client will attach to, or
`nil` for ALL filetypes. To match files by name,
pattern, or contents, you can define a custom
filetype using |vim.filetype.add()|: >lua
vim.filetype.add({
filename = {
['my_filename'] = 'my_filetype1',
},
pattern = {
['.*/etc/my_file_pattern/.*'] = 'my_filetype2',
},
})
vim.lsp.config('…', {
filetypes = { 'my_filetype1', 'my_filetype2' },
})
<
• {reuse_client}? (`fun(client: vim.lsp.Client, config: vim.lsp.ClientConfig): boolean`)
Predicate which decides if a client should be
re-used. Used on all running clients. The default
implementation re-uses a client if name and root_dir
matches.
• {root_dir}? (`string|fun(bufnr: integer, on_dir:fun(root_dir?:string))`)
*lsp-root_dir()* Decides the workspace root: the
directory where the LSP server will base its
workspaceFolders, rootUri, and rootPath on
initialization. The function form must call the
`on_dir` callback to provide the root dir, or LSP
will not be activated for the buffer. Thus a
`root_dir()` function can dynamically decide
per-buffer whether to activate (or skip) LSP. See
example at |vim.lsp.enable()|.
• {root_markers}? (`(string|string[])[]`) *lsp-root_markers*
Filename(s) (".git/", "package.json", …) used to
decide the workspace root. Unused if `root_dir` is
defined. The list order decides priority. To indicate
"equal priority", specify names in a nested list
`{ { 'a.txt', 'b.lua' }, ... }`.
• For each item, Nvim will search upwards (from the
buffer file) for that marker, or list of markers;
search stops at the first directory containing that
marker, and the directory is used as the root dir
(workspace folder).
• Example: Find the first ancestor directory
containing file or directory "stylua.toml"; if not
found, find the first ancestor containing ".git": >
root_markers = { 'stylua.toml', '.git' }
<
• Example: Find the first ancestor directory
containing EITHER "stylua.toml" or ".luarc.json";
if not found, find the first ancestor containing
".git": >
root_markers = { { 'stylua.toml', '.luarc.json' }, '.git' }
<
buf_attach_client({bufnr}, {client_id}) *vim.lsp.buf_attach_client()*
Implements the `textDocument/did…` notifications required to track a
buffer for any language server.
Without calling this, the server won't be notified of changes to a buffer.
Parameters: ~
• {bufnr} (`integer`) Buffer handle, or 0 for current
• {client_id} (`integer`) Client id
Return: ~
(`boolean`) success `true` if client was attached successfully;
`false` otherwise
buf_detach_client({bufnr}, {client_id}) *vim.lsp.buf_detach_client()*
Detaches client from the specified buffer. Note: While the server is
notified that the text document (buffer) was closed, it is still able to
send notifications should it ignore this notification.
Parameters: ~
• {bufnr} (`integer`) Buffer handle, or 0 for current
• {client_id} (`integer`) Client id
buf_is_attached({bufnr}, {client_id}) *vim.lsp.buf_is_attached()*
Checks if a buffer is attached for a particular client.
Parameters: ~
• {bufnr} (`integer`) Buffer handle, or 0 for current
• {client_id} (`integer`) the client id
buf_notify({bufnr}, {method}, {params}) *vim.lsp.buf_notify()*
Send a notification to a server
Attributes: ~
Since: 0.5.0
Parameters: ~
• {bufnr} (`integer?`) The number of the buffer
• {method} (`string`) Name of the request method
• {params} (`any`) Arguments to send to the server
Return: ~
(`boolean`) success true if any client returns true; false otherwise
*vim.lsp.buf_request_all()*
buf_request_all({bufnr}, {method}, {params}, {handler})
Sends an async request for all active clients attached to the buffer and
executes the `handler` callback with the combined result.
Attributes: ~
Since: 0.5.0
Parameters: ~
• {bufnr} (`integer`) Buffer handle, or 0 for current.
• {method} (`string`) LSP method name
• {params} (`table|(fun(client: vim.lsp.Client, bufnr: integer): table?)?`)
Parameters to send to the server. Can also be passed as a
function that returns the params table for cases where
parameters are specific to the client.
• {handler} (`function`) Handler called after all requests are
completed. Server results are passed as a
`client_id:result` map.