Mercurial > vim
view runtime/doc/repeat.txt @ 32936:c517845bd10e v9.0.1776
patch 9.0.1776: No support for stable Python 3 ABI
Commit: https://github.com/vim/vim/commit/c13b3d1350b60b94fe87f0761ea31c0e7fb6ebf3
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Sun Aug 20 21:18:38 2023 +0200
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
author | Christian Brabandt <cb@256bit.org> |
---|---|
date | Sun, 20 Aug 2023 21:30:04 +0200 |
parents | 695b50472e85 |
children | 484543479bd7 |
line wrap: on
line source
*repeat.txt* For Vim version 9.0. Last change: 2023 May 26 VIM REFERENCE MANUAL by Bram Moolenaar Repeating commands, Vim scripts and debugging *repeating* Chapter 26 of the user manual introduces repeating |usr_26.txt|. 1. Single repeats |single-repeat| 2. Multiple repeats |multi-repeat| 3. Complex repeats |complex-repeat| 4. Using Vim scripts |using-scripts| 5. Using Vim packages |packages| 6. Creating Vim packages |package-create| 7. Debugging scripts |debug-scripts| 8. Profiling |profiling| ============================================================================== 1. Single repeats *single-repeat* *.* . Repeat last change, with count replaced with [count]. Also repeat a yank command, when the 'y' flag is included in 'cpoptions'. Does not repeat a command-line command. Simple changes can be repeated with the "." command. Without a count, the count of the last change is used. If you enter a count, it will replace the last one. |v:count| and |v:count1| will be set. If the last change included a specification of a numbered register, the register number will be incremented. See |redo-register| for an example how to use this. Note that when repeating a command that used a Visual selection, the same SIZE of area is used, see |visual-repeat|. *@:* @: Repeat last command-line [count] times. {not available when compiled without the |+cmdline_hist| feature} ============================================================================== 2. Multiple repeats *multi-repeat* *:g* *:global* *E148* :[range]g[lobal]/{pattern}/[cmd] Execute the Ex command [cmd] (default ":p") on the lines within [range] where {pattern} matches. :[range]g[lobal]!/{pattern}/[cmd] Execute the Ex command [cmd] (default ":p") on the lines within [range] where {pattern} does NOT match. *:v* *:vglobal* :[range]v[global]/{pattern}/[cmd] Same as :g!. Example: > :g/^Obsolete/d _ Using the underscore after `:d` avoids clobbering registers or the clipboard. This also makes it faster. Instead of the '/' which surrounds the {pattern}, you can use any other single byte character, but not an alphabetic character, '\', '"', '|' or '!'. This is useful if you want to include a '/' in the search pattern or replacement string. For the definition of a pattern, see |pattern|. NOTE [cmd] may contain a range; see |collapse| and |edit-paragraph-join| for examples. The global commands work by first scanning through the [range] lines and marking each line where a match occurs (for a multi-line pattern, only the start of the match matters). In a second scan the [cmd] is executed for each marked line, as if the cursor was in that line. For ":v" and ":g!" the command is executed for each not marked line. If a line is deleted its mark disappears. The default for [range] is the whole buffer (1,$). Use "CTRL-C" to interrupt the command. If an error message is given for a line, the command for that line is aborted and the global command continues with the next marked or unmarked line. *E147* When the command is used recursively, it only works on one line. Giving a range is then not allowed. This is useful to find all lines that match a pattern and do not match another pattern: > :g/found/v/notfound/{cmd} This first finds all lines containing "found", but only executes {cmd} when there is no match for "notfound". Any Ex command can be used, see |ex-cmd-index|. To execute a Normal mode command, you can use the `:normal` command: > :g/pat/normal {commands} Make sure that {commands} ends with a whole command, otherwise Vim will wait for you to type the rest of the command for each match. The screen will not have been updated, so you don't know what you are doing. See |:normal|. The undo/redo command will undo/redo the whole global command at once. The previous context mark will only be set once (with "''" you go back to where the cursor was before the global command). The global command sets both the last used search pattern and the last used substitute pattern (this is vi compatible). This makes it easy to globally replace a string: :g/pat/s//PAT/g This replaces all occurrences of "pat" with "PAT". The same can be done with: :%s/pat/PAT/g Which is two characters shorter! When using "global" in Ex mode, a special case is using ":visual" as a command. This will move to a matching line, go to Normal mode to let you execute commands there until you use |Q| to return to Ex mode. This will be repeated for each matching line. While doing this you cannot use ":global". To abort this type CTRL-C twice. ============================================================================== 3. Complex repeats *complex-repeat* *q* *recording* q{0-9a-zA-Z"} Record typed characters into register {0-9a-zA-Z"} (uppercase to append). The 'q' command is disabled while executing a register, and it doesn't work inside a mapping and |:normal|. Note: If the register being used for recording is also used for |y| and |p| the result is most likely not what is expected, because the put will paste the recorded macro and the yank will overwrite the recorded macro. Note: The recording happens while you type, replaying the register happens as if the keys come from a mapping. This matters, for example, for undo, which only syncs when commands were typed. q Stops recording. (Implementation note: The 'q' that stops recording is not stored in the register, unless it was the result of a mapping) *@* @{0-9a-z".=*+} Execute the contents of register {0-9a-z".=*+} [count] times. Note that register '%' (name of the current file) and '#' (name of the alternate file) cannot be used. The register is executed like a mapping, that means that the difference between 'wildchar' and 'wildcharm' applies, and undo might not be synced in the same way. For "@=" you are prompted to enter an expression. The result of the expression is then executed. See also |@:|. *@@* *E748* @@ Repeat the previous @{0-9a-z":*} [count] times. *:@* :[addr]@{0-9a-z".=*+} Execute the contents of register {0-9a-z".=*+} as an Ex command. First set cursor at line [addr] (default is current line). When the last line in the register does not have a <CR> it will be added automatically when the 'e' flag is present in 'cpoptions'. For ":@=" the last used expression is used. The result of evaluating the expression is executed as an Ex command. Mappings are not recognized in these commands. When the |line-continuation| character (\) is present at the beginning of a line in a linewise register, then it is combined with the previous line. This is useful for yanking and executing parts of a Vim script. Future: Will execute the register for each line in the address range. :[addr]*{0-9a-z".=+} *:star-compatible* When '*' is present in 'cpoptions' |cpo-star|, use ":*" in the same way as ":@". This is NOT the default when 'nocompatible' is used. When the '*' flag is not present in 'cpoptions', ":*" is an alias for ":'<,'>", select the Visual area |:star|. *:@:* :[addr]@: Repeat last command-line. First set cursor at line [addr] (default is current line). :[addr]@ *:@@* :[addr]@@ Repeat the previous :@{register}. First set cursor at line [addr] (default is current line). ============================================================================== 4. Using Vim scripts *using-scripts* For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|. *:so* *:source* *load-vim-script* :so[urce] {file} Read Ex commands from {file}. These are commands that start with a ":". Triggers the |SourcePre| autocommand. *:source-range* :[range]so[urce] [++clear] Read Ex commands from the [range] of lines in the current buffer. When [range] is omitted read all lines. When sourcing commands from the current buffer, the same script-ID |<SID>| is used even if the buffer is sourced multiple times. If a buffer is sourced more than once, then the functions in the buffer are defined again. To source a range of lines that doesn't start with the |:vim9script| command in Vim9 script context, the |:vim9cmd| modifier can be used. If you use a Visual selection and type ":", the range in the form "'<,'>" can come before it: > :'<,'>vim9cmd source < Otherwise the range goes after the modifier and must have a colon prefixed, like all Vim9 ranges: > :vim9cmd :5,9source < When a range of lines in a buffer is sourced in the Vim9 script context, the previously defined script-local variables and functions are not cleared. This works like the range started with the ":vim9script noclear" command. The "++clear" argument can be used to clear the script-local variables and functions before sourcing the script. This works like the range started with the `:vim9script` command without the "noclear" argument. See |vim9-reload| for more information. Examples: > :4,5source :10,18source ++clear < *:source!* :so[urce]! {file} Read Vim commands from {file}. These are commands that are executed from Normal mode, like you type them. When used after |:global|, |:argdo|, |:windo|, |:bufdo|, in a loop or when another command follows the display won't be updated while executing the commands. Cannot be used in the |sandbox|. *:ru* *:runtime* :ru[ntime][!] [where] {file} .. Read Ex commands from {file} in each directory given by 'runtimepath' and/or 'packpath'. There is no error for non-existing files. Example: > :runtime syntax/c.vim < There can be multiple {file} arguments, separated by spaces. Each {file} is searched for in the first directory from 'runtimepath', then in the second directory, etc. Use a backslash to include a space inside {file} (although it's better not to use spaces in file names, it causes trouble). When [!] is included, all found files are sourced. When it is not included only the first found file is sourced. When [where] is omitted only 'runtimepath' is used. Other values: START search under "start" in 'packpath' OPT search under "opt" in 'packpath' PACK search under "start" and "opt" in 'packpath' ALL first use 'runtimepath', then search under "start" and "opt" in 'packpath' When {file} contains wildcards it is expanded to all matching files. Example: > :runtime! plugin/**/*.vim < This is what Vim uses to load the plugin files when starting up. This similar command: > :runtime plugin/**/*.vim < would source the first file only. When 'verbose' is one or higher, there is a message when no file could be found. When 'verbose' is two or higher, there is a message about each searched file. *:pa* *:packadd* *E919* :pa[ckadd][!] {name} Search for an optional plugin directory in 'packpath' and source any plugin files found. The directory must match: pack/*/opt/{name} ~ The directory is added to 'runtimepath' if it wasn't there yet. If the directory pack/*/opt/{name}/after exists it is added at the end of 'runtimepath'. If loading packages from "pack/*/start" was skipped, then this directory is searched first: pack/*/start/{name} ~ Note that {name} is the directory name, not the name of the .vim file. All the files matching the pattern pack/*/opt/{name}/plugin/**/*.vim ~ will be sourced. This allows for using subdirectories below "plugin", just like with plugins in 'runtimepath'. If the filetype detection was not enabled yet (this is usually done with a `syntax enable` or `filetype on` command in your .vimrc file), this will also look for "{name}/ftdetect/*.vim" files. When the optional ! is added no plugin files or ftdetect scripts are loaded, only the matching directories are added to 'runtimepath'. This is useful in your .vimrc. The plugins will then be loaded during initialization, see |load-plugins| (note that the loading order will be reversed, because each directory is inserted before others). Note that for ftdetect scripts to be loaded you will need to write `filetype plugin indent on` AFTER all `packadd!` commands. Also see |pack-add|. {only available when compiled with |+eval|} *:packl* *:packloadall* :packl[oadall][!] Load all packages in the "start" directory under each entry in 'packpath'. First all the directories found are added to 'runtimepath', then the plugins found in the directories are sourced. This allows for a plugin to depend on something of another plugin, e.g. an "autoload" directory. See |packload-two-steps| for how this can be useful. This is normally done automatically during startup, after loading your .vimrc file. With this command it can be done earlier. Packages will be loaded only once. Using `:packloadall` a second time will have no effect. When the optional ! is added this command will load packages even when done before. Note that when using `:packloadall` in the |vimrc| file, the 'runtimepath' option is updated, and later all plugins in 'runtimepath' will be loaded, which means they are loaded again. Plugins are expected to handle that. An error only causes sourcing the script where it happens to be aborted, further plugins will be loaded. See |packages|. {only available when compiled with |+eval|} :scripte[ncoding] [encoding] *:scripte* *:scriptencoding* *E167* Specify the character encoding used in the script. The following lines will be converted from [encoding] to the value of the 'encoding' option, if they are different. Examples: > scriptencoding iso-8859-5 scriptencoding cp932 < When [encoding] is empty, no conversion is done. This can be used to restrict conversion to a sequence of lines: > scriptencoding euc-jp ... lines to be converted ... scriptencoding ... not converted ... < When conversion isn't supported by the system, there is no error message and no conversion is done. When a line can't be converted there is no error and the original line is kept. Don't use "ucs-2" or "ucs-4", scripts cannot be in these encodings (they would contain NUL bytes). When a sourced script starts with a BOM (Byte Order Mark) in utf-8 format Vim will recognize it, no need to use ":scriptencoding utf-8" then. If you set the 'encoding' option in your |.vimrc|, `:scriptencoding` must be placed after that. E.g.: > set encoding=utf-8 scriptencoding utf-8 < :scriptv[ersion] {version} *:scriptv* *:scriptversion* *E999* *E984* *E1040* Specify the version of Vim for the lines that follow in the same file. Only applies at the toplevel of sourced scripts, not inside functions. If {version} is higher than what the current Vim version supports E999 will be given. You either need to rewrite the script to make it work with an older Vim version, or update Vim to a newer version. See |vimscript-version| for what changed between versions. :vim9s[cript] [noclear] *:vim9s* *:vim9script* Marks a script file as containing |Vim9-script| commands. Also see |vim9-namespace|. *E1038* Must be the first command in the file. *E1039* For [noclear] see |vim9-reload|. Without the |+eval| feature this changes the syntax for some commands. See |:vim9cmd| for executing one command with Vim9 syntax and semantics. *:scr* *:scriptnames* :scr[iptnames] List all sourced script names, in the order they were first encountered. The number is used for the script ID |<SID>|. For a script that was used with `import autoload` but was not actually sourced yet an "A" is shown after the script ID. For a script that was referred to by one name but after resolving symbolic links got sourced with another name the other script is after "->". E.g. "20->22" means script 20 was sourced as script 22. Also see `getscriptinfo()`. {not available when compiled without the |+eval| feature} :scr[iptnames][!] {scriptId} *:script* Edit script {scriptId}. Although ":scriptnames name" works, using ":script name" is recommended. When the current buffer can't be |abandon|ed and the ! is not present, the command fails. *:fini* *:finish* *E168* :fini[sh] Stop sourcing a script. Can only be used in a Vim script file. This is a quick way to skip the rest of the file. If it is used after a |:try| but before the matching |:finally| (if present), the commands following the ":finally" up to the matching |:endtry| are executed first. This process applies to all nested ":try"s in the script. The outermost ":endtry" then stops sourcing the script. All commands and command sequences can be repeated by putting them in a named register and then executing it. There are two ways to get the commands in the register: - Use the record command "q". You type the commands once, and while they are being executed they are stored in a register. Easy, because you can see what you are doing. If you make a mistake, "p"ut the register into the file, edit the command sequence, and then delete it into the register again. You can continue recording by appending to the register (use an uppercase letter). - Delete or yank the command sequence into the register. Often used command sequences can be put under a function key with the ':map' command. An alternative is to put the commands in a file, and execute them with the ':source!' command. Useful for long command sequences. Can be combined with the ':map' command to put complicated commands under a function key. The ':source' command reads Ex commands from a file or a buffer line by line. You will have to type any needed keyboard input. The ':source!' command reads from a script file character by character, interpreting each character as if you typed it. Example: When you give the ":!ls" command you get the |hit-enter| prompt. If you ':source' a file with the line "!ls" in it, you will have to type the <Enter> yourself. But if you ':source!' a file with the line ":!ls" in it, the next characters from that file are read until a <CR> is found. You will not have to type <CR> yourself, unless ":!ls" was the last line in the file. It is possible to put ':source[!]' commands in the script file, so you can make a top-down hierarchy of script files. The ':source' command can be nested as deep as the number of files that can be opened at one time (about 15). The ':source!' command can be nested up to 15 levels deep. You can use the "<sfile>" string (literally, this is not a special key) inside of the sourced file, in places where a file name is expected. It will be replaced by the file name of the sourced file. For example, if you have a "other.vimrc" file in the same directory as your ".vimrc" file, you can source it from your ".vimrc" file with this command: > :source <sfile>:h/other.vimrc In script files terminal-dependent key codes are represented by terminal-independent two character codes. This means that they can be used in the same way on different kinds of terminals. The first character of a key code is 0x80 or 128, shown on the screen as "~@". The second one can be found in the list |key-notation|. Any of these codes can also be entered with CTRL-V followed by the three digit decimal code. This does NOT work for the <t_xx> termcap codes, these can only be used in mappings. *:source_crnl* *W15* Win32: Files that are read with ":source" normally have <CR><NL> <EOL>s. These always work. If you are using a file with <NL> <EOL>s (for example, a file made on Unix), this will be recognized if 'fileformats' is not empty and the first line does not end in a <CR>. This fails if the first line has something like ":map <F1> :help^M", where "^M" is a <CR>. If the first line ends in a <CR>, but following ones don't, you will get an error message, because the <CR> from the first lines will be lost. Mac Classic: Files that are read with ":source" normally have <CR> <EOL>s. These always work. If you are using a file with <NL> <EOL>s (for example, a file made on Unix), this will be recognized if 'fileformats' is not empty and the first line does not end in a <CR>. Be careful not to use a file with <NL> linebreaks which has a <CR> in first line. On other systems, Vim expects ":source"ed files to end in a <NL>. These always work. If you are using a file with <CR><NL> <EOL>s (for example, a file made on MS-Windows), all lines will have a trailing <CR>. This may cause problems for some commands (e.g., mappings). There is no automatic <EOL> detection, because it's common to start with a line that defines a mapping that ends in a <CR>, which will confuse the automaton. *line-continuation* Long lines in a ":source"d Ex command script file can be split by inserting a line continuation symbol "\" (backslash) at the start of the next line. There can be white space before the backslash, which is ignored. Example: the lines > :set comments=sr:/*,mb:*,el:*/, \://, \b:#, \:%, \n:>, \fb:- are interpreted as if they were given in one line: :set comments=sr:/*,mb:*,el:*/,://,b:#,:%,n:>,fb:- All leading whitespace characters in the line before a backslash are ignored. Note however that trailing whitespace in the line before it cannot be inserted freely; it depends on the position where a command is split up whether additional whitespace is allowed or not. When a space is required it's best to put it right after the backslash. A space at the end of a line is hard to see and may be accidentally deleted. > :syn match Comment \ "very long regexp" \ keepend In |Vim9| script the backslash can often be omitted, but not always. See |vim9-line-continuation|. There is a problem with the ":append" and ":insert" commands: > :1append \asdf . The backslash is seen as a line-continuation symbol, thus this results in the command: > :1appendasdf . To avoid this, add the 'C' flag to the 'cpoptions' option: > :set cpo+=C :1append \asdf . :set cpo-=C Note that when the commands are inside a function, you need to add the 'C' flag when defining the function, it is not relevant when executing it. > :set cpo+=C :function Foo() :1append \asdf . :endfunction :set cpo-=C < *line-continuation-comment* To add a comment in between the lines start with '"\ '. Notice the space after the backslash. Example: > let array = [ "\ first entry comment \ 'first', "\ second entry comment \ 'second', \ ] Rationale: Most programs work with a trailing backslash to indicate line continuation. Using this in Vim would cause incompatibility with Vi. For example for this Vi mapping: > :map xx asdf\ < Therefore the unusual leading backslash is used. Starting a comment in a continuation line results in all following continuation lines to be part of the comment. Since it was like this for a long time, when making it possible to add a comment halfway a sequence of continuation lines, it was not possible to use \", since that was a valid continuation line. Using '"\ ' comes closest, even though it may look a bit weird. Requiring the space after the backslash is to make it very unlikely this is a normal comment line. ============================================================================== 5. Using Vim packages *packages* A Vim package is a directory that contains one or more plugins. The advantages over normal plugins: - A package can be downloaded as an archive and unpacked in its own directory. Thus the files are not mixed with files of other plugins. That makes it easy to update and remove. - A package can be a git, mercurial, etc. repository. That makes it really easy to update. - A package can contain multiple plugins that depend on each other. - A package can contain plugins that are automatically loaded on startup and ones that are only loaded when needed with `:packadd`. Using a package and loading automatically ~ Let's assume your Vim files are in the "~/.vim" directory and you want to add a package from a zip archive "/tmp/foopack.zip": % mkdir -p ~/.vim/pack/foo % cd ~/.vim/pack/foo % unzip /tmp/foopack.zip The directory name "foo" is arbitrary, you can pick anything you like. You would now have these files under ~/.vim: pack/foo/README.txt pack/foo/start/foobar/plugin/foo.vim pack/foo/start/foobar/syntax/some.vim pack/foo/opt/foodebug/plugin/debugger.vim When Vim starts up, after processing your .vimrc, it scans all directories in 'packpath' for plugins under the "pack/*/start" directory. First all those directories are added to 'runtimepath'. Then all the plugins are loaded. See |packload-two-steps| for how these two steps can be useful. To allow for calling into package functionality while parsing your .vimrc, |:colorscheme| and |autoload| will both automatically search under 'packpath' as well in addition to 'runtimepath'. See the documentation for each for details. In the example Vim will find "pack/foo/start/foobar/plugin/foo.vim" and adds "~/.vim/pack/foo/start/foobar" to 'runtimepath'. If the "foobar" plugin kicks in and sets the 'filetype' to "some", Vim will find the syntax/some.vim file, because its directory is in 'runtimepath'. Vim will also load ftdetect files, if there are any. Note that the files under "pack/foo/opt" are not loaded automatically, only the ones under "pack/foo/start". See |pack-add| below for how the "opt" directory is used. Loading packages automatically will not happen if loading plugins is disabled, see |load-plugins|. To load packages earlier, so that 'runtimepath' gets updated: > :packloadall This also works when loading plugins is disabled. The automatic loading will only happen once. If the package has an "after" directory, that directory is added to the end of 'runtimepath', so that anything there will be loaded later. Using a single plugin and loading it automatically ~ If you don't have a package but a single plugin, you need to create the extra directory level: % mkdir -p ~/.vim/pack/foo/start/foobar % cd ~/.vim/pack/foo/start/foobar % unzip /tmp/someplugin.zip You would now have these files: pack/foo/start/foobar/plugin/foo.vim pack/foo/start/foobar/syntax/some.vim From here it works like above. Optional plugins ~ *pack-add* To load an optional plugin from a pack use the `:packadd` command: > :packadd foodebug This searches for "pack/*/opt/foodebug" in 'packpath' and will find ~/.vim/pack/foo/opt/foodebug/plugin/debugger.vim and source it. This could be done if some conditions are met. For example, depending on whether Vim supports a feature or a dependency is missing. You can also load an optional plugin at startup, by putting this command in your |.vimrc|: > :packadd! foodebug The extra "!" is so that the plugin isn't loaded if Vim was started with |--noplugin|. It is perfectly normal for a package to only have files in the "opt" directory. You then need to load each plugin when you want to use it. Where to put what ~ Since color schemes, loaded with `:colorscheme`, are found below "pack/*/start" and "pack/*/opt", you could put them anywhere. We recommend you put them below "pack/*/opt", for example ".vim/pack/mycolors/opt/dark/colors/very_dark.vim". Filetype plugins should go under "pack/*/start", so that they are always found. Unless you have more than one plugin for a file type and want to select which one to load with `:packadd`. E.g. depending on the compiler version: > if foo_compiler_version > 34 packadd foo_new else packadd foo_old endif The "after" directory is most likely not useful in a package. It's not disallowed though. ============================================================================== 6. Creating Vim packages *package-create* This assumes you write one or more plugins that you distribute as a package. If you have two unrelated plugins you would use two packages, so that Vim users can choose what they include or not. Or you can decide to use one package with optional plugins, and tell the user to add the preferred ones with `:packadd`. Decide how you want to distribute the package. You can create an archive or you could use a repository. An archive can be used by more users, but is a bit harder to update to a new version. A repository can usually be kept up-to-date easily, but it requires a program like "git" to be available. You can do both, github can automatically create an archive for a release. Your directory layout would be like this: start/foobar/plugin/foo.vim " always loaded, defines commands start/foobar/plugin/bar.vim " always loaded, defines commands start/foobar/autoload/foo.vim " loaded when foo command used start/foobar/doc/foo.txt " help for foo.vim start/foobar/doc/tags " help tags opt/fooextra/plugin/extra.vim " optional plugin, defines commands opt/fooextra/autoload/extra.vim " loaded when extra command used opt/fooextra/doc/extra.txt " help for extra.vim opt/fooextra/doc/tags " help tags This allows for the user to do: > mkdir ~/.vim/pack cd ~/.vim/pack git clone https://github.com/you/foobar.git myfoobar Here "myfoobar" is a name that the user can choose, the only condition is that it differs from other packages. In your documentation you explain what the plugins do, and tell the user how to load the optional plugin: > :packadd! fooextra You could add this packadd command in one of your plugins, to be executed when the optional plugin is needed. Run the `:helptags` command to generate the doc/tags file. Including this generated file in the package means that the user can drop the package in the pack directory and the help command works right away. Don't forget to re-run the command after changing the plugin help: > :helptags path/start/foobar/doc :helptags path/opt/fooextra/doc Dependencies between plugins ~ *packload-two-steps* Suppose you have two plugins that depend on the same functionality. You can put the common functionality in an autoload directory, so that it will be found automatically. Your package would have these files: pack/foo/start/one/plugin/one.vim > call foolib#getit() < pack/foo/start/two/plugin/two.vim > call foolib#getit() < pack/foo/start/lib/autoload/foolib.vim > func foolib#getit() This works, because loading packages will first add all found directories to 'runtimepath' before sourcing the plugins. ============================================================================== 7. Debugging scripts *debug-scripts* Besides the obvious messages that you can add to your scripts to find out what they are doing, Vim offers a debug mode. This allows you to step through a sourced file or user function and set breakpoints. NOTE: The debugging mode is far from perfect. Debugging will have side effects on how Vim works. You cannot use it to debug everything. For example, the display is messed up by the debugging messages. An alternative to debug mode is setting the 'verbose' option. With a bigger number it will give more verbose messages about what Vim is doing. STARTING DEBUG MODE *debug-mode* To enter debugging mode use one of these methods: 1. Start Vim with the |-D| argument: > vim -D file.txt < Debugging will start as soon as the first vimrc file is sourced. This is useful to find out what is happening when Vim is starting up. A side effect is that Vim will switch the terminal mode before initialisations have finished, with unpredictable results. For a GUI-only version (Windows, Macintosh) the debugging will start as soon as the GUI window has been opened. To make this happen early, add a ":gui" command in the vimrc file. *:debug* 2. Run a command with ":debug" prepended. Debugging will only be done while this command executes. Useful for debugging a specific script or user function. And for scripts and functions used by autocommands. Example: > :debug edit test.txt.gz 3. Set a breakpoint in a sourced file or user function. You could do this in the command line: > vim -c "breakadd file */explorer.vim" . < This will run Vim and stop in the first line of the "explorer.vim" script. Breakpoints can also be set while in debugging mode. In debugging mode every executed command is displayed before it is executed. Comment lines, empty lines and lines that are not executed are skipped. When a line contains two commands, separated by "|", each command will be displayed separately. DEBUG MODE Once in debugging mode, the usual Ex commands can be used. For example, to inspect the value of a variable: > echo idx When inside a user function, this will print the value of the local variable "idx". Prepend "g:" to get the value of a global variable: > echo g:idx All commands are executed in the context of the current function or script. You can also set options, for example setting or resetting 'verbose' will show what happens, but you might want to set it just before executing the lines you are interested in: > :set verbose=20 Commands that require updating the screen should be avoided, because their effect won't be noticed until after leaving debug mode. For example: > :help won't be very helpful. There is a separate command-line history for debug mode. NOTE: In Vim9 script, if a command is written at the script level and continues on the next line, not using the old way with a backslash for line continuation, only the first line is printed before the debugging prompt. The line number for a function line is relative to the start of the function. If you have trouble figuring out where you are, edit the file that defines the function in another Vim, search for the start of the function and do "99j". Replace "99" with the line number. Additionally, these commands can be used: *>cont* cont Continue execution until the next breakpoint is hit. *>quit* quit Abort execution. This is like using CTRL-C, some things might still be executed, doesn't abort everything. Still stops at the next breakpoint. *>next* next Execute the command and come back to debug mode when it's finished. This steps over user function calls and sourced files. *>step* step Execute the command and come back to debug mode for the next command. This steps into called user functions and sourced files. *>interrupt* interrupt This is like using CTRL-C, but unlike ">quit" comes back to debug mode for the next command that is executed. Useful for testing |:finally| and |:catch| on interrupt exceptions. *>finish* finish Finish the current script or user function and come back to debug mode for the command after the one that sourced or called it. *>bt* *>backtrace* *>where* backtrace Show the call stacktrace for current debugging session. bt where *>frame* frame N Goes to N backtrace level. + and - signs make movement relative. E.g., ":frame +3" goes three frames up. *>up* up Goes one level up from call stacktrace. *>down* down Goes one level down from call stacktrace. About the additional commands in debug mode: - There is no command-line completion for them, you get the completion for the normal Ex commands only. - You can shorten them, up to a single character, unless more than one command starts with the same letter. "f" stands for "finish", use "fr" for "frame". - Hitting <CR> will repeat the previous one. When doing another command, this is reset (because it's not clear what you want to repeat). - When you want to use the Ex command with the same name, prepend a colon: ":cont", ":next", ":finish" (or shorter). *vim9-debug* When debugging a compiled :def function, "step" will stop before every executed line, not every single instruction. Thus it works mostly like a not compiled function. Access to local variables is limited you can use: > echo varname But not much else. When executing a command that is not a specific bytecode instruction but executed like a normal Ex command, "step" will stop once in the compiled context, where local variables can be inspected, and once just before executing the command. In a :def function variables that haven't been declared yet cannot be inspected. Variables that have been declared can be inspected, also when the block they were declared in has finished. In commands this would not be possible, thus is slightly misleading (but can be useful). The backtrace shows the hierarchy of function calls, e.g.: >bt ~ 3 function One[3] ~ 2 Two[3] ~ ->1 Three[3] ~ 0 Four ~ line 1: let four = 4 ~ The "->" points to the current frame. Use "up", "down" and "frame N" to select another frame. In the current frame you can evaluate the local function variables. There is no way to see the command at the current line yet. DEFINING BREAKPOINTS *:breaka* *:breakadd* :breaka[dd] func [lnum] {name} Set a breakpoint in a function. Example: > :breakadd func Explore < Doesn't check for a valid function name, thus the breakpoint can be set before the function is defined. :breaka[dd] file [lnum] {name} Set a breakpoint in a sourced file. Example: > :breakadd file 43 .vimrc :breaka[dd] here Set a breakpoint in the current line of the current file. Like doing: > :breakadd file <cursor-line> <current-file> < Note that this only works for commands that are executed when sourcing the file, not for a function defined in that file. :breaka[dd] expr {expression} Sets a breakpoint, that will break whenever the {expression} evaluates to a different value. Example: > :breakadd expr g:lnum < Will break, whenever the global variable lnum changes. Errors in evaluation are suppressed, you can use the name of a variable that does not exist yet. This also means you will not notice anything if the expression has a mistake. Note if you watch a |script-variable| this will break when switching scripts, since the script variable is only valid in the script where it has been defined and if that script is called from several other scripts, this will stop whenever that particular variable will become visible or inaccessible again. The [lnum] is the line number of the breakpoint. Vim will stop at or after this line. When omitted line 1 is used. *:debug-name* {name} is a pattern that is matched with the file or function name. The pattern is like what is used for autocommands. There must be a full match (as if the pattern starts with "^" and ends in "$"). A "*" matches any sequence of characters. 'ignorecase' is not used, but "\c" can be used in the pattern to ignore case |/\c|. Don't include the () for the function name! The match for sourced scripts is done against the full file name. If no path is specified the current directory is used. Examples: > breakadd file explorer.vim matches "explorer.vim" in the current directory. > breakadd file *explorer.vim matches ".../plugin/explorer.vim", ".../plugin/iexplorer.vim", etc. > breakadd file */explorer.vim matches ".../plugin/explorer.vim" and "explorer.vim" in any other directory. The match for functions is done against the name as it's shown in the output of ":function". However, for local functions the script-specific prefix such as "<SNR>99_" is ignored to make it easier to match script-local functions without knowing the ID of the script. Note that functions are first loaded and later executed. When they are loaded the "file" breakpoints are checked, when they are executed the "func" breakpoints. DELETING BREAKPOINTS *:breakd* *:breakdel* *E161* :breakd[el] {nr} Delete breakpoint {nr}. Use |:breaklist| to see the number of each breakpoint. :breakd[el] * Delete all breakpoints. :breakd[el] func [lnum] {name} Delete a breakpoint in a function. :breakd[el] file [lnum] {name} Delete a breakpoint in a sourced file. :breakd[el] here Delete a breakpoint at the current line of the current file. When [lnum] is omitted, the first breakpoint in the function or file is deleted. The {name} must be exactly the same as what was typed for the ":breakadd" command. "explorer", "*explorer.vim" and "*explorer*" are different. LISTING BREAKPOINTS *:breakl* *:breaklist* :breakl[ist] List all breakpoints. OBSCURE *:debugg* *:debuggreedy* :debugg[reedy] Read debug mode commands from the normal input stream, instead of getting them directly from the user. Only useful for test scripts. Example: > echo 'q^Mq' | vim -e -s -c debuggreedy -c 'breakadd file script.vim' -S script.vim :0debugg[reedy] Undo ":debuggreedy": get debug mode commands directly from the user, don't use typeahead for debug commands. ============================================================================== 8. Profiling *profile* *profiling* Profiling means that Vim measures the time that is spent on executing functions and/or scripts. The |+profile| feature is required for this. It is included when Vim was compiled with "huge" features. You can also use the |reltime()| function to measure time. This only requires the |+reltime| feature, which is present in more builds. For profiling syntax highlighting see |:syntime|. For example, to profile the one_script.vim script file: > :profile start /tmp/one_script_profile :profile file one_script.vim :source one_script.vim :exit :prof[ile] start {fname} *:prof* *:profile* *E750* Start profiling, write the output in {fname} upon exit or when a `:profile stop` or `:profile dump` command is invoked. "~/" and environment variables in {fname} will be expanded. If {fname} already exists it will be silently overwritten. The variable |v:profiling| is set to one. :prof[ile] stop Write the collected profiling information to the logfile and stop profiling. You can use the `:profile start` command to clear the profiling statistics and start profiling again. :prof[ile] pause Don't profile until the following `:profile continue`. Can be used when doing something that should not be counted (e.g., an external command). Does not nest. :prof[ile] continue Continue profiling after `:profile pause`. :prof[ile] func {pattern} Profile function that matches the pattern {pattern}. See |:debug-name| for how {pattern} is used. :prof[ile][!] file {pattern} Profile script file that matches the pattern {pattern}. See |:debug-name| for how {pattern} is used. This only profiles the script itself, not the functions defined in it. When the [!] is added then all functions defined in the script will also be profiled. Note that profiling only starts when the script is loaded after this command. A :profile command in the script itself won't work. :prof[ile] dump Write the current state of profiling to the logfile immediately. After running this command, Vim continues to collect the profiling statistics. :profd[el] ... *:profd* *:profdel* Stop profiling for the arguments specified. See |:breakdel| for the arguments. Examples: > profdel func MyFunc profdel file MyScript.vim profdel here You must always start with a ":profile start fname" command. The resulting file is written when Vim exits. For example, to profile one specific function: > profile start /tmp/vimprofile profile func MyFunc Here is an example of the output, with line numbers prepended for the explanation: 1 FUNCTION Test2() ~ 2 Called 1 time ~ 3 Total time: 0.155251 ~ 4 Self time: 0.002006 ~ 5 ~ 6 count total (s) self (s) ~ 7 9 0.000096 for i in range(8) ~ 8 8 0.153655 0.000410 call Test3() ~ 9 8 0.000070 endfor ~ 10 " Ask a question ~ 11 1 0.001341 echo input("give me an answer: ") ~ The header (lines 1-4) gives the time for the whole function. The "Total" time is the time passed while the function was executing. The "Self" time is the "Total" time reduced by time spent in: - other user defined functions - sourced scripts - executed autocommands - external (shell) commands Lines 7-11 show the time spent in each executed line. Lines that are not executed do not count. Thus a comment line is never counted. The Count column shows how many times a line was executed. Note that the "for" command in line 7 is executed one more time as the following lines. That is because the line is also executed to detect the end of the loop. The time Vim spends waiting for user input isn't counted at all. Thus how long you take to respond to the input() prompt is irrelevant. Profiling should give a good indication of where time is spent, but keep in mind there are various things that may clobber the results: - The accuracy of the time measured depends on the gettimeofday(), or clock_gettime if available, system function. The accuracy ranges from 1/100 second to nanoseconds. With clock_gettime the times are displayed in nanoseconds, otherwise microseconds. You can use `has("prof_nsec")`. - Real elapsed time is measured, if other processes are busy they may cause delays at unpredictable moments. You may want to run the profiling several times and use the lowest results. - If you have several commands in one line you only get one time. Split the line to see the time for the individual commands. - The time of the lines added up is mostly less than the time of the whole function. There is some overhead in between. - Functions that are deleted before Vim exits will not produce profiling information. You can check the |v:profiling| variable if needed: > :if !v:profiling : delfunc MyFunc :endif < - Profiling may give weird results on multi-processor systems, when sleep mode kicks in or the processor frequency is reduced to save power. - The "self" time is wrong when a function is used recursively. vim:tw=78:ts=8:noet:ft=help:norl: