Repeat
Nvim:help pages,generated fromsource using thetree-sitter-vimdoc parser.
Repeating commands, Vim scripts and debugging
Chapter 26 of the user manual introduces repeating
usr_26.txt.
..Repeat last change, with count replaced with [count].Also repeat a yank command, when the 'y' flag isincluded in
'cpoptions'. Does not repeat acommand-line command.
Simple changes can be repeated with the "." command. Without a count, thecount of the last change is used. If you enter a count, it will replace thelast one.
v:count and
v:count1 will be set.
If the last change included a specification of a numbered register, theregister number will be incremented. See
redo-register for an example howto use this.
Note that when repeating a command that used a Visual selection, the same SIZEof area is used, see
visual-repeat.
@:@:Repeat last command-line [count] times.
:g:globalE148:[range]g[lobal]/{pattern}/[cmd]Execute the Ex command [cmd] (default ":p") on thelines within [range] where
{pattern} matches.
:[range]g[lobal]!/{pattern}/[cmd]Execute the Ex command [cmd] (default ":p") on thelines 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 othersingle byte character, but not an alphabetic character, '\', '"', '|' or '!'.This is useful if you want to include a '/' in the search pattern orreplacement string.
For the definition of a pattern, see
pattern.
The global commands work by first scanning through the [range] lines andmarking each line where a match occurs (for a multi-line pattern, only thestart of the match matters).In a second scan the [cmd] is executed for each marked line, as if the cursorwas in that line. For ":v" and ":g!" the command is executed for each notmarked line. If a line is deleted its mark disappears.The default for [range] is the whole buffer (1,$). Use "CTRL-C" to interruptthe command. If an error message is given for a line, the command for thatline is aborted and the global command continues with the next marked orunmarked line.
E147When the command is used recursively, it only works on one line. Giving arange is then not allowed. This is useful to find all lines that match apattern and do not match another pattern:
:g/found/v/notfound/{cmd}This first finds all lines containing "found", but only executes
{cmd} whenthere is no match for "notfound".
Any Ex command can be used, see
ex-cmd-index. To execute a Normal modecommand, you can use the
:normal command:
:g/pat/normal {commands}Make sure that
{commands} ends with a whole command, otherwise Vim will waitfor you to type the rest of the command for each match. The screen will nothave 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 towhere the cursor was before the global command).
The global command sets both the last used search pattern and the last usedsubstitute pattern (this is vi compatible). This makes it easy to globallyreplace 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 acommand. This will move to a matching line, go to Normal mode to let youexecute commands there until you use
gQ to return to Ex mode. This will berepeated for each matching line. While doing this you cannot use ":global".To abort this type
CTRL-C twice.
qrecordingmacroq{0-9a-zA-Z"}Record typed characters into register
{0-9a-zA-Z"}(uppercase to append). The 'q' command is disabledwhile executing a register, and it doesn't work insidea mapping and
:normal.
Note: If the register being used for recording is alsoused for
y and
p the result is most likely notwhat is expected, because the put will paste therecorded macro and the yank will overwrite therecorded macro.
Note: The recording happens while you type, replayingthe register happens as if the keys come from amapping. This matters, for example, for undo, whichonly syncs when commands were typed.
qStops recording.Implementation note: The 'q' that stops recording isnot stored in the register, unless it was the resultof a mapping
@@{0-9a-z".=*+}Execute the contents of register
{0-9a-z".=*+} [count]times. Note that register '%' (name of the currentfile) and '#' (name of the alternate file) cannot beused.The register is executed like a mapping, that meansthat 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. Theresult 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 anEx command. First set cursor at line [addr] (defaultis current line). When the last line in the registerdoes not have a
<CR> it will be added automaticallywhen the 'e' flag is present in
'cpoptions'.For ":@=" the last used expression is used. Theresult of evaluating the expression is executed as anEx command.Mappings are not recognized in these commands.When the
line-continuation character (\) is presentat the beginning of a line in a linewise register,then it is combined with the previous line. This isuseful for yanking and executing parts of a Vimscript.
:@::[addr]@:Repeat last command-line. First set cursor at line[addr] (default is current line).
:[addr]@
:@@:[addr]@@Repeat the previous :@{register}. First set cursor atline [addr] (default is current line).
For writing a Vim script, see chapter 41 of the user manual
usr_41.txt.
:[range]so[urce]Read Ex commands or Lua code from the [range] of linesin the current buffer. When [range] is omitted readall lines. The buffer is treated as Lua code if its
'filetype' is "lua" or its filename ends with ".lua".
When sourcing commands or Lua code from the currentbuffer, the same script-ID
<SID> is used even if thebuffer is sourced multiple times. If a buffer issourced more than once, then the functions in thebuffer are defined again.
Implementation detail: When sourcing a [range] oflines that falls inside a folded region, the rangewill be adjusted to the start and end of the fold,but only if a two line specifiers range was used.
:ru:runtime:ru[ntime][!] [where]
{file} ..Sources
Ex commands or Lua code (".lua" files) readfrom
{file} (a relative path) in each directory givenby
'runtimepath' and/or
'packpath'.Ignores non-existing files.
Example:
:runtime syntax/c.vim:runtime syntax/c.lua
There can be multiple space-separated
{file}arguments. Each
{file} is searched for in the firstdirectory from
'runtimepath', then in the seconddirectory, etc.
When [!] is included, all found files are sourced.Else only the first found file is sourced.
When
{file} contains wildcards it is expanded to allmatching files. Example:
:runtime! plugin/**/*.{vim,lua}This is what Nvim uses to load the plugin files whenstarting up. This similar command:
:runtime plugin/**/*.{vim,lua}would source the first file only.
For each{file} pattern, if two.vim and.lua filenames match and differ only in extension, the.vimfile is sourced first.
When
'verbose' is one or higher, there is a messagewhen no file could be found.When
'verbose' is two or higher, there is a messageabout each searched file.
If the directory pack/*/opt/{name}/after exists it isadded 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 nameof the .vim file. All files matching the patterns
pack/*/opt/{name}/plugin/**/*.vimpack/*/opt/{name}/plugin/**/*.luawill be sourced. This allows for using subdirectoriesbelow "plugin", just like with plugins in
'runtimepath'.
If the filetype detection was already enabled (thisis usually done with a
syntax enable or
filetype oncommand in your
vimrc, or automatically during
initialization), and the package was found in"pack/*/opt/{name}", this command will also lookfor "{name}/ftdetect/*.vim" files.
When the optional "!" is given, no plugin/ files orftdetect/ scripts are loaded, only the matchingdirectories are added to
'runtimepath'. This isuseful in your
init.vim. The plugins will then beloaded during the
load-pluginsinitialization step(note that the loading order will be reversed becauseeach directory is inserted before others), afterloading the ftdetect scripts.
To programmatically decide if
! is needed duringstartup, check
v:vim_did_init: use
! if 0 (to notduplicate
load-plugins step), no
! otherwise (toforce load plugin files as otherwise they won't beloaded automatically).
First all the directories found are added to
'runtimepath', then the plugins found in thedirectories are sourced. This allows for a plugin todepend on something of another plugin, e.g. an"autoload" directory. See
packload-two-steps forhow this can be useful.
This is normally done automatically during startup,after loading your
vimrc file. With this command itcan 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 loadpackages even when done before.
Note that when using
:packloadall in the
vimrcfile, the
'runtimepath' option is updated, and laterall plugins in
'runtimepath' will be loaded, whichmeans they are loaded again. Plugins are expected tohandle that.
An error only causes sourcing the script where ithappens to be aborted, further plugins will be loaded.See
packages.
:scripte[ncoding] [encoding]
:scripte:scriptencodingE167Specify the character encoding used in the script.The following lines will be converted from [encoding]to the value of the
'encoding' option, if they aredifferent. Examples:
scriptencoding iso-8859-5scriptencoding cp932
When [encoding] is empty, no conversion is done. Thiscan be used to restrict conversion to a sequence oflines:
scriptencoding euc-jp... lines to be converted ...scriptencoding... not converted ...
When conversion isn't supported by the system, thereis no error message and no conversion is done. When aline can't be converted there is no error and theoriginal line is kept.
Don't use "ucs-2" or "ucs-4", scripts cannot be inthese encodings (they would contain NUL bytes).When a sourced script starts with a BOM (Byte OrderMark) in utf-8 format Vim will recognize it, no needto use ":scriptencoding utf-8" then.
:scr:scriptnames:scr[iptnames]List all sourced script names, in the order they werefirst sourced. The number is used for the script ID
<SID>.Also see
getscriptinfo().
:scr[iptnames][!]
{scriptId}:scriptEdit script
{scriptId}. Although ":scriptnames name"works, using ":script name" is recommended.When the current buffer can't be
abandoned and the !is not present, the command fails.
:fini:finishE168:fini[sh]Stop sourcing a script. Can only be used in a Vimscript file. This is a quick way to skip the rest ofthe file. If it is used after a
:try but before thematching
:finally (if present), the commandsfollowing the ":finally" up to the matching
:endtryare executed first. This process applies to allnested ":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 namedregister and then executing it. There are two ways to get the commands in theregister:
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 withthe ':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 readsfrom a script file character by character, interpreting each character as ifyou typed it.
Example: When you give the ":!ls" command you get the
hit-enter prompt. Ifyou ':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 willnot 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 canmake a top-down hierarchy of script files. The ':source' command can benested as deep as the number of files that can be opened at one time (about15). The ':source!' command can be nested up to 15 levels deep.
You can use the "<script>" string (literally, this is not a special key) insideof the sourced file, in places where a file name is expected. It will bereplaced by the file name of the sourced file. For example, if you have a"other.vimrc" file in the same directory as your
init.vim file, you cansource it from your
init.vim file with this command:
:source <script>:h/other.vimrc
In script files terminal-dependent key codes are represented byterminal-independent two character codes. This means that they can be usedin the same way on different kinds of terminals. The first character of akey code is 0x80 or 128, shown on the screen as "~@". The second one can befound in the list
key-notation. Any of these codes can also be enteredwith
CTRL-V followed by the three digit decimal code.
:source_crnlW15Windows: 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, afile made on Unix), this will be recognized if
'fileformats' is not empty andthe first line does not end in a
<CR>. This fails if the first line hassomething like ":map
<F1> :help^M", where "^M" is a
<CR>. If the first lineends in a
<CR>, but following ones don't, you will get an error message,because the
<CR> from the first lines will be lost.
On other systems, Vim expects ":source"ed files to end in a<NL>. Thesealways work. If you are using a file with<CR><NL><EOL>s (for example, afile made on MS-Windows), all lines will have a trailing<CR>. This may causeproblems for some commands (e.g., mappings). There is no automatic<EOL>detection, because it's common to start with a line that defines a mappingthat ends in a<CR>, which will confuse the automaton.
line-continuationLong lines in a ":source"d Ex command script file can be split by insertinga 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 beinserted freely; it depends on the position where a command is split upwhether additional whitespace is allowed or not.
When a space is required it's best to put it right after the backslash. Aspace at the end of a line is hard to see and may be accidentally deleted.
:syn match Comment \ "very long regexp" \ keepend
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 thecommand:
: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-commentTo add a comment in between the lines start with
'"\ '. Notice the spaceafter the backslash. Example:
let array = [ "\ first entry comment \ 'first', "\ second entry comment \ 'second', \ ]
Rationale:Most programs work with a trailing backslash to indicate linecontinuation. 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 followingcontinuation lines to be part of the comment. Since it was like thisfor a long time, when making it possible to add a comment halfway asequence of continuation lines, it was not possible to use \", sincethat was a valid continuation line. Using'"\ ' comes closest, eventhough it may look a bit weird. Requiring the space after thebackslash is to make it very unlikely this is a normal comment line.
Besides the obvious messages that you can add to your scripts to find out whatthey are doing, Vim offers a debug mode. This allows you to step through asourced file or user function and set breakpoints.
NOTE: The debugging mode is far from perfect. Debugging will have sideeffects on how Vim works. You cannot use it to debug everything. Forexample, the display is messed up by the debugging messages.
An alternative to debug mode is setting the
'verbose' option. With a biggernumber it will give more verbose messages about what Vim is doing.
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) 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.
:debug2. 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. Whena line contains two commands, separated by "|", each command will be displayedseparately.
DEBUG MODE
Once in debugging mode, the usual Ex commands can be used. For example, toinspect 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 showwhat happens, but you might want to set it just before executing the lines youare interested in:
:set verbose=20
Commands that require updating the screen should be avoided, because theireffect 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.
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 definesthe 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:
>contcontContinue execution until the next breakpoint is hit.
>quitquitAbort execution. This is like using
CTRL-C, somethings might still be executed, doesn't aborteverything. Still stops at the next breakpoint.
>nextnextExecute the command and come back to debug mode whenit's finished. This steps over user function callsand sourced files.
>stepstepExecute the command and come back to debug mode forthe next command. This steps into called userfunctions and sourced files.
>interruptinterruptThis is like using
CTRL-C, but unlike ">quit" comesback to debug mode for the next command that isexecuted. Useful for testing
:finally and
:catchon interrupt exceptions.
>finishfinishFinish the current script or user function and comeback to debug mode for the command after the one thatsourced or called it.
>bt>backtrace>wherebacktraceShow the call stacktrace for current debugging session.btwhere
>frameframe NGoes to N backtrace level. + and - signs make movementrelative. E.g., ":frame +3" goes three frames up.
>upupGoes one level up from call stacktrace.
>downdownGoes 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).
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" toselect another frame.
In the current frame you can evaluate the local function variables. There isno 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 breakpointcan be set before the function is defined.
:breaka[dd] file [lnum]
{name}Set a breakpoint in a sourced file. Example:
:breakadd file 43 init.vim
:breaka[dd] hereSet 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 whensourcing 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 avariable that does not exist yet. This also means you willnot notice anything if the expression has a mistake.
Note if you watch a
script-variable this will breakwhen switching scripts, since the script variable is onlyvalid in the script where it has been defined and if thatscript is called from several other scripts, this will stopwhenever that particular variable will become visible orinaccessible again.
The [lnum] is the line number of the breakpoint. Vim will stop at or afterthis line. When omitted line 1 is used.
:debug-name{name} is a pattern that is matched with the file or function name. Thepattern is like what is used for autocommands. There must be a full match (asif the pattern starts with "^" and ends in "$"). A "*" matches any sequenceof characters.
'ignorecase' is not used, but "\c" can be used in the patternto 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 pathis 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 outputof ":function". For local functions this means that something like "<SNR>99_"is prepended.
Note that functions are first loaded and later executed. When they are loadedthe "file" breakpoints are checked, when they are executed the "func"breakpoints.
: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] hereDelete a breakpoint at the current line of the current file.
When [lnum] is omitted, the first breakpoint in the function or file isdeleted.The{name} must be exactly the same as what was typed for the ":breakadd"command. "explorer", "*explorer.vim" and "*explorer*" are different.
OBSCURE
:debugg:debuggreedy:debugg[reedy]Read debug mode commands from the normal input stream, insteadof getting them directly from the user. Only useful for testscripts. 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 theuser, don't use typeahead for debug commands.
Profiling means that Vim measures the time that is spent on executingfunctions and/or scripts.
You can also use the
reltime() function to measure time.
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:profileE750Start profiling, write the output in
{fname} upon exit or whena
: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] stopWrite the collected profiling information to the logfile andstop profiling. You can use the:profile start command toclear the profiling statistics and start profiling again.
:prof[ile] pauseStop profiling until the next:profile continue command.Can be used when doing something that should not be counted(e.g., an external command). Does not nest.
:prof[ile] continueContinue 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 functionsdefined in it.When the [!] is added then all functions defined in the scriptwill also be profiled.Note that profiling only starts when the script is loadedafter this command. A :profile command in the script itselfwon't work.
:prof[ile] dumpWrite the current state of profiling to the logfileimmediately. After running this command, Vim continues tocollect the profiling statistics.
:profd[el] ...
:profd:profdelStop profiling for the arguments specified. See
:breakdelfor the arguments. Examples:
profdel func MyFuncprofdel file MyScript.vimprofdel here
You must always start with a ":profile start fname" command. The resultingfile is written when Vim exits. For example, to profile one specificfunction:
profile start /tmp/vimprofileprofile func MyFunc
Here is an example of the output, with linenumbers 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)
79 0.000096 for i in range(8)
88 0.153655 0.000410 call Test3()
98 0.000070 endfor
10 " Ask a question
111 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 isthe "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 notexecuted 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 howlong you take to respond to the input() prompt is irrelevant.
Profiling should give a good indication of where time is spent, but keep inmind there are various things that may clobber the results:
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.
The editor state is represented by the Context concept. This includes thingslike the current
jumplist, values of
registers, and more, described below.
context-dictContext objects are dictionaries with the following key-value pairs: