summaryrefslogtreecommitdiffstats
path: root/runtime/doc/channel.txt
blob: f2946795514d8119c79a3427461aaf445594e834 (plain)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
*channel.txt*      For Vim version 9.1.  Last change: 2024 Jun 13


		  VIM REFERENCE MANUAL	  by Bram Moolenaar


		      Inter-process communication		*channel*

Vim uses channels to communicate with other processes.
A channel uses a socket or pipes.			*socket-interface*
Jobs can be used to start processes and communicate with them.
The Netbeans interface also uses a channel. |netbeans|

1. Overview				|job-channel-overview|
2. Channel demo				|channel-demo|
3. Opening a channel			|channel-open|
4. Using a JSON or JS channel		|channel-use|
5. Channel commands			|channel-commands|
6. Using a RAW or NL channel		|channel-raw|
7. More channel functions		|channel-more|
8. Channel functions details		|channel-functions-details|
9. Starting a job with a channel	|job-start|
10. Starting a job without a channel	|job-start-nochannel|
11. Job functions			|job-functions-details|
12. Job options				|job-options|
13. Controlling a job			|job-control|
14. Using a prompt buffer		|prompt-buffer|
15. Language Server Protocol		|language-server-protocol|

							*E1277*
{only when compiled with the |+channel| feature for channel stuff}
	You can check this with: `has('channel')`
{only when compiled with the |+job| feature for job stuff}
	You can check this with: `has('job')`

==============================================================================
1. Overview						*job-channel-overview*

There are four main types of jobs:
1. A daemon, serving several Vim instances.
   Vim connects to it with a socket.
2. One job working with one Vim instance, asynchronously.
   Uses a socket or pipes.
3. A job performing some work for a short time, asynchronously.
   Uses a socket or pipes.
4. Running a filter, synchronously.
   Uses pipes.

For when using sockets See |job-start|, |job-start-nochannel| and
|channel-open|.  For 2 and 3, one or more jobs using pipes, see |job-start|.
For 4 use the ":{range}!cmd" command, see |filter|.

Over the socket and pipes these protocols are available:
RAW	nothing known, Vim cannot tell where a message ends
NL	every message ends in a NL (newline) character
JSON	JSON encoding |json_encode()|
JS	JavaScript style JSON-like encoding |js_encode()|
LSP	Language Server Protocol encoding |language-server-protocol|

Common combination are:
- Using a job connected through pipes in NL mode.  E.g., to run a style
  checker and receive errors and warnings.
- Using a daemon, connecting over a socket in JSON mode.  E.g. to lookup
  cross-references in a database.

==============================================================================
2. Channel demo				*channel-demo* *demoserver.py*

This requires Python.  The demo program can be found in
$VIMRUNTIME/tools/demoserver.py
Run it in one terminal.  We will call this T1.

Run Vim in another terminal.  Connect to the demo server with: >
	let channel = ch_open('localhost:8765')

In T1 you should see:
	=== socket opened === ~

You can now send a message to the server: >
	echo ch_evalexpr(channel, 'hello!')

The message is received in T1 and a response is sent back to Vim.
You can see the raw messages in T1.  What Vim sends is:
	[1,"hello!"] ~
And the response is:
	[1,"got it"] ~
The number will increase every time you send a message.

The server can send a command to Vim.  Type this on T1 (literally, including
the quotes):
	["ex","echo 'hi there'"] ~
And you should see the message in Vim. You can move the cursor a word forward:
	["normal","w"] ~

To handle asynchronous communication a callback needs to be used: >
	func MyHandler(channel, msg)
	  echo "from the handler: " .. a:msg
	endfunc
	call ch_sendexpr(channel, 'hello!', {'callback': "MyHandler"})
Vim will not wait for a response.  Now the server can send the response later
and MyHandler will be invoked.

Instead of giving a callback with every send call, it can also be specified
when opening the channel: >
	call ch_close(channel)
	let channel = ch_open('localhost:8765', {'callback': "MyHandler"})
	call ch_sendexpr(channel, 'hello channel!')

When trying out channels it's useful to see what is going on.  You can tell
Vim to write lines in log file: >
	call ch_logfile('channellog', 'w')
See |ch_logfile()|.

==============================================================================
3. Opening a channel					*channel-open*

To open a channel: >
    let channel = ch_open({address} [, {options}])
    if ch_status(channel) == "open"
      " use the channel

Use |ch_status()| to see if the channel could be opened.

					*channel-address*
{address} can be a domain name or an IP address, followed by a port number, or
a Unix-domain socket path prefixed by "unix:".  E.g. >
    www.example.com:80   " domain + port
    127.0.0.1:1234       " IPv4 + port
    [2001:db8::1]:8765   " IPv6 + port
    unix:/tmp/my-socket  " Unix-domain socket path

{options} is a dictionary with optional entries:	*channel-open-options*

"mode" can be:						*channel-mode*
	"json" - Use JSON, see below; most convenient way. Default.
	"js"   - Use JS (JavaScript) encoding, more efficient than JSON.
	"nl"   - Use messages that end in a NL character
	"raw"  - Use raw messages
	"lsp"  - Use language server protocol encoding
						*channel-callback* *E921*
"callback"	A function that is called when a message is received that is
		not handled otherwise (e.g. a JSON message with ID zero).  It
		gets two arguments: the channel and the received message.
		Example: >
	func Handle(channel, msg)
	  echo 'Received: ' .. a:msg
	endfunc
	let channel = ch_open("localhost:8765", {"callback": "Handle"})
<
		When "mode" is "json" or "js" or "lsp" the "msg" argument is
		the body of the received message, converted to Vim types.
		When "mode" is "nl" the "msg" argument is one message,
		excluding the NL.
		When "mode" is "raw" the "msg" argument is the whole message
		as a string.

		For all callbacks: Use |function()| to bind it to arguments
		and/or a Dictionary.  Or use the form "dict.function" to bind
		the Dictionary.

		Callbacks are only called at a "safe" moment, usually when Vim
		is waiting for the user to type a character.  Vim does not use
		multi-threading.

							*close_cb*
"close_cb"	A function that is called when the channel gets closed, other
		than by calling ch_close().  It should be defined like this: >
	func MyCloseHandler(channel)
<		Vim will invoke callbacks that handle data before invoking
		close_cb, thus when this function is called no more data will
		be passed to the callbacks.  However, if a callback causes Vim
		to check for messages, the close_cb may be invoked while still
		in the callback.  The plugin must handle this somehow, it can
		be useful to know that no more data is coming.
		If it is not known if there is a message to be read, use a
		try/catch block: >
			try
			  let msg = ch_readraw(a:channel)
			catch
			  let msg = 'no message'
			endtry
			try
			  let err = ch_readraw(a:channel, #{part: 'err'})
			catch
			  let err = 'no error'
			endtry
<							*channel-drop*
"drop"		Specifies when to drop messages:
		    "auto"	When there is no callback to handle a message.
				The "close_cb" is also considered for this.
		    "never"	All messages will be kept.

							*channel-noblock*
"noblock"	Same effect as |job-noblock|.  Only matters for writing.

							*waittime*
"waittime"	The time to wait for the connection to be made in
		milliseconds.  A negative number waits forever.

		The default is zero, don't wait, which is useful if a local
		server is supposed to be running already.  On Unix Vim
		actually uses a 1 msec timeout, that is required on many
		systems.  Use a larger value for a remote server, e.g.  10
		msec at least.
							*channel-timeout*
"timeout"	The time to wait for a request when blocking, E.g. when using
		ch_evalexpr().  In milliseconds.  The default is 2000 (2
		seconds).

When "mode" is "json" or "js" the "callback" is optional.  When omitted it is
only possible to receive a message after sending one.

To change the channel options after opening it use |ch_setoptions()|.  The
arguments are similar to what is passed to |ch_open()|, but "waittime" cannot
be given, since that only applies to opening the channel.

For example, the handler can be added or changed: >
    call ch_setoptions(channel, {'callback': callback})
When "callback" is empty (zero or an empty string) the handler is removed.

After a callback has been invoked Vim will update the screen and put the
cursor back where it belongs.  Thus the callback should not need to do
`:redraw`.

The timeout can be changed: >
    call ch_setoptions(channel, {'timeout': msec})
<
							  *channel-close* *E906*
Once done with the channel, disconnect it like this: >
    call ch_close(channel)
When a socket is used this will close the socket for both directions.  When
pipes are used (stdin/stdout/stderr) they are all closed.  This might not be
what you want!  Stopping the job with job_stop() might be better.
All readahead is discarded, callbacks will no longer be invoked.

Note that a channel is closed in three stages:
  - The I/O ends, log message: "Closing channel". There can still be queued
    messages to read or callbacks to invoke.
  - The readahead is cleared, log message: "Clearing channel".  Some variables
    may still reference the channel.
  - The channel is freed, log message: "Freeing channel".

When the channel can't be opened you will get an error message.  There is a
difference between MS-Windows and Unix: On Unix when the port doesn't exist
ch_open() fails quickly.  On MS-Windows "waittime" applies.
*E898* *E901* *E902*

If there is an error reading or writing a channel it will be closed.
*E630* *E631*

==============================================================================
4. Using a JSON or JS channel					*channel-use*

If mode is JSON then a message can be sent synchronously like this: >
    let response = ch_evalexpr(channel, {expr})
This awaits a response from the other side.

When mode is JS this works the same, except that the messages use
JavaScript encoding.  See |js_encode()| for the difference.

To send a message, without handling a response or letting the channel callback
handle the response: >
    call ch_sendexpr(channel, {expr})

To send a message and letting the response handled by a specific function,
asynchronously: >
    call ch_sendexpr(channel, {expr}, {'callback': Handler})

Vim will match the response with the request using the message ID.  Once the
response is received the callback will be invoked.  Further responses with the
same ID will be ignored.  If your server sends back multiple responses you
need to send them with ID zero, they will be passed to the channel callback.

The {expr} is converted to JSON and wrapped in an array.  An example of the
message that the receiver will get when {expr} is the string "hello":
	[12,"hello"] ~

The format of the JSON sent is:
    [{number},{expr}]

In which {number} is different every time.  It must be used in the response
(if any):

    [{number},{response}]

This way Vim knows which sent message matches with which received message and
can call the right handler.  Also when the messages arrive out of order.

A newline character is terminating the JSON text.  This can be used to
separate the read text.  For example, in Python:
	splitidx = read_text.find('\n')
	message = read_text[:splitidx]
	rest = read_text[splitidx + 1:]

The sender must always send valid JSON to Vim.  Vim can check for the end of
the message by parsing the JSON.  It will only accept the message if the end
was received.  A newline after the message is optional.

When the process wants to send a message to Vim without first receiving a
message, it must use the number zero:
    [0,{response}]

Then channel handler will then get {response} converted to Vim types.  If the
channel does not have a handler the message is dropped.

It is also possible to use ch_sendraw() and ch_evalraw() on a JSON or JS
channel.  The caller is then completely responsible for correct encoding and
decoding.

==============================================================================
5. Channel commands					*channel-commands*

With a JSON channel the process can send commands to Vim that will be
handled by Vim internally, it does not require a handler for the channel.

Possible commands are:				*E903* *E904* *E905*
    ["redraw", {forced}]
    ["ex",     {Ex command}]
    ["normal", {Normal mode command}]
    ["expr",   {expression}, {number}]
    ["expr",   {expression}]
    ["call",   {func name}, {argument list}, {number}]
    ["call",   {func name}, {argument list}]

With all of these: Be careful what these commands do!  You can easily
interfere with what the user is doing.  To avoid trouble use |mode()| to check
that the editor is in the expected state.  E.g., to send keys that must be
inserted as text, not executed as a command:
    ["ex","if mode() == 'i' | call feedkeys('ClassName') | endif"] ~

Errors in these commands are normally not reported to avoid them messing up
the display.  If you do want to see them, set the 'verbose' option to 3 or
higher.


Command "redraw" ~

The other commands do not explicitly update the screen, so that you can send a
sequence of commands without the cursor moving around.  A redraw can happen as
a side effect of some commands.  You must end with the "redraw" command to
show any changed text and show the cursor where it belongs.

The argument is normally an empty string:
	["redraw", ""] ~
To first clear the screen pass "force":
	["redraw", "force"] ~


Command "ex" ~

The "ex" command is executed as any Ex command.  There is no response for
completion or error.  You could use functions in an |autoload| script:
	["ex","call myscript#MyFunc(arg)"]

You can also use "call |feedkeys()|" to insert any key sequence.

When there is an error a message is written to the channel log, if it exists,
and v:errmsg is set to the error.


Command "normal" ~

The "normal" command is executed like with ":normal!", commands are not
mapped.  Example to open the folds under the cursor:
	["normal" "zO"]


Command "expr"  with response ~

The "expr" command can be used to get the result of an expression.  For
example, to get the number of lines in the current buffer:
	["expr","line('$')", -2] ~

It will send back the result of the expression:
	[-2, "last line"] ~
The format is:
	[{number}, {result}]

Here {number} is the same as what was in the request.  Use a negative number
to avoid confusion with message that Vim sends.  Use a different number on
every request to be able to match the request with the response.

{result} is the result of the evaluation and is JSON encoded.  If the
evaluation fails or the result can't be encoded in JSON it is the string
"ERROR".


Command "expr" without a response ~

This command is similar to "expr" above, but does not send back any response.
Example:
	["expr","setline('$', ['one', 'two', 'three'])"] ~
There is no third argument in the request.


Command "call" ~

This is similar to "expr", but instead of passing the whole expression as a
string this passes the name of a function and a list of arguments.  This
avoids the conversion of the arguments to a string and escaping and
concatenating them.  Example:
	["call", "line", ["$"], -2] ~

Leave out the fourth argument if no response is to be sent:
	["call", "setline", ["$", ["one", "two", "three"]]] ~

==============================================================================
6. Using a RAW or NL channel				*channel-raw*

If mode is RAW or NL then a message can be sent like this: >
    let response = ch_evalraw(channel, {string})

The {string} is sent as-is.  The response will be what can be read from the
channel right away.  Since Vim doesn't know how to recognize the end of the
message you need to take care of it yourself.  The timeout applies for reading
the first byte, after that it will not wait for anything more.

If mode is "nl" you can send a message in a similar way.  You are expected
to put in the NL after each message.  Thus you can also send several messages
ending in a NL at once.  The response will be the text up to and including the
first NL.  This can also be just the NL for an empty response.
If no NL was read before the channel timeout an empty string is returned.

To send a message, without expecting a response: >
    call ch_sendraw(channel, {string})
The process can send back a response, the channel handler will be called with
it.

						*channel-onetime-callback*
To send a message and letting the response handled by a specific function,
asynchronously: >
    call ch_sendraw(channel, {string}, {'callback': 'MyHandler'})

This {string} can also be JSON, use |json_encode()| to create it and
|json_decode()| to handle a received JSON message.

It is not possible to use |ch_evalexpr()| or |ch_sendexpr()| on a raw channel.

A String in Vim cannot contain NUL bytes.  To send or receive NUL bytes read
or write from a buffer.  See |in_io-buffer| and |out_io-buffer|.

==============================================================================
7. More channel functions				*channel-more*

To obtain the status of a channel: ch_status(channel).  The possible results
are:
	"fail"		Failed to open the channel.
	"open"		The channel can be used.
	"buffered"	The channel was closed but there is data to read.
	"closed"	The channel was closed.

To obtain the job associated with a channel: ch_getjob(channel)

To read one message from a channel: >
	let output = ch_read(channel)
This uses the channel timeout.  To read without a timeout, just get any
message that is available: >
	let output = ch_read(channel, {'timeout': 0})
When no message was available then the result is v:none for a JSON or JS mode
channels, an empty string for a RAW or NL channel.  You can use |ch_canread()|
to check if there is something to read.

Note that when there is no callback, messages are dropped.  To avoid that add
a close callback to the channel.

To read all normal output from a RAW channel that is available: >
	let output = ch_readraw(channel)
To read all error output from a RAW channel that is available: >
	let output = ch_readraw(channel, {"part": "err"})
Note that if the channel is in NL mode, ch_readraw() will only return one line
for each call.

ch_read() and ch_readraw() use the channel timeout.  When there is nothing to
read within that time an empty string is returned.  To specify a different
timeout in msec use the "timeout" option:
	{"timeout": 123} ~
To read from the error output use the "part" option:
	{"part": "err"} ~
To read a message with a specific ID, on a JS or JSON channel:
	{"id": 99} ~
When no ID is specified or the ID is -1, the first message is returned. This
overrules any callback waiting for this message.

For a RAW channel this returns whatever is available, since Vim does not know
where a message ends.
For a NL channel this returns one message.
For a JS or JSON channel this returns one decoded message.
This includes any sequence number.

==============================================================================
8. Channel functions details			*channel-functions-details*

ch_canread({handle})						*ch_canread()*
		Return non-zero when there is something to read from {handle}.
		{handle} can be a Channel or a Job that has a Channel.

		This is useful to read from a channel at a convenient time,
		e.g. from a timer.

		Note that messages are dropped when the channel does not have
		a callback.  Add a close callback to avoid that.

		Can also be used as a |method|: >
			GetChannel()->ch_canread()
<
		Return type: |Number|

ch_close({handle})						*ch_close()*
		Close {handle}.  See |channel-close|.
		{handle} can be a Channel or a Job that has a Channel.
		A close callback is not invoked.

		Can also be used as a |method|: >
			GetChannel()->ch_close()
<
		Return type: |Number|

ch_close_in({handle})						*ch_close_in()*
		Close the "in" part of {handle}.  See |channel-close-in|.
		{handle} can be a Channel or a Job that has a Channel.
		A close callback is not invoked.

		Can also be used as a |method|: >
			GetChannel()->ch_close_in()
<
		Return type: |Number|


ch_evalexpr({handle}, {expr} [, {options}])			*ch_evalexpr()*
		Send {expr} over {handle}.  The {expr} is encoded
		according to the type of channel.  The function cannot be used
		with a raw channel.  See |channel-use|.
		{handle} can be a Channel or a Job that has a Channel.
		When using the "lsp" channel mode, {expr} must be a |Dict|.
								*E917*
		{options} must be a Dictionary.  It must not have a "callback"
		entry.  It can have a "timeout" entry to specify the timeout
		for this specific request.

		ch_evalexpr() waits for a response and returns the decoded
		expression.  When there is an error or timeout it returns an
		empty |String| or, when using the "lsp" channel mode, returns an
		empty |Dict|.

		Note that while waiting for the response, Vim handles other
		messages.  You need to make sure this doesn't cause trouble.

		Can also be used as a |method|: >
			GetChannel()->ch_evalexpr(expr)
<
		Return type: dict<any> or |String|


ch_evalraw({handle}, {string} [, {options}])		*ch_evalraw()*
		Send {string} over {handle}.
		{handle} can be a Channel or a Job that has a Channel.

		Works like |ch_evalexpr()|, but does not encode the request or
		decode the response.  The caller is responsible for the
		correct contents.  Also does not add a newline for a channel
		in NL mode, the caller must do that.  The NL in the response
		is removed.
		Note that Vim does not know when the text received on a raw
		channel is complete, it may only return the first part and you
		need to use |ch_readraw()| to fetch the rest.
		See |channel-use|.

		Can also be used as a |method|: >
			GetChannel()->ch_evalraw(rawstring)
<
		Return type: dict<any> or |String|

ch_getbufnr({handle}, {what})				 *ch_getbufnr()*
		Get the buffer number that {handle} is using for String {what}.
		{handle} can be a Channel or a Job that has a Channel.
		{what} can be "err" for stderr, "out" for stdout or empty for
		socket output.
		Returns -1 when there is no buffer.

		Can also be used as a |method|: >
			GetChannel()->ch_getbufnr(what)
<
		Return type: |Number|

ch_getjob({channel})						*ch_getjob()*
		Get the Job associated with {channel}.
		If there is no job calling |job_status()| on the returned Job
		will result in "fail".

		Can also be used as a |method|: >
			GetChannel()->ch_getjob()
<
		Return type: |job| or |String|

ch_info({handle})						*ch_info()*
		Returns a Dictionary with information about {handle}.  The
		items are:
		   "id"		  number of the channel
		   "status"	  "open", "buffered" or "closed", like
				  ch_status()
		When opened with ch_open():
		   "hostname"	  the hostname of the address
		   "port"	  the port of the address
		   "path"	  the path of the Unix-domain socket
		   "sock_status"  "open" or "closed"
		   "sock_mode"	  "NL", "RAW", "JSON" or "JS"
		   "sock_io"	  "socket"
		   "sock_timeout" timeout in msec

		Note that "path" is only present for Unix-domain sockets, for
		regular ones "hostname" and "port" are present instead.

		When opened with job_start():
		   "out_status"	  "open", "buffered" or "closed"
		   "out_mode"	  "NL", "RAW", "JSON" or "JS"
		   "out_io"	  "null", "pipe", "file" or "buffer"
		   "out_timeout"  timeout in msec
		   "err_status"	  "open", "buffered" or "closed"
		   "err_mode"	  "NL", "RAW", "JSON" or "JS"
		   "err_io"	  "out", "null", "pipe", "file" or "buffer"
		   "err_timeout"  timeout in msec
		   "in_status"	  "open" or "closed"
		   "in_mode"	  "NL", "RAW", "JSON", "JS" or "LSP"
		   "in_io"	  "null", "pipe", "file" or "buffer"
		   "in_timeout"	  timeout in msec

		Can also be used as a |method|: >
			GetChannel()->ch_info()
<
		Return type: dict<any>

ch_log({msg} [, {handle}])					*ch_log()*
		Write String {msg} in the channel log file, if it was opened
		with |ch_logfile()|.
		The text "ch_log():" is prepended to the message to make clear
		it came from this function call and make it easier to find in
		the log file.
		When {handle} is passed the channel number is used for the
		message.
		{handle} can be a Channel or a Job that has a Channel.  The
		Channel must be open for the channel number to be used.

		Can also be used as a |method|: >
			'did something'->ch_log()
<
		Return type: dict<any>

ch_logfile({fname} [, {mode}])					*ch_logfile()*
		Start logging channel activity to {fname}.
		When {fname} is an empty string: stop logging.

		When {mode} is omitted or contains "a" or is "o" then append
		to the file.
		When {mode} contains "w" and not "a" start with an empty file.
		When {mode} contains "o" then log all terminal output.
		Otherwise only some interesting terminal output is logged.

		Use |ch_log()| to write log messages.  The file is flushed
		after every message, on Unix you can use "tail -f" to see what
		is going on in real time.

		To enable the log very early, to see what is received from a
		terminal during startup, use |--log| (this uses mode "ao"): >
			vim --log logfile
<
		This function is not available in the |sandbox|.
		NOTE: the channel communication is stored in the file, be
		aware that this may contain confidential and privacy sensitive
		information, e.g. a password you type in a terminal window.

		Can also be used as a |method|: >
			'logfile'->ch_logfile('w')
<
		Return type: |Number|

ch_open({address} [, {options}])				*ch_open()*
		Open a channel to {address}.  See |channel|.
		Returns a Channel.  Use |ch_status()| to check for failure.

		{address} is a String, see |channel-address| for the possible
		accepted forms.

		If {options} is given it must be a |Dictionary|.
		See |channel-open-options|.

		Can also be used as a |method|: >
			GetAddress()->ch_open()
<
		Return type: |channel|

ch_read({handle} [, {options}])					*ch_read()*
		Read from {handle} and return the received message.
		{handle} can be a Channel or a Job that has a Channel.
		For a NL channel this waits for a NL to arrive, except when
		there is nothing more to read (channel was closed).
		See |channel-more|.

		Can also be used as a |method|: >
			GetChannel()->ch_read()
<
		Return type: |String|

ch_readblob({handle} [, {options}])			*ch_readblob()*
		Like ch_read() but reads binary data and returns a |Blob|.
		See |channel-more|.

		Can also be used as a |method|: >
			GetChannel()->ch_readblob()
<
		Return type: |Blob|

ch_readraw({handle} [, {options}])			*ch_readraw()*
		Like ch_read() but for a JS and JSON channel does not decode
		the message.  For a NL channel it does not block waiting for
		the NL to arrive, but otherwise works like ch_read().
		See |channel-more|.

		Can also be used as a |method|: >
			GetChannel()->ch_readraw()
<
		Return type: |String|

ch_sendexpr({handle}, {expr} [, {options}])			*ch_sendexpr()*
		Send {expr} over {handle}.  The {expr} is encoded
		according to the type of channel.  The function cannot be used
		with a raw channel.
		See |channel-use|.				*E912*
		{handle} can be a Channel or a Job that has a Channel.
		When using the "lsp" channel mode, {expr} must be a |Dict|.

		If the channel mode is "lsp", then returns a Dict. Otherwise
		returns an empty String.  If the "callback" item is present in
		{options}, then the returned Dict contains the ID of the
		request message.  The ID can be used to send a cancellation
		request to the LSP server (if needed).  Returns an empty Dict
		on error.

		If a response message is not expected for {expr}, then don't
		specify the "callback" item in {options}.

		Can also be used as a |method|: >
			GetChannel()->ch_sendexpr(expr)
<
		Return type: dict<any> or |String|


ch_sendraw({handle}, {expr} [, {options}])		*ch_sendraw()*
		Send |String| or |Blob| {expr} over {handle}.
		Works like |ch_sendexpr()|, but does not encode the request or
		decode the response.  The caller is responsible for the
		correct contents.  Also does not add a newline for a channel
		in NL mode, the caller must do that.  The NL in the response
		is removed.
		See |channel-use|.

		Can also be used as a |method|: >
			GetChannel()->ch_sendraw(rawexpr)
<
		Return type: dict<any> or |String|

ch_setoptions({handle}, {options})			*ch_setoptions()*
		Set options on {handle}:
			"callback"	the channel callback
			"timeout"	default read timeout in msec
			"mode"		mode for the whole channel
		See |ch_open()| for more explanation.
		{handle} can be a Channel or a Job that has a Channel.

		Note that changing the mode may cause queued messages to be
		lost.

		These options cannot be changed:
			"waittime"	only applies to |ch_open()|

		Can also be used as a |method|: >
			GetChannel()->ch_setoptions(options)
<
		Return type: |Number|

ch_status({handle} [, {options}])				*ch_status()*
		Return the status of {handle}:
			"fail"		failed to open the channel
			"open"		channel can be used
			"buffered"	channel can be read, not written to
			"closed"	channel can not be used
		{handle} can be a Channel or a Job that has a Channel.
		"buffered" is used when the channel was closed but there is
		still data that can be obtained with |ch_read()|.

		If {options} is given it can contain a "part" entry to specify
		the part of the channel to return the status for: "out" or
		"err".  For example, to get the error status: >
			ch_status(job, {"part": "err"})
<
		Can also be used as a |method|: >
			GetChannel()->ch_status()
<
		Return type: |String|

==============================================================================
9. Starting a job with a channel			*job-start* *job*

To start a job and open a channel for stdin/stdout/stderr: >
    let job = job_start(command, {options})

You can get the channel with: >
    let channel = job_getchannel(job)

The channel will use NL mode.  If you want another mode it's best to specify
this in {options}.  When changing the mode later some text may have already
been received and not parsed correctly.

If the command produces a line of output that you want to deal with, specify
a handler for stdout: >
    let job = job_start(command, {"out_cb": "MyHandler"})
The function will be called with the channel and a message. You would define
it like this: >
    func MyHandler(channel, msg)

Without the handler you need to read the output with |ch_read()| or
|ch_readraw()|. You can do this in the close callback, see |read-in-close-cb|.

Note that if the job exits before you read the output, the output may be lost.
This depends on the system (on Unix this happens because closing the write end
of a pipe causes the read end to get EOF).  To avoid this make the job sleep
for a short while before it exits.

The handler defined for "out_cb" will not receive stderr.  If you want to
handle that separately, add an "err_cb" handler: >
    let job = job_start(command, {"out_cb": "MyHandler",
	    \			  "err_cb": "ErrHandler"})

If you want to handle both stderr and stdout with one handler use the
"callback" option: >
    let job = job_start(command, {"callback": "MyHandler"})

Depending on the system, starting a job can put Vim in the background, the
started job gets the focus.  To avoid that, use the `foreground()` function.
This might not always work when called early, put in the callback handler or
use a timer to call it after the job has started.

You can send a message to the command with ch_evalraw().  If the channel is in
JSON or JS mode you can use ch_evalexpr().

There are several options you can use, see |job-options|.
For example, to start a job and write its output in buffer "dummy": >
	let logjob = job_start("tail -f /tmp/log",
			     \ {'out_io': 'buffer', 'out_name': 'dummy'})
	sbuf dummy


Job input from a buffer ~
							*in_io-buffer*
To run a job that reads from a buffer: >
	let job = job_start({command},
	    \ {'in_io': 'buffer', 'in_name': 'mybuffer'})
<
							*E915* *E918*
The buffer is found by name, similar to |bufnr()|. The buffer must exist and
be loaded when job_start() is called.

By default this reads the whole buffer.  This can be changed with the "in_top"
and "in_bot" options.

A special mode is when "in_top" is set to zero and "in_bot" is not set: Every
time a line is added to the buffer, the last-but-one line will be sent to the
job stdin.  This allows for editing the last line and sending it when pressing
Enter.
							*channel-close-in*
When not using the special mode the pipe or socket will be closed after the
last line has been written.  This signals the reading end that the input
finished.  You can also use |ch_close_in()| to close it sooner.

NUL bytes in the text will be passed to the job (internally Vim stores these
as NL bytes).


Reading job output in the close callback ~
							*read-in-close-cb*
If the job can take some time and you don't need intermediate results, you can
add a close callback and read the output there: >

	func! CloseHandler(channel)
	  while ch_status(a:channel, {'part': 'out'}) == 'buffered'
	    echomsg ch_read(a:channel)
	  endwhile
	endfunc
	let job = job_start(command, {'close_cb': 'CloseHandler'})

You will want to do something more useful than "echomsg".

==============================================================================
10. Starting a job without a channel			*job-start-nochannel*

To start another process without creating a channel: >
    let job = job_start(command,
	\ {"in_io": "null", "out_io": "null", "err_io": "null"})

This starts {command} in the background, Vim does not wait for it to finish.

When Vim sees that neither stdin, stdout or stderr are connected, no channel
will be created.  Often you will want to include redirection in the command to
avoid it getting stuck.

There are several options you can use, see |job-options|.

							*job-start-if-needed*
To start a job only when connecting to an address does not work, do something
like this: >
	let channel = ch_open(address, {"waittime": 0})
	if ch_status(channel) == "fail"
	  let job = job_start(command)
	  let channel = ch_open(address, {"waittime": 1000})
	endif

Note that the waittime for ch_open() gives the job one second to make the port
available.

==============================================================================
11. Job functions					*job-functions-details*

job_getchannel({job})					 *job_getchannel()*
		Get the channel handle that {job} is using.
		To check if the job has no channel: >
			if string(job_getchannel(job)) == 'channel fail'
<
		Can also be used as a |method|: >
			GetJob()->job_getchannel()
<
		Return type: |channel|

job_info([{job}])					*job_info()*
		Returns a Dictionary with information about {job}:
		   "status"	what |job_status()| returns
		   "channel"	what |job_getchannel()| returns
		   "cmd"	List of command arguments used to start the job
		   "process"	process ID
		   "tty_in"	terminal input name, empty when none
		   "tty_out"	terminal output name, empty when none
		   "exitval"	only valid when "status" is "dead"
		   "exit_cb"	function to be called on exit
		   "stoponexit"	|job-stoponexit|

		   Only in Unix:
		   "termsig"	the signal which terminated the process
				(See |job_stop()| for the values)
				only valid when "status" is "dead"

		   Only in MS-Windows:
		   "tty_type"	Type of virtual console in use.
				Values are "winpty" or "conpty".
				See 'termwintype'.

		Without any arguments, returns a List with all Job objects.

		Can also be used as a |method|: >
			GetJob()->job_info()
<
		Return type: dict<any> or list<job> depending on whether {job}
		was given


job_setoptions({job}, {options})			*job_setoptions()*
		Change options for {job}.  Supported are:
		   "stoponexit"	|job-stoponexit|
		   "exit_cb"	|job-exit_cb|

		Can also be used as a |method|: >
			GetJob()->job_setoptions(options)
<
		Return type: |Number|


job_start({command} [, {options}])			*job_start()*
		Start a job and return a Job object.  Unlike |system()| and
		|:!cmd| this does not wait for the job to finish.
		To start a job in a terminal window see |term_start()|.

		If the job fails to start then |job_status()| on the returned
		Job object results in "fail" and none of the callbacks will be
		invoked.

		{command} can be a String.  This works best on MS-Windows.  On
		Unix it is split up in white-separated parts to be passed to
		execvp().  Arguments in double quotes can contain white space.

		{command} can be a List, where the first item is the executable
		and further items are the arguments.  All items are converted
		to String.  This works best on Unix.

		On MS-Windows, job_start() makes a GUI application hidden. If
		you want to show it, use |:!start| instead.

		The command is executed directly, not through a shell, the
		'shell' option is not used.  To use the shell: >
	let job = job_start(["/bin/sh", "-c", "echo hello"])
<		Or: >
	let job = job_start('/bin/sh -c "echo hello"')
<		Note that this will start two processes, the shell and the
		command it executes.  If you don't want this use the "exec"
		shell command.

		On Unix $PATH is used to search for the executable only when
		the command does not contain a slash.

		The job will use the same terminal as Vim.  If it reads from
		stdin the job and Vim will be fighting over input, that
		doesn't work.  Redirect stdin and stdout to avoid problems: >
	let job = job_start(['sh', '-c', "myserver </dev/null >/dev/null"])
<
		The returned Job object can be used to get the status with
		|job_status()| and stop the job with |job_stop()|.

		Note that the job object will be deleted if there are no
		references to it.  This closes the stdin and stderr, which may
		cause the job to fail with an error.  To avoid this keep a
		reference to the job.  Thus instead of: >
	call job_start('my-command')
<		use: >
	let myjob = job_start('my-command')
<		and unlet "myjob" once the job is not needed or is past the
		point where it would fail (e.g. when it prints a message on
		startup).  Keep in mind that variables local to a function
		will cease to exist if the function returns.  Use a
		script-local variable if needed: >
	let s:myjob = job_start('my-command')
<
		{options} must be a Dictionary.  It can contain many optional
		items, see |job-options|.

		Can also be used as a |method|: >
			BuildCommand()->job_start()
<
		Return type: |job|


job_status({job})					*job_status()* *E916*
		Returns a String with the status of {job}:
			"run"	job is running
			"fail"	job failed to start
			"dead"	job died or was stopped after running

		On Unix a non-existing command results in "dead" instead of
		"fail", because a fork happens before the failure can be
		detected.

		If in Vim9 script a variable is declared with type "job" but
		never assigned to, passing that variable to job_status()
		returns "fail".

		If an exit callback was set with the "exit_cb" option and the
		job is now detected to be "dead" the callback will be invoked.

		For more information see |job_info()|.

		Can also be used as a |method|: >
			GetJob()->job_status()
<
		Return type: |String|


job_stop({job} [, {how}])					*job_stop()*
		Stop the {job}.  This can also be used to signal the job.

		When {how} is omitted or is "term" the job will be terminated.
		For Unix SIGTERM is sent.  On MS-Windows the job will be
		terminated forcedly (there is no "gentle" way).
		This goes to the process group, thus children may also be
		affected.

		Effect for Unix:
			"term"	 SIGTERM (default)
			"hup"	 SIGHUP
			"quit"	 SIGQUIT
			"int"	 SIGINT
			"kill"	 SIGKILL (strongest way to stop)
			number	 signal with that number

		Effect for MS-Windows:
			"term"	 terminate process forcedly (default)
			"hup"	 CTRL_BREAK
			"quit"	 CTRL_BREAK
			"int"	 CTRL_C
			"kill"	 terminate process forcedly
			Others	 CTRL_BREAK

		On Unix the signal is sent to the process group.  This means
		that when the job is "sh -c command" it affects both the shell
		and the command.

		The result is a Number: 1 if the operation could be executed,
		0 if "how" is not supported on the system.
		Note that even when the operation was executed, whether the
		job was actually stopped needs to be checked with
		|job_status()|.

		If the status of the job is "dead", the signal will not be
		sent.  This is to avoid to stop the wrong job (esp. on Unix,
		where process numbers are recycled).

		When using "kill" Vim will assume the job will die and close
		the channel.

		Can also be used as a |method|: >
			GetJob()->job_stop()
<
		Return type: |Number|


==============================================================================
12. Job options						*job-options*

The {options} argument in job_start() is a dictionary.  All entries are
optional.  Some options can be used after the job has started, using
job_setoptions(job, {options}).  Many options can be used with the channel
related to the job, using ch_setoptions(channel, {options}).
See |job_setoptions()| and |ch_setoptions()|.

						*in_mode* *out_mode* *err_mode*
"in_mode"		mode specifically for stdin, only when using pipes
"out_mode"		mode specifically for stdout, only when using pipes
"err_mode"		mode specifically for stderr, only when using pipes
			See |channel-mode| for the values.

			Note: when setting "mode" the part specific mode is
			overwritten.  Therefore set "mode" first and the part
			specific mode later.

			Note: when writing to a file or buffer and when
			reading from a buffer NL mode is used by default.

						*job-noblock*
"noblock": 1		When writing use a non-blocking write call.  This
			avoids getting stuck if Vim should handle other
			messages in between, e.g. when a job sends back data
			to Vim.  It implies that when `ch_sendraw()` returns
			not all data may have been written yet.
			This option was added in patch 8.1.0350, test with: >
				if has("patch-8.1.350")
				  let options['noblock'] = 1
				endif
<
						*job-callback*
"callback": handler	Callback for something to read on any part of the
			channel.
						*job-out_cb* *out_cb*
"out_cb": handler	Callback for when there is something to read on
			stdout.  Only for when the channel uses pipes.  When
			"out_cb" wasn't set the channel callback is used.
			The two arguments are the channel and the message.

						*job-err_cb* *err_cb*
"err_cb": handler	Callback for when there is something to read on
			stderr.  Only for when the channel uses pipes.  When
			"err_cb" wasn't set the channel callback is used.
			The two arguments are the channel and the message.
						*job-close_cb*
"close_cb": handler	Callback for when the channel is closed.  Same as
			"close_cb" on |ch_open()|, see |close_cb|.
						*job-drop*
"drop": when		Specifies when to drop messages.  Same as "drop" on
			|ch_open()|, see |channel-drop|.  For "auto" the
			exit_cb is not considered.
						*job-exit_cb*
"exit_cb": handler	Callback for when the job ends.  The arguments are the
			job and the exit status.
			Vim checks up to 10 times per second for jobs that
			ended.  The check can also be triggered by calling
			|job_status()|, which may then invoke the exit_cb
			handler.
			Note that data can be buffered, callbacks may still be
			called after the process ends.
							*job-timeout*
"timeout": time		The time to wait for a request when blocking, E.g.
			when using ch_evalexpr().  In milliseconds.  The
			default is 2000 (2 seconds).
						*out_timeout* *err_timeout*
"out_timeout": time	Timeout for stdout.  Only when using pipes.
"err_timeout": time	Timeout for stderr.  Only when using pipes.
			Note: when setting "timeout" the part specific mode is
			overwritten.  Therefore set "timeout" first and the
			part specific mode later.

						*job-stoponexit*
"stoponexit": {signal}	Send {signal} to the job when Vim exits.  See
			|job_stop()| for possible values.
"stoponexit": ""	Do not stop the job when Vim exits.
			The default is "term".

						*job-term*
"term": "open"		Start a terminal in a new window and connect the job
			stdin/stdout/stderr to it.  Similar to using
			`:terminal`.
			NOTE: Not implemented yet!

"channel": {channel}	Use an existing channel instead of creating a new one.
			The parts of the channel that get used for the new job
			will be disconnected from what they were used before.
			If the channel was still used by another job this may
			cause I/O errors.
			Existing callbacks and other settings remain.

"pty": 1		Use a pty (pseudo-tty) instead of a pipe when
			possible.  This is most useful in combination with a
			terminal window, see |terminal|.
			{only on Unix and Unix-like systems}

				*job-in_io* *in_top* *in_bot* *in_name* *in_buf*
"in_io": "null"		disconnect stdin (read from /dev/null)
"in_io": "pipe"		stdin is connected to the channel (default)
"in_io": "file"		stdin reads from a file
"in_io": "buffer"	stdin reads from a buffer
"in_top": number	when using "buffer": first line to send (default: 1)
"in_bot": number	when using "buffer": last line to send (default: last)
"in_name": "/path/file"	the name of the file or buffer to read from
"in_buf": number	the number of the buffer to read from

				*job-out_io* *out_name* *out_buf*
"out_io": "null"	disconnect stdout (goes to /dev/null)
"out_io": "pipe"	stdout is connected to the channel (default)
"out_io": "file"	stdout writes to a file
"out_io": "buffer"	stdout appends to a buffer (see below)
"out_name": "/path/file" the name of the file or buffer to write to
"out_buf": number	the number of the buffer to write to
"out_modifiable": 0	when writing to a buffer, 'modifiable' will be off
			(see below)
"out_msg": 0		when writing to a new buffer, the first line will be
			set to "Reading from channel output..."

				*job-err_io* *err_name* *err_buf*
"err_io": "out"		stderr messages to go to stdout
"err_io": "null"	disconnect stderr  (goes to /dev/null)
"err_io": "pipe"	stderr is connected to the channel (default)
"err_io": "file"	stderr writes to a file
"err_io": "buffer"	stderr appends to a buffer (see below)
"err_name": "/path/file" the name of the file or buffer to write to
"err_buf": number	the number of the buffer to write to
"err_modifiable": 0	when writing to a buffer, 'modifiable' will be off
			(see below)
"err_msg": 0		when writing to a new buffer, the first line will be
			set to "Reading from channel error..."

"block_write": number	only for testing: pretend every other write to stdin
			will block

"env": dict		environment variables for the new process
"cwd": "/path/to/dir"	current working directory for the new process;
			if the directory does not exist an error is given


Writing to a buffer ~
							*out_io-buffer*
When the out_io or err_io mode is "buffer" and there is a callback, the text
is appended to the buffer before invoking the callback.

When a buffer is used both for input and output, the output lines are put
above the last line, since the last line is what is written to the channel
input.  Otherwise lines are appended below the last line.

When using JS or JSON mode with "buffer", only messages with zero or negative
ID will be added to the buffer, after decoding + encoding.  Messages with a
positive number will be handled by a callback, commands are handled as usual.

The name of the buffer from "out_name" or "err_name" is compared the full name
of existing buffers, also after expanding the name for the current directory.
E.g., when a buffer was created with ":edit somename" and the buffer name is
"somename" it will use that buffer.

If there is no matching buffer a new buffer is created.  Use an empty name to
always create a new buffer.  |ch_getbufnr()| can then be used to get the
buffer number.

For a new buffer 'buftype' is set to "nofile" and 'bufhidden' to "hide".  If
you prefer other settings, create the buffer first and pass the buffer number.
					*out_modifiable* *err_modifiable*
The "out_modifiable" and "err_modifiable" options can be used to set the
'modifiable' option off, or write to a buffer that has 'modifiable' off.  That
means that lines will be appended to the buffer, but the user can't easily
change the buffer.
					*out_msg* *err_msg*
The "out_msg" option can be used to specify whether a new buffer will have the
first line set to "Reading from channel output...".  The default is to add the
message.  "err_msg" does the same for channel error.

When an existing buffer is to be written where 'modifiable' is off and the
"out_modifiable" or "err_modifiable" options is not zero, an error is given
and the buffer will not be written to.

When the buffer written to is displayed in a window and the cursor is in the
first column of the last line, the cursor will be moved to the newly added
line and the window is scrolled up to show the cursor if needed.

Undo is synced for every added line.  NUL bytes are accepted (internally Vim
stores these as NL bytes).


Writing to a file ~
							*E920*
The file is created with permissions 600 (read-write for the user, not
accessible for others).  Use |setfperm()| to change this.

If the file already exists it is truncated.

==============================================================================
13. Controlling a job					*job-control*

To get the status of a job: >
	echo job_status(job)

To make a job stop running: >
	job_stop(job)

This is the normal way to end a job. On Unix it sends a SIGTERM to the job.
It is possible to use other ways to stop the job, or even send arbitrary
signals.  E.g. to force a job to stop, "kill it": >
	job_stop(job, "kill")

For more options see |job_stop()|.

==============================================================================
14. Using a prompt buffer				*prompt-buffer*

If you want to type input for the job in a Vim window you have a few options:
- Use a normal buffer and handle all possible commands yourself.
  This will be complicated, since there are so many possible commands.
- Use a terminal window.  This works well if what you type goes directly to
  the job and the job output is directly displayed in the window.
  See |terminal-window|.
- Use a window with a prompt buffer. This works well when entering a line for
  the job in Vim while displaying (possibly filtered) output from the job.

A prompt buffer is created by setting 'buftype' to "prompt". You would
normally only do that in a newly created buffer.

The user can edit and enter one line of text at the very last line of the
buffer.  When pressing Enter in the prompt line the callback set with
|prompt_setcallback()| is invoked.  It would normally send the line to a job.
Another callback would receive the output from the job and display it in the
buffer, below the prompt (and above the next prompt).

Only the text in the last line, after the prompt, is editable. The rest of the
buffer is not modifiable with Normal mode commands.  It can be modified by
calling functions, such as |append()|.  Using other commands may mess up the
buffer.

After setting 'buftype' to "prompt" Vim does not automatically start Insert
mode, use `:startinsert` if you want to enter Insert mode, so that the user
can start typing a line.

The text of the prompt can be set with the |prompt_setprompt()| function. If
no prompt is set with |prompt_setprompt()|, "% " is used. You can get the
effective prompt text for a buffer, with |prompt_getprompt()|.

The user can go to Normal mode and navigate through the buffer.  This can be
useful to see older output or copy text.

The CTRL-W key can be used to start a window command, such as CTRL-W w to
switch to the next window.  This also works in Insert mode (use Shift-CTRL-W
to delete a word). When leaving the window Insert mode will be stopped.  When
coming back to the prompt window Insert mode will be restored.

Any command that starts Insert mode, such as "a", "i", "A" and "I", will move
the cursor to the last line.  "A" will move to the end of the line, "I" to the
start of the line.

Here is an example for Unix.  It starts a shell in the background and prompts
for the next shell command.  Output from the shell is displayed above the
prompt. >

	" Create a channel log so we can see what happens.
	call ch_logfile('logfile', 'w')

	" Function handling a line of text that has been typed.
	func TextEntered(text)
	  " Send the text to a shell with Enter appended.
	  call ch_sendraw(g:shell_job, a:text .. "\n")
	endfunc

	" Function handling output from the shell: Add it above the prompt.
	func GotOutput(channel, msg)
	  call append(line("$") - 1, "- " .. a:msg)
	endfunc

	" Function handling the shell exits: close the window.
	func JobExit(job, status)
	  quit!
	endfunc

	" Start a shell in the background.
	let shell_job = job_start(["/bin/sh"], #{
		\ out_cb: function('GotOutput'),
		\ err_cb: function('GotOutput'),
		\ exit_cb: function('JobExit'),
		\ })

	new
	set buftype=prompt
	let buf = bufnr('')
	call prompt_setcallback(buf, function("TextEntered"))
	eval prompt_setprompt(buf, "shell command: ")

	" start accepting shell commands
	startinsert
<
The same in |Vim9| script: >

	vim9script

	# Create a channel log so we can see what happens.
	ch_logfile('logfile', 'w')

	var shell_job: job

	# Function handling a line of text that has been typed.
	def TextEntered(text: string)
	  # Send the text to a shell with Enter appended.
	  ch_sendraw(shell_job, text .. "\n")
	enddef

	# Function handling output from the shell: Add it above the prompt.
	def GotOutput(channel: channel, msg: string)
	  append(line("$") - 1, "- " .. msg)
	enddef

	# Function handling the shell exits: close the window.
	def JobExit(job: job, status: number)
	  quit!
	enddef

	# Start a shell in the background.
	shell_job = job_start(["/bin/sh"], {
				 out_cb: GotOutput,
				 err_cb: GotOutput,
				 exit_cb: JobExit,
				 })

	new
	set buftype=prompt
	var buf = bufnr('')
	prompt_setcallback(buf, TextEntered)
	prompt_setprompt(buf, "shell command: ")

	# start accepting shell commands
	startinsert

==============================================================================
15. Language Server Protocol			*language-server-protocol*

The language server protocol specification is available at:

    https://microsoft.github.io/language-server-protocol/specification

Each LSP protocol message starts with a simple HTTP header followed by the
payload encoded in JSON-RPC format.  This is described in:

    https://www.jsonrpc.org/specification

