Update runtime files
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
*vim9.txt* For Vim version 8.2. Last change: 2022 Mar 08
|
||||
*vim9.txt* For Vim version 8.2. Last change: 2022 Mar 18
|
||||
|
||||
|
||||
VIM REFERENCE MANUAL by Bram Moolenaar
|
||||
@ -995,6 +995,11 @@ The values can also be useful as the default value for an argument: >
|
||||
if b == null_blob
|
||||
# b argument was not given
|
||||
|
||||
It is possible to compare `null` with any value, this will not give a type
|
||||
error. However, comparing `null` with a number, float or bool will always
|
||||
result in `false`. This is different from legacy script, where comparing
|
||||
`null` with zero or `false` would return `true`.
|
||||
|
||||
When converting a boolean to a string `false` and `true` are used, not
|
||||
`v:false` and `v:true` like in legacy script. `v:none` has no `none`
|
||||
replacement, it has no equivalent in other languages.
|
||||
@ -1234,6 +1239,11 @@ Closures defined in a loop will share the same context. For example: >
|
||||
endfor
|
||||
echo range(5)->map((i, _) => flist[i]())
|
||||
# Result: [4, 4, 4, 4, 4]
|
||||
< *E1271*
|
||||
A closure must be compiled in the context that it is defined in, so that
|
||||
variables in that context can be found. This mostly happens correctly, except
|
||||
when a function is marked for debugging with `breakadd` after it was compiled.
|
||||
Make sure the define the breakpoint before compiling the outerh function.
|
||||
|
||||
The "inloop" variable will exist only once, all closures put in the list refer
|
||||
to the same instance, which in the end will have the value 4. This is
|
||||
@ -1739,7 +1749,8 @@ actually needed. Using the autoload mechanism is recommended:
|
||||
prefix is obtained from the file name, as you would to manually in a
|
||||
legacy autoload script. Thus the exported function can be found with
|
||||
"for#search#Stuff", but you would normally use `import autoload` and not
|
||||
use the prefix.
|
||||
use the prefix (which has the side effect of loading the autoload script
|
||||
when compiling a function that encounters this name).
|
||||
|
||||
You can split up the functionality and import other scripts from the
|
||||
autoload script as you like. This way you can share code between plugins.
|
||||
@ -1751,7 +1762,17 @@ script context of where the mapping was defined.
|
||||
When compiling a `:def` function and a function in an autoload script is
|
||||
encountered, the script is not loaded until the `:def` function is called.
|
||||
This also means you get any errors only at runtime, since the argument and
|
||||
return types are not known yet.
|
||||
return types are not known yet. If you would use the name with '#' characters
|
||||
then the autoload script IS loaded.
|
||||
|
||||
Be careful to not refer to an item in an autoload script that does trigger
|
||||
loading it unintentionally. For example, when setting an option that takes a
|
||||
function name, make sure to use a string, not a function reference: >
|
||||
import autoload 'qftf.vim'
|
||||
&quickfixtextfunc = 'qftf.Func' # autoload script NOT loaded
|
||||
&quickfixtextfunc = qftf.Func # autoload script IS loaded
|
||||
On the other hand, it can be useful to load the script early, at a time when
|
||||
any errors should be given.
|
||||
|
||||
For testing the |test_override()| function can be used to have the
|
||||
`import autoload` load the script right away, so that the items and types can
|
||||
|
||||
Reference in New Issue
Block a user