IntenseFinance/neovim
3
0
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2026-08-17 17:04:47 -05:00
Code Issues Packages Projects Releases Wiki Activity

docs: misc, cwd, vimscript.txt #41356

Browse Source 
Extract vimscript.txt from repeat.txt
This commit is contained in:
Justin M. Keyes
2026-08-17 13:37:08 -04:00
committed by GitHub
parent a4aa0417cf
commit b107154ba2
11 changed files with 806 additions and 777 deletions
Download Patch File Download Diff File Expand all files Collapse all files
runtime/doc/api.txt
+13 -6
View File
@@ -899,18 +899,24 @@ nvim_get_color_map() *nvim_get_color_map()*
(`table<string,integer>`) Map of color names and RGB values.
nvim_get_context({opts}) *nvim_get_context()*
Gets a map of the current editor state.
Gets a map (msgpack encoding) of the current editor state:
• "bufs" |buffer-list|
• "funcs" Vimscript global and |script-local| functions
• "gvars" |global-variable|s
• "jumps" |jumplist|
• "regs" |registers|
• "sfuncs" Vimscript |script-local| functions
Attributes: ~
Since: 0.4.0
Parameters: ~
• {opts} (`vim.api.keyset.context?`) Optional parameters.
• types: List of |context-types| ("regs", "jumps", "bufs",
"gvars", …) to gather, or empty for "all".
• types: List of context types (see above) to gather, or empty
for "all".
Return: ~
(`table<string,any>`) map of global |context|.
(`table<string,any>`) Editor state as a msgpack-encoded map.
nvim_get_current_buf() *nvim_get_current_buf()*
Gets the current buffer.
@@ -1260,13 +1266,14 @@ nvim_list_wins() *nvim_list_wins()*
(`integer[]`) List of |window-ID|s
nvim_load_context({dict}) *nvim_load_context()*
Sets the current editor state from the given |context| map.
Sets the current editor state from the given map.
Attributes: ~
Since: 0.4.0
Parameters: ~
• {dict} (`table<string,any>`) |Context| map.
• {dict} (`table<string,any>`) Msgpack-encoded editor state, in the
form returned by |nvim_get_context()|.
Return: ~
(`any`)
runtime/doc/intro.txt
+13 -11
View File
@@ -388,19 +388,21 @@ CTRL-\ CTRL-G works the same as |CTRL-\_CTRL-N| for backward compatibility.
*:exm* *:exmode* *gQ* *mode-Ex* *Ex-mode* *Ex* *EX* *E501*
:exm[ode]
[count]q: Switch to Ex mode. This is like typing ":" commands
one after another, except you don't have to keep
pressing ":". Use |:visual| to exit this mode.
[count]q: Switch to Ex mode. This is like the |cmdwin| except
it stays open, in Insert-mode, so can you keep
entering ":" commands (REPL style). Use |:visual| to
exit this mode.
If a command moves the cursor or changes the buffer,
the current line is printed. An empty line moves to
(and prints) the next line.
Without [count], "q:" opens the regular |cmdwin|.
Implementation details: a persistent |cmdwin| where
<Enter> executes the current line as a command
(against the window from which Ex mode was entered)
and stays open, in insert-mode. Command output is
presented as comment (") lines. After a command that
moves the cursor or changes the buffer, the current
line is printed. An empty line moves to (and prints)
the next line.
Implementation: a persistent |cmdwin| where <Enter>
executes the current line as a command (against the
window from which Ex mode was entered). Command output
is presented as comment (") lines.
==============================================================================
Window contents *window-contents*
runtime/doc/options.txt
+10 -5
View File
@@ -781,13 +781,18 @@ A jump table for the options with a short description can be found at |Q_op|.
*'autochdir'* *'acd'* *'noautochdir'* *'noacd'*
'autochdir' 'acd' boolean (default off)
global
When on, Vim will change the current working directory whenever you
open a file, switch buffers, delete a buffer or open/close a window.
It will change to the directory containing the file which was opened
or selected. When a buffer has no name it also has no directory, thus
the current directory won't change when navigating to it.
When on, Nvim will change its global |current-directory| to the parent
of the current file, whenever you open a file, switch buffers, delete
a buffer or open/close a window.
When a buffer has no name it also has no directory, thus the current
directory won't change when navigating to it.
Note: When this option is on some plugins may not work.
Alternatively, consider using |:bcd|, |:lcd|, or |:tcd| in an autocmd,
to selectively set a local (not global) directory. See |project-dir|.
*'autocomplete'* *'ac'* *'noautocomplete'* *'noac'*
'autocomplete' 'ac' boolean (default off)
global or local to buffer |global-local|
runtime/doc/plugins.txt
+1
View File
@@ -138,6 +138,7 @@ This clears the built-in directory-opening autocommands. >lua
end,
})
<
*netrw*
To enable the legacy "netrw" plugin: >vim
:packadd netrw
runtime/doc/repeat.txt
+1 -732
View File
@@ -4,7 +4,7 @@
NVIM REFERENCE MANUAL
Repeating commands, Vim scripts and debugging *repeating*
Repeating commands *repeating*
Chapter 26 of the user manual introduces repeating |usr_26.txt|.
@@ -213,736 +213,5 @@ Multiple cursors *mcursor* *multicursor*
todo
==============================================================================
Using Vim scripts *using-scripts*
For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|.
*:so* *:source*
:so[urce] {file} Runs |Ex-command|s or Lua code (".lua" files) from
{file}. Triggers the |SourcePre| autocommand.
:[range]so[urce] Read Ex commands or Lua code from the [range] of lines
in the current buffer. When [range] is omitted read
all 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 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.
Implementation detail: When sourcing a [range] of
lines that falls inside a folded region, the range
will be adjusted to the start and end of the fold,
but only if a two line specifiers range was used.
*:source!*
:so[urce]! {file} Runs |Normal-mode| commands from {file}. 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.
*:ru* *:runtime*
:ru[ntime][!] [where] {file} ..
Sources |Ex| commands or Lua code (".lua" files) read
from {file} (a relative path) in each directory given
by '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 first
directory from 'runtimepath', then in the second
directory, etc.
When [!] is included, all found files are sourced.
Else only the first found file is sourced.
When [where] is omitted only 'runtimepath' is used.
Other values:
START search only under "start" in 'packpath'
OPT search only 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,lua}
< This is what Nvim uses to load the plugin files when
starting up. This similar command: >
:runtime plugin/**/*.{vim,lua}
< would source the first file only.
For each {file} pattern, if two `.vim` and `.lua` file
names match and differ only in extension, the `.vim`
file is sourced first.
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} |pack-add| Search for an optional plugin directory in
'packpath', source any plugin files found, and add it
to 'runtimepath'. The directory must match: >
pack/*/opt/{name}
< If the directory pack/*/opt/{name}/after exists it is
added at the end of 'runtimepath'.
Note: Use |vim.pack.add()| to install from a URL.
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 files matching the patterns >
pack/*/opt/{name}/plugin/**/*.vim
pack/*/opt/{name}/plugin/**/*.lua
< will be sourced. This allows for using subdirectories
below "plugin", just like with plugins in
'runtimepath'.
If the filetype detection was already enabled (this
is usually done with a `syntax enable` or `filetype on`
command in your |vimrc|, or automatically during
|initialization|), and the package was found in
"pack/*/opt/{name}", this command will also look
for "{name}/ftdetect/*.vim" files.
When the optional "!" is given, no plugin/ files or
ftdetect/ scripts are loaded, only the matching
directories are added to 'runtimepath'. This is
useful in your |init.vim|. The plugins will then be
loaded during the |load-plugins| |initialization| step
(note that the loading order will be reversed because
each directory is inserted before others), after
loading the ftdetect scripts.
To programmatically decide if `!` is needed during
startup, check |v:vim_did_init|: use `!` if 0 (to not
duplicate |load-plugins| step), no `!` otherwise (to
force load plugin files as otherwise they won't be
loaded automatically).
*: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|.
: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.
*:scr* *:scriptnames*
:scr[iptnames] List all sourced script names, in the order they were
first sourced. The number is used for the script ID
|<SID>|.
Also see `getscriptinfo()`.
: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 "<script>" 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 |init.vim| file, you can
source it from your |init.vim| file with this command: >
:source <script>: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.
*:source_crnl* *W15*
Windows: 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.
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
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.
==============================================================================
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) 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.
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).
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 init.vim
: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". For local functions this means that something like "<SNR>99_"
is prepended.
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.
==============================================================================
Profiling *profile* *profiling*
Profiling means that Vim measures the time that is spent on executing
functions 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* *: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
Stop 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] 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:
- 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.
==============================================================================
Context *Context* *context*
The editor state is represented by the Context concept. This includes things
like the current |jumplist|, values of |registers|, and more, described below.
*context-types*
The following Context items are supported:
"jumps" |jumplist|
"regs" |registers|
"bufs" |buffer-list|
"gvars" |global-variable|s
"sfuncs" |script-local| functions
"funcs" global and |script-local| functions
*context-dict*
Context objects are dictionaries with the following key-value pairs:
- "jumps", "regs", "bufs", "gvars":
|readfile()|-style |List| representation of corresponding msgpack
objects (see |msgpackdump()| and |msgpackparse()|).
- "funcs" (includes |script-local| functions as well):
|List| of |:function| definitions.
vim:tw=78:ts=8:noet:ft=help:norl:
runtime/doc/vimeval.txt
+1 -1
View File
@@ -4,7 +4,7 @@
VIM REFERENCE MANUAL by Bram Moolenaar
Expression evaluation *vimscript* *expression* *expr* *E15* *eval* *eval.txt*
Expression evaluation *expression* *expr* *E15* *eval* *eval.txt*
Using expressions is introduced in chapter 41 of the user manual |usr_41.txt|.
runtime/doc/vimscript.txt
+723
View File
@@ -0,0 +1,723 @@
*vimscript.txt* Nvim
NVIM REFERENCE MANUAL
Vimscript and debugging *vimscript*
This reference describes commands for running and debugging Vimscript.
For details on authoring Vimscript, see: |expression| |vimscript-functions|
Type |gO| to see the table of contents.
==============================================================================
Using Vimscript *using-scripts*
For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|.
*:so* *:source*
:so[urce] {file} Runs |Ex-command|s or Lua code (".lua" files) from
{file}. Triggers the |SourcePre| autocommand.
:[range]so[urce] Read Ex commands or Lua code from the [range] of lines
in the current buffer. When [range] is omitted read
all 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 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.
Implementation detail: When sourcing a [range] of
lines that falls inside a folded region, the range
will be adjusted to the start and end of the fold,
but only if a two line specifiers range was used.
*:source!*
:so[urce]! {file} Runs |Normal-mode| commands from {file}. 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.
*:ru* *:runtime*
:ru[ntime][!] [where] {file} ..
Sources |Ex| commands or Lua code (".lua" files) read
from {file} (a relative path) in each directory given
by '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 first
directory from 'runtimepath', then in the second
directory, etc.
When [!] is included, all found files are sourced.
Else only the first found file is sourced.
When [where] is omitted only 'runtimepath' is used.
Other values:
START search only under "start" in 'packpath'
OPT search only 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,lua}
< This is what Nvim uses to load the plugin files when
starting up. This similar command: >
:runtime plugin/**/*.{vim,lua}
< would source the first file only.
For each {file} pattern, if two `.vim` and `.lua` file
names match and differ only in extension, the `.vim`
file is sourced first.
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} |pack-add| Search for an optional plugin directory in
'packpath', source any plugin files found, and add it
to 'runtimepath'. The directory must match: >
pack/*/opt/{name}
< If the directory pack/*/opt/{name}/after exists it is
added at the end of 'runtimepath'.
Note: Use |vim.pack.add()| to install from a URL.
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 files matching the patterns >
pack/*/opt/{name}/plugin/**/*.vim
pack/*/opt/{name}/plugin/**/*.lua
< will be sourced. This allows for using subdirectories
below "plugin", just like with plugins in
'runtimepath'.
If the filetype detection was already enabled (this
is usually done with a `syntax enable` or `filetype on`
command in your |vimrc|, or automatically during
|initialization|), and the package was found in
"pack/*/opt/{name}", this command will also look
for "{name}/ftdetect/*.vim" files.
When the optional "!" is given, no plugin/ files or
ftdetect/ scripts are loaded, only the matching
directories are added to 'runtimepath'. This is
useful in your |init.vim|. The plugins will then be
loaded during the |load-plugins| |initialization| step
(note that the loading order will be reversed because
each directory is inserted before others), after
loading the ftdetect scripts.
To programmatically decide if `!` is needed during
startup, check |v:vim_did_init|: use `!` if 0 (to not
duplicate |load-plugins| step), no `!` otherwise (to
force load plugin files as otherwise they won't be
loaded automatically).
*: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|.
: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.
*:scr* *:scriptnames*
:scr[iptnames] List all sourced script names, in the order they were
first sourced. The number is used for the script ID
|<SID>|.
Also see `getscriptinfo()`.
: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 "<script>" 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 |init.vim| file, you can
source it from your |init.vim| file with this command: >
:source <script>: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.
*:source_crnl* *W15*
Windows: 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.
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
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.
==============================================================================
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) 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.
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).
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 init.vim
: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". For local functions this means that something like "<SNR>99_"
is prepended.
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.
==============================================================================
Profiling *profile* *profiling*
Profiling means that Vim measures the time that is spent on executing
functions 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* *: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
Stop 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] 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:
- 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:
runtime/lua/vim/_meta/api.gen.lua
Generated
+12 -6
View File
@@ -1349,12 +1349,18 @@ function vim.api.nvim_get_color_map() end
--- @return table<string,vim.api.keyset.command_info> # Map of maps describing commands.
function vim.api.nvim_get_commands(opts) end
--- Gets a map of the current editor state.
--- Gets a map (msgpack encoding) of the current editor state:
---
--- - "bufs" [buffer-list]
--- - "funcs" Vimscript global and [script-local] functions
--- - "gvars" [global-variable]s
--- - "jumps" [jumplist]
--- - "regs" [registers]
--- - "sfuncs" Vimscript [script-local] functions
---
--- @param opts vim.api.keyset.context? Optional parameters.
--- - types: List of `context-types` ("regs", "jumps", "bufs",
--- "gvars", …) to gather, or empty for "all".
--- @return table<string,any> # map of global |context|.
--- - types: List of context types (see above) to gather, or empty for "all".
--- @return table<string,any> # Editor state as a msgpack-encoded map.
function vim.api.nvim_get_context(opts) end
--- Gets the current buffer.
@@ -1658,9 +1664,9 @@ function vim.api.nvim_list_uis() end
--- @return integer[] # List of |window-ID|s
function vim.api.nvim_list_wins() end
--- Sets the current editor state from the given `context` map.
--- Sets the current editor state from the given map.
---
--- @param dict table<string,any> `Context` map.
--- @param dict table<string,any> Msgpack-encoded editor state, in the form returned by [nvim_get_context()].
--- @return any
function vim.api.nvim_load_context(dict) end
runtime/lua/vim/_meta/options.gen.lua
Generated
+10 -5
View File
@@ -99,13 +99,18 @@ vim.o.arshape = vim.o.arabicshape
vim.go.arabicshape = vim.o.arabicshape
vim.go.arshape = vim.go.arabicshape
--- When on, Vim will change the current working directory whenever you
--- open a file, switch buffers, delete a buffer or open/close a window.
--- It will change to the directory containing the file which was opened
--- or selected. When a buffer has no name it also has no directory, thus
--- the current directory won't change when navigating to it.
--- When on, Nvim will change its global `current-directory` to the parent
--- of the current file, whenever you open a file, switch buffers, delete
--- a buffer or open/close a window.
---
--- When a buffer has no name it also has no directory, thus the current
--- directory won't change when navigating to it.
---
--- Note: When this option is on some plugins may not work.
---
--- Alternatively, consider using `:bcd`, `:lcd`, or `:tcd` in an autocmd,
--- to selectively set a local (not global) directory. See `project-dir`.
---
--- @type boolean
vim.o.autochdir = false
vim.o.acd = vim.o.autochdir
src/nvim/api/vim.c
+12 -6
View File
@@ -1494,14 +1494,20 @@ DictOf(Integer) nvim_get_color_map(Arena *arena)
return colors;
}
/// Gets a map of the current editor state.
/// Gets a map (msgpack encoding) of the current editor state:
///
/// - "bufs" [buffer-list]
/// - "funcs" Vimscript global and [script-local] functions
/// - "gvars" [global-variable]s
/// - "jumps" [jumplist]
/// - "regs" [registers]
/// - "sfuncs" Vimscript [script-local] functions
///
/// @param opts Optional parameters.
/// - types: List of |context-types| ("regs", "jumps", "bufs",
/// "gvars", …) to gather, or empty for "all".
/// - types: List of context types (see above) to gather, or empty for "all".
/// @param[out] err Error details, if any
///
/// @return map of global |context|.
/// @return Editor state as a msgpack-encoded map.
Dict nvim_get_context(Dict(context) *opts, Arena *arena, Error *err)
FUNC_API_SINCE(6)
{
@@ -1543,9 +1549,9 @@ Dict nvim_get_context(Dict(context) *opts, Arena *arena, Error *err)
return dict;
}
/// Sets the current editor state from the given |context| map.
/// Sets the current editor state from the given map.
///
/// @param dict |Context| map.
/// @param dict Msgpack-encoded editor state, in the form returned by [nvim_get_context()].
Object nvim_load_context(Dict dict, Error *err)
FUNC_API_SINCE(6)
{
src/nvim/options.lua
+10 -5
View File
@@ -237,12 +237,17 @@ local options = {
cb = 'did_set_autochdir',
defaults = false,
desc = [=[
When on, Vim will change the current working directory whenever you
open a file, switch buffers, delete a buffer or open/close a window.
It will change to the directory containing the file which was opened
or selected. When a buffer has no name it also has no directory, thus
the current directory won't change when navigating to it.
When on, Nvim will change its global |current-directory| to the parent
of the current file, whenever you open a file, switch buffers, delete
a buffer or open/close a window.
When a buffer has no name it also has no directory, thus the current
directory won't change when navigating to it.
Note: When this option is on some plugins may not work.
Alternatively, consider using |:bcd|, |:lcd|, or |:tcd| in an autocmd,
to selectively set a local (not global) directory. See |project-dir|.
]=],
full_name = 'autochdir',
scope = { 'global' },