To encode and send a LSP request/notification message in a Vim |Dict| into a
LSP JSON-RPC message and to receive and decode a LSP JSON-RPC
response/notification message into a Vim |Dict|, connect to the LSP server
with the |channel-mode| set to "lsp".

For messages received on a channel with |channel-mode| set to "lsp", Vim will
process the HTTP header and decode the JSON-RPC payload into a Vim |Dict| type
and call the |channel-callback| function or the specified
|channel-onetime-callback| function.  When sending messages on a channel using
the |ch_evalexpr()| or |ch_sendexpr()| functions, Vim will add the HTTP header
and encode the Vim expression into JSON.  Refer to |json_encode()| and
|json_decode()| for more information about how Vim encodes and decodes the
builtin types into JSON.

To open a channel using the 'lsp' mode, set the 'mode' item in the |ch_open()|
{options} argument to 'lsp'.  Example: >

    let ch = ch_open(..., #{mode: 'lsp'})

To open a channel using the 'lsp' mode with a job, set the 'in_mode' and
'out_mode' items in the |job_start()| {options} argument to 'lsp'. Example: >

    let cmd = ['clangd', '--background-index', '--clang-tidy']
    let opts = {}
    let opts.in_mode = 'lsp'
    let opts.out_mode = 'lsp'
    let opts.err_mode = 'nl'
    let opts.out_cb = function('LspOutCallback')
    let opts.err_cb = function('LspErrCallback')
    let opts.exit_cb = function('LspExitCallback')
    let job = job_start(cmd, opts)

Note that if a job outputs LSP messages on stdout and non-LSP messages on
stderr, then the channel-callback function should handle both the message
formats appropriately or you should use a separate callback function for
"out_cb" and "err_cb" to handle them as shown above.

To synchronously send a JSON-RPC request to the server, use the
|ch_evalexpr()| function. This function will wait and return the decoded
response message from the server. You can use either the |channel-timeout| or
the 'timeout' field in the {options} argument to control the response wait
time.  If the request times out, then an empty |Dict| is returned.  Example: >

    let req = {}
    let req.method = 'textDocument/definition'
    let req.params = {}
    let req.params.textDocument = #{uri: 'a.c'}
    let req.params.position = #{line: 10, character: 3}
    let defs = ch_evalexpr(ch, req, #{timeout: 100})
    if defs->empty()
        ... <handle failure>
    endif

Note that in the request message the 'id' field should not be specified. If it
is specified, then Vim will overwrite the value with an internally generated
identifier.  Vim currently supports only a number type for the 'id' field.
The callback function will be invoked for both a successful and a failed RPC
request.

To send a JSON-RPC request to the server and asynchronously process the
response, use the |ch_sendexpr()| function and supply a callback function.  If
the "id" field is present in the request message, then Vim will overwrite it
with an internally generated number.  This function returns a Dict with the
identifier used for the message.  This can be used to send cancellation
request to the LSP server (if needed).  Example: >

    let req = {}
    let req.method = 'textDocument/hover'
    let req.id = 200
    let req.params = {}
    let req.params.textDocument = #{uri: 'a.c'}
    let req.params.position = #{line: 10, character: 3}
    let resp = ch_sendexpr(ch, req, #{callback: 'HoverFunc'})

To cancel an outstanding asynchronous LSP request sent to the server using the
|ch_sendexpr()| function, send a cancellation message to the server using the
|ch_sendexpr()| function with the ID returned by the |ch_sendexpr()| function
for the request.  Example: >

    " send a completion request
    let req = {}
    let req.method = 'textDocument/completion'
    let req.params = {}
    let req.params.textDocument = #{uri: 'a.c'}
    let req.params.position = #{line: 10, character: 3}
    let reqstatus = ch_sendexpr(ch, req, #{callback: 'LspComplete'})
    " send a cancellation notification
    let notif = {}
    let notif.method = '$/cancelRequest'
    let notif.id = reqstatus.id
    call ch_sendexpr(ch, notif)

To send a JSON-RPC notification message to the server, use the |ch_sendexpr()|
function. As the server will not send a response message to the notification,
don't specify the "callback" item.  Example: >

    call ch_sendexpr(ch, #{method: 'initialized'})

To respond to a JSON-RPC request message from the server, use the
|ch_sendexpr()| function.  In the response message, copy the 'id' field value
from the server request message. Example: >

    let resp = {}
    let resp.id = req.id
    let resp.result = 1
    call ch_sendexpr(ch, resp)

The JSON-RPC notification messages from the server are delivered through the
|channel-callback| function.

Depending on the use case, you can use the ch_evalexpr(), ch_sendexpr() and
ch_sendraw() functions on the same channel.

A LSP request message has the following format (expressed as a Vim Dict).  The
"params" field is optional: >

    {
	"jsonrpc": "2.0",
	"id": <number>,
	"method": <string>,
	"params": <list|dict>
    }

A LSP response message has the following format (expressed as a Vim Dict).  The
"result" and "error" fields are optional: >

    {
	"jsonrpc": "2.0",
	"id": <number>,
	"result": <vim type>
	"error": <dict>
    }

A LSP notification message has the following format (expressed as a Vim Dict).
The "params" field is optional: >

    {
	"jsonrpc": "2.0",
	"method": <string>,
	"params": <list|dict>
    }

<
 vim:tw=78:ts=8:noet:ft=help:norl: