summaryrefslogtreecommitdiffstats
path: root/runtime/doc/repeat.txt
blob: e95b6a1ae6916a2bdcc5adaa8522ba03a5720cdd (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
*repeat.txt*    For Vim version 9.1.  Last change: 2023 May 26


		  VIM REFERENCE MANUAL    by Bram Moolenaar


Repeating commands, Vim scripts and debugging			*repeating*

Chapter 26 of the user manual introduces repeating |usr_26.txt|.

1. Single repeats		|single-repeat|
2. Multiple repeats		|multi-repeat|
3. Complex repeats		|complex-repeat|
4. Using Vim scripts		|using-scripts|
5. Using Vim packages		|packages|
6. Creating Vim packages	|package-create|
7. Debugging scripts		|debug-scripts|
8. Profiling			|profiling|

==============================================================================
1. Single repeats					*single-repeat*

							*.*
.			Repeat last change, with count replaced with [count].
			Also repeat a yank command, when the 'y' flag is
			included in 'cpoptions'.  Does not repeat a
			command-line command.

Simple changes can be repeated with the "." command.  Without a count, the
count of the last change is used.  If you enter a count, it will replace the
last one.  |v:count| and |v:count1| will be set.

If the last change included a specification of a numbered register, the
register number will be incremented.  See |redo-register| for an example how
to use this.

Note that when repeating a command that used a Visual selection, the same SIZE
of area is used, see |visual-repeat|.

							*@:*
@:			Repeat last command-line [count] times.
			{not available when compiled without the
			|+cmdline_hist| feature}


==============================================================================
2. Multiple repeats					*multi-repeat*

						*:g* *:global* *E148*
:[range]g[lobal]/{pattern}/[cmd]
			Execute the Ex command [cmd] (default ":p") on the
			lines within [range] where {pattern} matches.

:[range]g[lobal]!/{pattern}/[cmd]
			Execute the Ex command [cmd] (default ":p") on the
			lines within [range] where {pattern} does NOT match.

							*:v* *:vglobal*
:[range]v[global]/{pattern}/[cmd]
			Same as :g!.

Example: >
	:g/^Obsolete/d _
Using the underscore after `:d` avoids clobbering registers or the clipboard.
This also makes it faster.

Instead of the '/' which surrounds the {pattern}, you can use any other
single byte character, but not an alphabetic character, '\', '"', '|' or '!'.
This is useful if you want to include a '/' in the search pattern or
replacement string.

For the definition of a pattern, see |pattern|.

NOTE [cmd] may contain a range; see |collapse| and |edit-paragraph-join| for
examples.

The global commands work by first scanning through the [range] lines and
marking each line where a match occurs (for a multi-line pattern, only the
start of the match matters).
In a second scan the [cmd] is executed for each marked line, as if the cursor
was in that line.  For ":v" and ":g!" the command is executed for each not
marked line.  If a line is deleted its mark disappears.
The default for [range] is the whole buffer (1,$).  Use "CTRL-C" to interrupt
the command.  If an error message is given for a line, the command for that
line is aborted and the global command continues with the next marked or
unmarked line.
								*E147*
When the command is used recursively, it only works on one line.  Giving a
range is then not allowed. This is useful to find all lines that match a
pattern and do not match another pattern: >
	:g/found/v/notfound/{cmd}
This first finds all lines containing "found", but only executes {cmd} when
there is no match for "notfound".

Any Ex command can be used, see |ex-cmd-index|.  To execute a Normal mode
command, you can use the `:normal` command: >
	:g/pat/normal {commands}
Make sure that {commands} ends with a whole command, otherwise Vim will wait
for you to type the rest of the command for each match.  The screen will not
have been updated, so you don't know what you are doing.  See |:normal|.

The undo/redo command will undo/redo the whole global command at once.
The previous context mark will only be set once (with "''" you go back to
where the cursor was before the global command).

The global command sets both the last used search pattern and the last used
substitute pattern (this is vi compatible).  This makes it easy to globally
replace a string:
	:g/pat/s//PAT/g
This replaces all occurrences of "pat" with "PAT".  The same can be done with:
	:%s/pat/PAT/g
Which is two characters shorter!

When using "global" in Ex mode, a special case is using ":visual" as a
command.  This will move to a matching line, go to Normal mode to let you
execute commands there until you use |Q| to return to Ex mode.  This will be
repeated for each matching line.  While doing this you cannot use ":global".
To abort this type CTRL-C twice.

==============================================================================
3. Complex repeats					*complex-repeat*

							*q* *recording*
q{0-9a-zA-Z"}		Record typed characters into register {0-9a-zA-Z"}
			(uppercase to append).  The 'q' command is disabled
			while executing a register, and it doesn't work inside
			a mapping and |:normal|.

			Note: If the register being used for recording is also
			used for |y| and |p| the result is most likely not
			what is expected, because the put will paste the
			recorded macro and the yank will overwrite the
			recorded macro.

			Note: The recording happens while you type, replaying
			the register happens as if the keys come from a
			mapping.  This matters, for example, for undo, which
			only syncs when commands were typed.

q			Stops recording.  (Implementation note: The 'q' that
			stops recording is not stored in the register, unless
			it was the result of a mapping)

							*@*
@{0-9a-z".=*+}		Execute the contents of register {0-9a-z".=*+} [count]
			times.  Note that register '%' (name of the current
			file) and '#' (name of the alternate file) cannot be
			used.
			The register is executed like a mapping, that means
			that the difference between 'wildchar' and 'wildcharm'
			applies, and undo might not be synced in the same way.
			For "@=" you are prompted to enter an expression.  The
			result of the expression is then executed.
			See also |@:|.

							*@@* *E748*
@@			Repeat the previous @{0-9a-z":*} [count] times.

								*:@*
:[addr]@{0-9a-z".=*+}	Execute the contents of register {0-9a-z".=*+} as an Ex
			command.  First set cursor at line [addr] (default is
			current line).  When the last line in the register does
			not have a <CR> it will be added automatically when
			the 'e' flag is present in 'cpoptions'.
			For ":@=" the last used expression is used.  The
			result of evaluating the expression is executed as an
			Ex command.
			Mappings are not recognized in these commands.
			When the |line-continuation| character (\) is present
			at the beginning of a line in a linewise register,
			then it is combined with the previous line. This is
			useful for yanking and executing parts of a Vim
			script.
			Future: Will execute the register for each line in the
			address range.

:[addr]*{0-9a-z".=+}					*:star-compatible*
			When '*' is present in 'cpoptions' |cpo-star|, use
			":*" in the same way as ":@".  This is NOT the default
			when 'nocompatible' is used.  When the '*' flag is not
			present in 'cpoptions', ":*" is an alias for ":'<,'>",
			select the Visual area |:star|.

							*:@:*
:[addr]@:		Repeat last command-line.  First set cursor at line
			[addr] (default is current line).

:[addr]@							*:@@*
:[addr]@@		Repeat the previous :@{register}.  First set cursor at
			line [addr] (default is current line).

==============================================================================
4. Using Vim scripts					*using-scripts*

For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|.

					*:so* *:source* *load-vim-script*
:so[urce] {file}	Read Ex commands from {file}.  These are commands that
			start with a ":".
			Triggers the |SourcePre| autocommand.
							*:source-range*
:[range]so[urce] [++clear]
			Read Ex commands from the [range] of lines in the
			current buffer.  When [range] is omitted read all
			lines.

			When sourcing commands from the current buffer, the
			same script-ID |<SID>| is used even if the buffer is
			sourced multiple times. If a buffer is sourced more
			than once, then the functions in the buffer are
			defined again.

			To source a range of lines that doesn't start with the
			|:vim9script| command in Vim9 script context, the
			|:vim9cmd| modifier can be used.  If you use a Visual
			selection and type ":", the range in the form "'<,'>"
			can come before it: >
				:'<,'>vim9cmd source
<			Otherwise the range goes after the modifier and must
			have a colon prefixed, like all Vim9 ranges: >
				:vim9cmd :5,9source

<			When a range of lines in a buffer is sourced in the
			Vim9 script context, the previously defined
			script-local variables and functions are not cleared.
			This works like the range started with the
			":vim9script noclear" command.  The "++clear" argument
			can be used to clear the script-local variables and
			functions before sourcing the script. This works like
			the range started with the `:vim9script` command
			without the "noclear" argument. See |vim9-reload| for
			more information.
			Examples: >
				:4,5source
				:10,18source ++clear
<
							*:source!*
:so[urce]! {file}	Read Vim commands from {file}.  These are commands
			that are executed from Normal mode, like you type
			them.
			When used after |:global|, |:argdo|, |:windo|,
			|:bufdo|, in a loop or when another command follows
			the display won't be updated while executing the
			commands.
			Cannot be used in the |sandbox|.

							*:ru* *:runtime*
:ru[ntime][!] [where] {file} ..
			Read Ex commands from {file} in each directory given
			by 'runtimepath' and/or 'packpath'.  There is no error
			for non-existing files.

			Example: >
				:runtime syntax/c.vim

<			There can be multiple {file} arguments, separated by
			spaces.  Each {file} is searched for in the first
			directory from 'runtimepath', then in the second
			directory, etc.  Use a backslash to include a space
			inside {file} (although it's better not to use spaces
			in file names, it causes trouble).

			When [!] is included, all found files are sourced.
			When it is not included only the first found file is
			sourced.

			When [where] is omitted only 'runtimepath' is used.
			Other values:
				START	search under "start" in 'packpath'
				OPT	search under "opt" in 'packpath'
				PACK	search under "start" and "opt" in
					'packpath'
				ALL	first use 'runtimepath', then search
					under "start" and "opt" in 'packpath'

			When {file} contains wildcards it is expanded to all
			matching files.  Example: >
				:runtime! plugin/**/*.vim
<			This is what Vim uses to load the plugin files when
			starting up.  This similar command: >
				:runtime plugin/**/*.vim
<			would source the first file only.

			When 'verbose' is one or higher, there is a message
			when no file could be found.
			When 'verbose' is two or higher, there is a message
			about each searched file.

							*:pa* *:packadd* *E919*
:pa[ckadd][!] {name}	Search for an optional plugin directory in 'packpath'
			and source any plugin files found.  The directory must
			match:
				pack/*/opt/{name} ~
			The directory is added to 'runtimepath' if it wasn't
			there yet.
			If the directory pack/*/opt/{name}/after exists it is
			added at the end of 'runtimepath'.

			If loading packages from "pack/*/start" was skipped,
			then this directory is searched first:
				pack/*/start/{name} ~

			Note that {name} is the directory name, not the name
			of the .vim file.  All the files matching the pattern
				pack/*/opt/{name}/plugin/**/*.vim ~
			will be sourced.  This allows for using subdirectories
			below "plugin", just like with plugins in
			'runtimepath'.

			If the filetype detection was not enabled yet (this
			is usually done with a `syntax enable` or `filetype on`
			command in your .vimrc file), this will also look
			for "{name}/ftdetect/*.vim" files.

			When the optional ! is added no plugin files or
			ftdetect scripts are loaded, only the matching
			directories are added to 'runtimepath'.  This is
			useful in your .vimrc.  The plugins will then be
			loaded during initialization, see |load-plugins| (note
			that the loading order will be reversed, because each
			directory is inserted before others).
			Note that for ftdetect scripts to be loaded
			you will need to write `filetype plugin indent on`
			AFTER all `packadd!` commands.

			Also see |pack-add|.
			{only available when compiled with |+eval|}

						*:packl* *:packloadall*
:packl[oadall][!]	Load all packages in the "start" directory under each
			entry in 'packpath'.

			First all the directories found are added to
			'runtimepath', then the plugins found in the
			directories are sourced.  This allows for a plugin to
			depend on something of another plugin, e.g. an
			"autoload" directory.  See |packload-two-steps| for
			how this can be useful.

			This is normally done automatically during startup,
			after loading your .vimrc file.  With this command it
			can be done earlier.

			Packages will be loaded only once.  Using
			`:packloadall` a second time will have no effect.
			When the optional ! is added this command will load
			packages even when done before.

			Note that when using `:packloadall` in the |vimrc|
			file, the 'runtimepath' option is updated, and later
			all plugins in 'runtimepath' will be loaded, which
			means they are loaded again.  Plugins are expected to
			handle that.

			An error only causes sourcing the script where it
			happens to be aborted, further plugins will be loaded.
			See |packages|.
			{only available when compiled with |+eval|}

:scripte[ncoding] [encoding]		*:scripte* *:scriptencoding* *E167*
			Specify the character encoding used in the script.
			The following lines will be converted from [encoding]
			to the value of the 'encoding' option, if they are
			different.  Examples: >
				scriptencoding iso-8859-5
				scriptencoding cp932
<
			When [encoding] is empty, no conversion is done.  This
			can be used to restrict conversion to a sequence of
			lines: >
				scriptencoding euc-jp
				... lines to be converted ...
				scriptencoding
				... not converted ...

<			When conversion isn't supported by the system, there
			is no error message and no conversion is done.  When a
			line can't be converted there is no error and the
			original line is kept.

			Don't use "ucs-2" or "ucs-4", scripts cannot be in
			these encodings (they would contain NUL bytes).
			When a sourced script starts with a BOM (Byte Order
			Mark) in utf-8 format Vim will recognize it, no need
			to use ":scriptencoding utf-8" then.

			If you set the 'encoding' option in your |.vimrc|,
			`:scriptencoding` must be placed after that. E.g.: >
				set encoding=utf-8
				scriptencoding utf-8
<

:scriptv[ersion] {version}		*:scriptv* *:scriptversion*
							*E999* *E984* *E1040*
			Specify the version of Vim for the lines that follow
			in the same file.  Only applies at the toplevel of
			sourced scripts, not inside functions.

			If {version} is higher than what the current Vim
			version supports E999 will be given.  You either need
			to rewrite the script to make it work with an older
			Vim version, or update Vim to a newer version.  See
			|vimscript-version| for what changed between versions.

:vim9s[cript] [noclear]				*:vim9s* *:vim9script*
			Marks a script file as containing |Vim9-script|
			commands.  Also see |vim9-namespace|. *E1038*
			Must be the first command in the file. *E1039*
			For [noclear] see |vim9-reload|.
			Without the |+eval| feature this changes the syntax
			for some commands.
			See |:vim9cmd| for executing one command with Vim9
			syntax and semantics.

						*:scr* *:scriptnames*
:scr[iptnames]		List all sourced script names, in the order they were
			first encountered.  The number is used for the script
			ID |<SID>|.
			For a script that was used with `import autoload` but
			was not actually sourced yet an "A" is shown after the
			script ID.
			For a script that was referred to by one name but
			after resolving symbolic links got sourced with
			another name the other script is after "->".  E.g.
			"20->22" means script 20 was sourced as script 22.
			Also see `getscriptinfo()`.
			{not available when compiled without the |+eval|
			feature}

:scr[iptnames][!] {scriptId}			*:script*
			Edit script {scriptId}.  Although ":scriptnames name"
			works, using ":script name" is recommended.
			When the current buffer can't be |abandon|ed and the !
			is not present, the command fails.

						*:fini* *:finish* *E168*
:fini[sh]		Stop sourcing a script.  Can only be used in a Vim
			script file.  This is a quick way to skip the rest of
			the file.  If it is used after a |:try| but before the
			matching |:finally| (if present), the commands
			following the ":finally" up to the matching |:endtry|
			are executed first.  This process applies to all
			nested ":try"s in the script.  The outermost ":endtry"
			then stops sourcing the script.

All commands and command sequences can be repeated by putting them in a named
register and then executing it.  There are two ways to get the commands in the
register:
- Use the record command "q".  You type the commands once, and while they are
  being executed they are stored in a register.  Easy, because you can see
  what you are doing.  If you make a mistake, "p"ut the register into the
  file, edit the command sequence, and then delete it into the register
  again.  You can continue recording by appending to the register (use an
  uppercase letter).
- Delete or yank the command sequence into the register.

Often used command sequences can be put under a function key with the ':map'
command.

An alternative is to put the commands in a file, and execute them with the
':source!' command.  Useful for long command sequences.  Can be combined with
the ':map' command to put complicated commands under a function key.

The ':source' command reads Ex commands from a file or a buffer line by line.
You will have to type any needed keyboard input.  The ':source!' command reads
from a script file character by character, interpreting each character as if
you typed it.

Example: When you give the ":!ls" command you get the |hit-enter| prompt.  If
you ':source' a file with the line "!ls" in it, you will have to type the
<Enter> yourself.  But if you ':source!' a file with the line ":!ls" in it,
the next characters from that file are read until a <CR> is found.  You will
not have to type <CR> yourself, unless ":!ls" was the last line in the file.

It is possible to put ':source[!]' commands in the script file, so you can
make a top-down hierarchy of script files.  The ':source' command can be
nested as deep as the number of files that can be opened at one time (about
15).  The ':source!' command can be nested up to 15 levels deep.

You can use the "<sfile>" string (literally, this is not a special key) inside
of the sourced file, in places where a file name is expected.  It will be
replaced by the file name of the sourced file.  For example, if you have a
"other.vimrc" file in the same directory as your ".vimrc" file, you can source
it from your ".vimrc" file with this command: >
	:source <sfile>:h/other.vimrc

In script files terminal-dependent key codes are represented by
terminal-independent two character codes.  This means that they can be used
in the same way on different kinds of terminals.  The first character of a
key code is 0x80 or 128, shown on the screen as "~@".  The second one can be
found in the list |key-notation|.  Any of these codes can also be entered
with CTRL-V followed by the three digit decimal code.  This does NOT work for
the <t_xx> termcap codes, these can only be used in mappings.

							*:source_crnl* *W15*
Win32: Files that are read with ":source" normally have <CR><NL> <EOL>s.
These always work.  If you are using a file with <NL> <EOL>s (for example, a
file made on Unix), this will be recognized if 'fileformats' is not empty and
the first line does not end in a <CR>.  This fails if the first line has
something like ":map <F1> :help^M", where "^M" is a <CR>.  If the first line
ends in a <CR>, but following ones don't, you will get an error message,
because the <CR> from the first lines will be lost.

Mac Classic: Files that are read with ":source" normally have <CR> <EOL>s.
These always work.  If you are using a file with <NL> <EOL>s (for example, a
file made on Unix), this will be recognized if 'fileformats' is not empty and
the first line does not end in a <CR>.  Be careful not to use a file with <NL>
linebreaks which has a <CR> in first line.

On other systems, Vim expects ":source"ed files to end in a <NL>.  These
always work.  If you are using a file with <CR><NL> <EOL>s (for example, a
file made on MS-Windows), all lines will have a trailing <CR>.  This may cause
problems for some commands (e.g., mappings).  There is no automatic <EOL>
detection, because it's common to start with a line that defines a mapping
that ends in a <CR>, which will confuse the automaton.

							*line-continuation*
Long lines in a ":source"d Ex command script file can be split by inserting
a line continuation symbol "\" (backslash) at the start of the next line.
There can be white space before the backslash, which is ignored.

Example: the lines >
	:set comments=sr:/*,mb:*,el:*/,
		     \://,
		     \b:#,
		     \:%,
		     \n:>,
		     \fb:-
are interpreted as if they were given in one line:
	:set comments=sr:/*,mb:*,el:*/,://,b:#,:%,n:>,fb:-

All leading whitespace characters in the line before a backslash are ignored.
Note however that trailing whitespace in the line before it cannot be
inserted freely; it depends on the position where a command is split up
whether additional whitespace is allowed or not.

When a space is required it's best to put it right after the backslash.  A
space at the end of a line is hard to see and may be accidentally deleted. >
	:syn match Comment
		\ "very long regexp"
		\ keepend

In |Vim9| script the backslash can often be omitted, but not always.
See |vim9-line-continuation|.

There is a problem with the ":append" and ":insert" commands: >
   :1append
   \asdf
   .
The backslash is seen as a line-continuation symbol, thus this results in the
command: >
   :1appendasdf
   .
To avoid this, add the 'C' flag to the 'cpoptions' option: >
   :set cpo+=C
   :1append
   \asdf
   .
   :set cpo-=C

Note that when the commands are inside a function, you need to add the 'C'
flag when defining the function, it is not relevant when executing it. >
   :set cpo+=C
   :function Foo()
   :1append
   \asdf
   .
   :endfunction
   :set cpo-=C
<
					*line-continuation-comment*
To add a comment in between the lines start with '"\ '.  Notice the space
after the backslash.  Example: >
	let array = [
		"\ first entry comment
		\ 'first',
		"\ second entry comment
		\ 'second',
		\ ]

Rationale:
	Most programs work with a trailing backslash to indicate line
	continuation.  Using this in Vim would cause incompatibility with Vi.
	For example for this Vi mapping: >
		:map xx  asdf\
<	Therefore the unusual leading backslash is used.

	Starting a comment in a continuation line results in all following
	continuation lines to be part of the comment.  Since it was like this
	for a long time, when making it possible to add a comment halfway a
	sequence of continuation lines, it was not possible to use \", since
	that was a valid continuation line.  Using '"\ ' comes closest, even
	though it may look a bit weird.  Requiring the space after the
	backslash is to make it very unlikely this is a normal comment line.

==============================================================================
5. Using Vim packages					*packages*

A Vim package is a directory that contains one or more plugins.  The
advantages over normal plugins:
- A package can be downloaded as an archive and unpacked in its own directory.
  Thus the files are not mixed with files of other plugins.  That makes it
  easy to update and remove.
- A package can be a git, mercurial, etc. repository.  That makes it really
  easy to update.
- A package can contain multiple plugins that depend on each other.
- A package can contain plugins that are automatically loaded on startup and
  ones that are only loaded when needed with `:packadd`.


Using a package and loading automatically ~

Let's assume your Vim files are in the "~/.vim" directory and you want to add a
package from a zip archive "/tmp/foopack.zip":
	% mkdir -p ~/.vim/pack/foo
	% cd ~/.vim/pack/foo
	% unzip /tmp/foopack.zip

The directory name "foo" is arbitrary, you can pick anything you like.

You would now have these files under ~/.vim:
	pack/foo/README.txt
	pack/foo/start/foobar/plugin/foo.vim
	pack/foo/start/foobar/syntax/some.vim
	pack/foo/opt/foodebug/plugin/debugger.vim

When Vim starts up, after processing your .vimrc, it scans all directories in
'packpath' for plugins under the "pack/*/start" directory.  First all those
directories are added to 'runtimepath'.  Then all the plugins are loaded.
See |packload-two-steps| for how these two steps can be useful.

To allow for calling into package functionality while parsing your .vimrc,
|:colorscheme| and |autoload| will both automatically search under 'packpath'
as well in addition to 'runtimepath'.  See the documentation for each for
details.

In the example Vim will find "pack/foo/start/foobar/plugin/foo.vim" and adds
"~/.vim/pack/foo/start/foobar" to 'runtimepath'.

If the "foobar" plugin kicks in and sets the 'filetype' to "some", Vim will
find the syntax/some.vim file, because its directory is in 'runtimepath'.

Vim will also load ftdetect files, if there are any.

Note that the files under "pack/foo/opt" are not loaded automatically, only the
ones under "pack/foo/start".  See |pack-add| below for how the "opt" directory
is used.

Loading packages automatically will not happen if loading plugins is disabled,
see |load-plugins|.

To load packages earlier, so that 'runtimepath' gets updated: >
	:packloadall
This also works when loading plugins is disabled.  The automatic loading will
only happen once.

If the package has an "after" directory, that directory is added to the end of
'runtimepath', so that anything there will be loaded later.


Using a single plugin and loading it automatically ~

If you don't have a package but a single plugin, you need to create the extra
directory level:
	% mkdir -p ~/.vim/pack/foo/start/foobar
	% cd ~/.vim/pack/foo/start/foobar
	% unzip /tmp/someplugin.zip

You would now have these files:
	pack/foo/start/foobar/plugin/foo.vim
	pack/foo/start/foobar/syntax/some.vim

From here it works like above.


Optional plugins ~
							*pack-add*
To load an optional plugin from a pack use the `:packadd` command: >
	:packadd foodebug
This searches for "pack/*/opt/foodebug" in 'packpath' and will find
~/.vim/pack/foo/opt/foodebug/plugin/debugger.vim and source it.

This could be done if some conditions are met.  For example, depending on
whether Vim supports a feature or a dependency is missing.

You can also load an optional plugin at startup, by putting this command in
your |.vimrc|: >
	:packadd! foodebug
The extra "!" is so that the plugin isn't loaded if Vim was started with
|--noplugin|.

It is perfectly normal for a package to only have files in the "opt"
directory.  You then need to load each plugin when you want to use it.


Where to put what ~

Since color schemes, loaded with `:colorscheme`, are found below
"pack/*/start" and "pack/*/opt", you could put them anywhere.  We recommend
you put them below "pack/*/opt", for example
".vim/pack/mycolors/opt/dark/colors/very_dark.vim".

Filetype plugins should go under "pack/*/start", so that they are always
found.  Unless you have more than one plugin for a file type and want to
select which one to load with `:packadd`.  E.g. depending on the compiler
version: >
	if foo_compiler_version > 34
	  packadd foo_new
	else
	  packadd foo_old
	endif

The "after" directory is most likely not useful in a package.  It's not
disallowed though.

==============================================================================
6. Creating Vim packages				*package-create*

This assumes you write one or more plugins that you distribute as a package.

If you have two unrelated plugins you would use two packages, so that Vim
users can choose what they include or not.  Or you can decide to use one
package with optional plugins, and tell the user to add the preferred ones with
`:packadd`.

Decide how you want to distribute the package.  You can create an archive or
you could use a repository.  An archive can be used by more users, but is a
bit harder to update to a new version.  A repository can usually be kept
up-to-date easily, but it requires a program like "git" to be available.
You can do both, github can automatically create an archive for a release.

Your directory layout would be like this:
   start/foobar/plugin/foo.vim		" always loaded, defines commands
   start/foobar/plugin/bar.vim		" always loaded, defines commands
   start/foobar/autoload/foo.vim	" loaded when foo command used
   start/foobar/doc/foo.txt		" help for foo.vim
   start/foobar/doc/tags		" help tags
   opt/fooextra/plugin/extra.vim	" optional plugin, defines commands
   opt/fooextra/autoload/extra.vim	" loaded when extra command used
   opt/fooextra/doc/extra.txt		" help for extra.vim
   opt/fooextra/doc/tags		" help tags

This allows for the user to do: >
	mkdir ~/.vim/pack
	cd ~/.vim/pack
	git clone https://github.com/you/foobar.git myfoobar

Here "myfoobar" is a name that the user can choose, the only condition is that
it differs from other packages.

In your documentation you explain what the plugins do, and tell the user how
to load the optional plugin: >
	:packadd! fooextra

You could add this packadd command in one of your plugins, to be executed when
the optional plugin is needed.

Run the `:helptags` command to generate the doc/tags file.  Including this
generated file in the package means that the user can drop the package in the
pack directory and the help command works right away.  Don't forget to re-run
the command after changing the plugin help: >
	:helptags path/start/foobar/doc
	:helptags path/opt/fooextra/doc


Dependencies between plugins ~
							*packload-two-steps*
Suppose you have two plugins that depend on the same functionality. You can
put the common functionality in an autoload directory, so that it will be
found automatically.  Your package would have these files:

	pack/foo/start/one/plugin/one.vim  >
		call foolib#getit()
<	pack/foo/start/two/plugin/two.vim >
		call foolib#getit()
<	pack/foo/start/lib/autoload/foolib.vim >
		func foolib#getit()

This works, because loading packages will first add all found directories to
'runtimepath' before sourcing the plugins.

==============================================================================
7. Debugging scripts					*debug-scripts*

Besides the obvious messages that you can add to your scripts to find out what
they are doing, Vim offers a debug mode.  This allows you to step through a
sourced file or user function and set breakpoints.

NOTE: The debugging mode is far from perfect.  Debugging will have side
effects on how Vim works.  You cannot use it to debug everything.  For
example, the display is messed up by the debugging messages.

An alternative to debug mode is setting the 'verbose' option.  With a bigger
number it will give more verbose messages about what Vim is doing.


STARTING DEBUG MODE						*debug-mode*

To enter debugging mode use one of these methods:
1. Start Vim with the |-D| argument: >
	vim -D file.txt
<  Debugging will start as soon as the first vimrc file is sourced.  This is
   useful to find out what is happening when Vim is starting up.  A side
   effect is that Vim will switch the terminal mode before initialisations
   have finished, with unpredictable results.
   For a GUI-only version (Windows, Macintosh) the debugging will start as
   soon as the GUI window has been opened.  To make this happen early, add a
   ":gui" command in the vimrc file.
								*:debug*
2. Run a command with ":debug" prepended.  Debugging will only be done while
   this command executes.  Useful for debugging a specific script or user
   function.  And for scripts and functions used by autocommands.  Example: >
	:debug edit test.txt.gz

3. Set a breakpoint in a sourced file or user function.  You could do this in
   the command line: >
	vim -c "breakadd file */explorer.vim" .
<  This will run Vim and stop in the first line of the "explorer.vim" script.
   Breakpoints can also be set while in debugging mode.

In debugging mode every executed command is displayed before it is executed.
Comment lines, empty lines and lines that are not executed are skipped.  When
a line contains two commands, separated by "|", each command will be displayed
separately.


DEBUG MODE

Once in debugging mode, the usual Ex commands can be used.  For example, to
inspect the value of a variable: >
	echo idx
When inside a user function, this will print the value of the local variable
"idx".  Prepend "g:" to get the value of a global variable: >
	echo g:idx
All commands are executed in the context of the current function or script.
You can also set options, for example setting or resetting 'verbose' will show
what happens, but you might want to set it just before executing the lines you
are interested in: >
	:set verbose=20

Commands that require updating the screen should be avoided, because their
effect won't be noticed until after leaving debug mode.  For example: >
	:help
won't be very helpful.

There is a separate command-line history for debug mode.

NOTE: In Vim9 script, if a command is written at the script level and
continues on the next line, not using the old way with a backslash for line
continuation, only the first line is printed before the debugging prompt.

The line number for a function line is relative to the start of the function.
If you have trouble figuring out where you are, edit the file that defines
the function in another Vim, search for the start of the function and do
"99j".  Replace "99" with the line number.

Additionally, these commands can be used:
							*>cont*
	cont		Continue execution until the next breakpoint is hit.
							*>quit*
	quit		Abort execution.  This is like using CTRL-C, some
			things might still be executed, doesn't abort
			everything.  Still stops at the next breakpoint.
							*>next*
	next		Execute the command and come back to debug mode when
			it's finished.  This steps over user function calls
			and sourced files.
							*>step*
	step		Execute the command and come back to debug mode for
			the next command.  This steps into called user
			functions and sourced files.
							*>interrupt*
	interrupt	This is like using CTRL-C, but unlike ">quit" comes
			back to debug mode for the next command that is
			executed.  Useful for testing |:finally| and |:catch|
			on interrupt exceptions.
							*>finish*
	finish		Finish the current script or user function and come
			back to debug mode for the command after the one that
			sourced or called it.
							*>bt*
							*>backtrace*
							*>where*
	backtrace	Show the call stacktrace for current debugging session.
	bt
	where
							*>frame*
	frame N		Goes to N backtrace level. + and - signs make movement
			relative.  E.g., ":frame +3" goes three frames up.
							*>up*
	up		Goes one level up from call stacktrace.
							*>down*
	down		Goes one level down from call stacktrace.

About the additional commands in debug mode:
- There is no command-line completion for them, you get the completion for the
  normal Ex commands only.
- You can shorten them, up to a single character, unless more than one command
  starts with the same letter.  "f" stands for "finish", use "fr" for "frame".
- Hitting <CR> will repeat the previous one.  When doing another command, this
  is reset (because it's not clear what you want to repeat).
- When you want to use the Ex command with the same name, prepend a colon:
  ":cont", ":next", ":finish" (or shorter).
							*vim9-debug*
When debugging a compiled :def function, "step" will stop before every
executed line, not every single instruction.  Thus it works mostly like a not
compiled function.  Access to local variables is limited you can use: >
	echo varname
But not much else.
When executing a command that is not a specific bytecode instruction but
executed like a normal Ex command, "step" will stop once in the compiled
context, where local variables can be inspected, and once just before
executing the command.

In a :def function variables that haven't been declared yet cannot be
inspected.  Variables that have been declared can be inspected, also when the
block they were declared in has finished.  In commands this would not be
possible, thus is slightly misleading (but can be useful).

The backtrace shows the hierarchy of function calls, e.g.:
	>bt ~
	  3 function One[3] ~
	  2 Two[3] ~
	->1 Three[3] ~
	  0 Four ~
	line 1: let four = 4 ~

The "->" points to the current frame.  Use "up", "down" and "frame N" to
select another frame.

In the current frame you can evaluate the local function variables.  There is
no way to see the command at the current line yet.


DEFINING BREAKPOINTS
							*:breaka* *:breakadd*
:breaka[dd] func [lnum] {name}
		Set a breakpoint in a function.  Example: >
			:breakadd func Explore
<		Doesn't check for a valid function name, thus the breakpoint
		can be set before the function is defined.

:breaka[dd] file [lnum] {name}
		Set a breakpoint in a sourced file.  Example: >
			:breakadd file 43 .vimrc

:breaka[dd] here
		Set a breakpoint in the current line of the current file.
		Like doing: >
			:breakadd file <cursor-line> <current-file>
<		Note that this only works for commands that are executed when
		sourcing the file, not for a function defined in that file.

:breaka[dd] expr {expression}
		Sets a breakpoint, that will break whenever the {expression}
		evaluates to a different value. Example: >
			:breakadd expr g:lnum
<		Will break, whenever the global variable lnum changes.

		Errors in evaluation are suppressed, you can use the name of a
		variable that does not exist yet.  This also means you will
		not notice anything if the expression has a mistake.

		Note if you watch a |script-variable| this will break
		when switching scripts, since the script variable is only
		valid in the script where it has been defined and if that
		script is called from several other scripts, this will stop
		whenever that particular variable will become visible or
		inaccessible again.

The [lnum] is the line number of the breakpoint.  Vim will stop at or after
this line.  When omitted line 1 is used.

							*:debug-name*
{name} is a pattern that is matched with the file or function name.  The
pattern is like what is used for autocommands.  There must be a full match (as
if the pattern starts with "^" and ends in "$").  A "*" matches any sequence
of characters.  'ignorecase' is not used, but "\c" can be used in the pattern
to ignore case |/\c|.  Don't include the () for the function name!

The match for sourced scripts is done against the full file name.  If no path
is specified the current directory is used.  Examples: >
	breakadd file explorer.vim
matches "explorer.vim" in the current directory. >
	breakadd file *explorer.vim
matches ".../plugin/explorer.vim", ".../plugin/iexplorer.vim", etc. >
	breakadd file */explorer.vim
matches ".../plugin/explorer.vim" and "explorer.vim" in any other directory.

The match for functions is done against the name as it's shown in the output
of ":function".  However, for local functions the script-specific prefix such
as "<SNR>99_" is ignored to make it easier to match script-local functions
without knowing the ID of the script.

Note that functions are first loaded and later executed.  When they are loaded
the "file" breakpoints are checked, when they are executed the "func"
breakpoints.


DELETING BREAKPOINTS
						*:breakd* *:breakdel* *E161*
:breakd[el] {nr}
		Delete breakpoint {nr}.  Use |:breaklist| to see the number of
		each breakpoint.

:breakd[el] *
		Delete all breakpoints.

:breakd[el] func [lnum] {name}
		Delete a breakpoint in a function.

:breakd[el] file [lnum] {name}
		Delete a breakpoint in a sourced file.

:breakd[el] here
		Delete a breakpoint at the current line of the current file.

When [lnum] is omitted, the first breakpoint in the function or file is
deleted.
The {name} must be exactly the same as what was typed for the ":breakadd"
command.  "explorer", "*explorer.vim" and "*explorer*" are different.


LISTING BREAKPOINTS
							*:breakl* *:breaklist*
:breakl[ist]
		List all breakpoints.


OBSCURE

						*:debugg* *:debuggreedy*
:debugg[reedy]
		Read debug mode commands from the normal input stream, instead
		of getting them directly from the user.  Only useful for test
		scripts.  Example: >
		  echo 'q^Mq' | vim -e -s -c debuggreedy -c 'breakadd file script.vim' -S script.vim

:0debugg[reedy]
		Undo ":debuggreedy": get debug mode commands directly from the
		user, don't use typeahead for debug commands.

==============================================================================
8. Profiling						*profile* *profiling*

Profiling means that Vim measures the time that is spent on executing
functions and/or scripts.  The |+profile| feature is required for this.
It is included when Vim was compiled with "huge" features.

You can also use the |reltime()| function to measure time.  This only requires
the |+reltime| feature, which is present in more builds.

For profiling syntax highlighting see |:syntime|.

For example, to profile the one_script.vim script file: >
	:profile start /tmp/one_script_profile
	:profile file one_script.vim
	:source one_script.vim
	:exit


:prof[ile] start {fname}			*:prof* *:profile* *E750*
		Start profiling, write the output in {fname} upon exit or when
		a `:profile stop` or `:profile dump` command is invoked.
		"~/" and environment variables in {fname} will be expanded.
		If {fname} already exists it will be silently overwritten.
		The variable |v:profiling| is set to one.

:prof[ile] stop
		Write the collected profiling information to the logfile and
		stop profiling. You can use the `:profile start` command to
		clear the profiling statistics and start profiling again.

:prof[ile] pause
		Don't profile until the following `:profile continue`.  Can be
		used when doing something that should not be counted (e.g., an
		external command).  Does not nest.

:prof[ile] continue
		Continue profiling after `:profile pause`.

:prof[ile] func {pattern}
		Profile function that matches the pattern {pattern}.
		See |:debug-name| for how {pattern} is used.

:prof[ile][!] file {pattern}
		Profile script file that matches the pattern {pattern}.
		See |:debug-name| for how {pattern} is used.
		This only profiles the script itself, not the functions
		defined in it.
		When the [!] is added then all functions defined in the script
		will also be profiled.
		Note that profiling only starts when the script is loaded
		after this command.  A :profile command in the script itself
		won't work.

:prof[ile] dump
		Write the current state of profiling to the logfile
		immediately.  After running this command, Vim continues to
		collect the profiling statistics.

:profd[el] ...						*:profd* *:profdel*
		Stop profiling for the arguments specified. See |:breakdel|
		for the arguments. Examples: >
			profdel func MyFunc
			profdel file MyScript.vim
			profdel here

You must always start with a ":profile start fname" command.  The resulting
file is written when Vim exits.  For example, to profile one specific
function: >
	profile start /tmp/vimprofile
	profile func MyFunc

Here is an example of the output, with line
numbers prepended for the explanation:

  1 FUNCTION  Test2() ~
  2 Called 1 time ~
  3 Total time:   0.155251 ~
  4  Self time:   0.002006 ~
  5  ~
  6 count  total (s)   self (s) ~
  7	9	       0.000096   for i in range(8) ~
  8	8   0.153655   0.000410     call Test3() ~
  9	8	       0.000070   endfor ~
 10				  " Ask a question ~
 11	1	       0.001341   echo input("give me an answer: ") ~

The header (lines 1-4) gives the time for the whole function.  The "Total"
time is the time passed while the function was executing.  The "Self" time is
the "Total" time reduced by time spent in:
- other user defined functions
- sourced scripts
- executed autocommands
- external (shell) commands

Lines 7-11 show the time spent in each executed line.  Lines that are not
executed do not count.  Thus a comment line is never counted.

The Count column shows how many times a line was executed.  Note that the
"for" command in line 7 is executed one more time as the following lines.
That is because the line is also executed to detect the end of the loop.

The time Vim spends waiting for user input isn't counted at all.  Thus how
long you take to respond to the input() prompt is irrelevant.

Profiling should give a good indication of where time is spent, but keep in
mind there are various things that may clobber the results:

- The accuracy of the time measured depends on the gettimeofday(), or
  clock_gettime() if available, system function. The accuracy ranges from
  1/100 second to nanoseconds. With clock_gettime() the times are displayed in
  nanoseconds, otherwise microseconds.  You can use `has("prof_nsec")`.

- Real elapsed time is measured, if other processes are busy they may cause
  delays at unpredictable moments.  You may want to run the profiling several
  times and use the lowest results.

- If you have several commands in one line you only get one time.  Split the
  line to see the time for the individual commands.

- The time of the lines added up is mostly less than the time of the whole
  function.  There is some overhead in between.

- Functions that are deleted before Vim exits will not produce profiling
  information.  You can check the |v:profiling| variable if needed: >
	:if !v:profiling
	:   delfunc MyFunc
	:endif
<
- Profiling may give weird results on multi-processor systems, when sleep
  mode kicks in or the processor frequency is reduced to save power.

- The "self" time is wrong when a function is used recursively.


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