thac0/vim
1
0
Fork 0
forked from aniani/vim
Code Activity

Update runtime files, new color schemes

Browse Source
This commit is contained in:
Bram Moolenaar
2022-05-14 13:33:50 +01:00
parent 2e444bbef0
commit 30ab04e16e
34 changed files with 7441 additions and 2026 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
runtime/doc/Makefile
View File

@@ -144,7 +144,9 @@ DOCS = \
usr_43.txt \
usr_44.txt \
usr_45.txt \
usr_46.txt \
usr_50.txt \
usr_51.txt \
usr_52.txt \
usr_90.txt \
usr_toc.txt \
various.txt \
@@ -290,7 +292,9 @@ HTMLS = \
usr_43.html \
usr_44.html \
usr_45.html \
usr_46.html \
usr_50.html \
usr_51.html \
usr_52.html \
usr_90.html \
usr_toc.html \
various.html \

6
runtime/doc/eval.txt
View File

@@ -1,4 +1,4 @@
*eval.txt* For Vim version 8.2. Last change: 2022 May 11
*eval.txt* For Vim version 8.2. Last change: 2022 May 13
VIM REFERENCE MANUAL by Bram Moolenaar
@@ -2960,7 +2960,7 @@ the "autoload" directory in 'runtimepath'.
Using an autocommand ~
This is introduced in the user manual, section |41.14|.
This is introduced in the user manual, section |51.4|.
The autocommand is useful if you have a plugin that is a long Vim script file.
You can define the autocommand and quickly quit the script with `:finish`.
@@ -2978,7 +2978,7 @@ The file "~/vim/bufnetfuncs.vim" should then define functions that start with
Using an autoload script ~
*autoload* *E746*
This is introduced in the user manual, section |41.15|.
This is introduced in the user manual, section |51.5|.
Using a script in the "autoload" directory is simpler, but requires using
exactly the right file name. A function that can be autoloaded has a name

9
runtime/doc/help.txt
View File

@@ -1,4 +1,4 @@
*help.txt* For Vim version 8.2. Last change: 2022 Feb 26
*help.txt* For Vim version 8.2. Last change: 2022 May 13
VIM - main help file
k
@@ -88,12 +88,15 @@ Tuning Vim ~
|usr_43.txt| Using filetypes
|usr_44.txt| Your own syntax highlighted
|usr_45.txt| Select your language
|usr_46.txt| Write plugins using Vim9 script
Writing Vim scripts ~
|usr_50.txt| Advanced Vim script writing
|usr_51.txt| Create a plugin
|usr_52.txt| Write plugins using Vim9 script
Making Vim Run ~
|usr_90.txt| Installing Vim
REFERENCE MANUAL: These files explain every detail of Vim. *reference_toc*
General subjects ~

67
runtime/doc/tags
View File

@@ -1915,12 +1915,6 @@ $VIM_POSIX vi_diff.txt /*$VIM_POSIX*
40.3 usr_40.txt /*40.3*
41.1 usr_41.txt /*41.1*
41.10 usr_41.txt /*41.10*
41.11 usr_41.txt /*41.11*
41.12 usr_41.txt /*41.12*
41.13 usr_41.txt /*41.13*
41.14 usr_41.txt /*41.14*
41.15 usr_41.txt /*41.15*
41.16 usr_41.txt /*41.16*
41.2 usr_41.txt /*41.2*
41.3 usr_41.txt /*41.3*
41.4 usr_41.txt /*41.4*
@@ -1953,10 +1947,17 @@ $VIM_POSIX vi_diff.txt /*$VIM_POSIX*
45.3 usr_45.txt /*45.3*
45.4 usr_45.txt /*45.4*
45.5 usr_45.txt /*45.5*
46.1 usr_46.txt /*46.1*
46.2 usr_46.txt /*46.2*
46.3 usr_46.txt /*46.3*
46.? usr_46.txt /*46.?*
50.1 usr_50.txt /*50.1*
51.1 usr_51.txt /*51.1*
51.2 usr_51.txt /*51.2*
51.3 usr_51.txt /*51.3*
51.4 usr_51.txt /*51.4*
51.5 usr_51.txt /*51.5*
51.6 usr_51.txt /*51.6*
52.1 usr_52.txt /*52.1*
52.2 usr_52.txt /*52.2*
52.3 usr_52.txt /*52.3*
52.4 usr_52.txt /*52.4*
8g8 various.txt /*8g8*
90.1 usr_90.txt /*90.1*
90.2 usr_90.txt /*90.2*
@@ -2026,7 +2027,7 @@ $VIM_POSIX vi_diff.txt /*$VIM_POSIX*
:Break terminal.txt /*:Break*
:Cfilter quickfix.txt /*:Cfilter*
:Clear terminal.txt /*:Clear*
:CompilerSet usr_41.txt /*:CompilerSet*
:CompilerSet usr_51.txt /*:CompilerSet*
:Continue terminal.txt /*:Continue*
:DiffOrig diff.txt /*:DiffOrig*
:DoMatchParen pi_paren.txt /*:DoMatchParen*
@@ -6493,7 +6494,7 @@ dircolors.vim syntax.txt /*dircolors.vim*
dis motion.txt /*dis*
disable-menus gui.txt /*disable-menus*
discard editing.txt /*discard*
distribute-script usr_41.txt /*distribute-script*
distribute-script usr_51.txt /*distribute-script*
distribution intro.txt /*distribution*
diw motion.txt /*diw*
dl change.txt /*dl*
@@ -7028,11 +7029,11 @@ ft_rust.txt ft_rust.txt /*ft_rust.txt*
ft_sql.txt ft_sql.txt /*ft_sql.txt*
ftdetect filetype.txt /*ftdetect*
ftp pi_netrw.txt /*ftp*
ftplugin usr_41.txt /*ftplugin*
ftplugin usr_51.txt /*ftplugin*
ftplugin-docs filetype.txt /*ftplugin-docs*
ftplugin-name usr_05.txt /*ftplugin-name*
ftplugin-overrule filetype.txt /*ftplugin-overrule*
ftplugin-special usr_41.txt /*ftplugin-special*
ftplugin-special usr_51.txt /*ftplugin-special*
ftplugins usr_05.txt /*ftplugins*
fullcommand() builtin.txt /*fullcommand()*
funcref() builtin.txt /*funcref()*
@@ -8860,8 +8861,8 @@ plaintex.vim syntax.txt /*plaintex.vim*
plsql ft_sql.txt /*plsql*
plugin usr_05.txt /*plugin*
plugin-details filetype.txt /*plugin-details*
plugin-filetype usr_41.txt /*plugin-filetype*
plugin-special usr_41.txt /*plugin-special*
plugin-filetype usr_51.txt /*plugin-filetype*
plugin-special usr_51.txt /*plugin-special*
plugin_name.txt helphelp.txt /*plugin_name.txt*
pmbcs-option print.txt /*pmbcs-option*
pmbfn-option print.txt /*pmbfn-option*
@@ -9409,7 +9410,7 @@ sound_playevent() builtin.txt /*sound_playevent()*
sound_playfile() builtin.txt /*sound_playfile()*
sound_stop() builtin.txt /*sound_stop()*
soundfold() builtin.txt /*soundfold()*
source-vim9-script usr_46.txt /*source-vim9-script*
source-vim9-script usr_52.txt /*source-vim9-script*
space intro.txt /*space*
spec-customizing pi_spec.txt /*spec-customizing*
spec-how-to-use-it pi_spec.txt /*spec-how-to-use-it*
@@ -10171,8 +10172,8 @@ type-casting vim9.txt /*type-casting*
type-checking vim9.txt /*type-checking*
type-inference vim9.txt /*type-inference*
type-mistakes tips.txt /*type-mistakes*
typecorrect-settings usr_41.txt /*typecorrect-settings*
typecorrect.txt usr_41.txt /*typecorrect.txt*
typecorrect-settings usr_51.txt /*typecorrect-settings*
typecorrect.txt usr_51.txt /*typecorrect.txt*
typename() builtin.txt /*typename()*
u undo.txt /*u*
uganda uganda.txt /*uganda*
@@ -10189,8 +10190,8 @@ undo-remarks undo.txt /*undo-remarks*
undo-tree undo.txt /*undo-tree*
undo-two-ways undo.txt /*undo-two-ways*
undo.txt undo.txt /*undo.txt*
undo_ftplugin usr_41.txt /*undo_ftplugin*
undo_indent usr_41.txt /*undo_indent*
undo_ftplugin usr_51.txt /*undo_ftplugin*
undo_indent usr_51.txt /*undo_indent*
undofile() builtin.txt /*undofile()*
undotree() builtin.txt /*undotree()*
unicode mbyte.txt /*unicode*
@@ -10200,7 +10201,7 @@ unlisted-buffer windows.txt /*unlisted-buffer*
up-down-motions motion.txt /*up-down-motions*
uppercase change.txt /*uppercase*
urxvt-mouse options.txt /*urxvt-mouse*
use-cpo-save usr_41.txt /*use-cpo-save*
use-cpo-save usr_51.txt /*use-cpo-save*
use-visual-cmds version4.txt /*use-visual-cmds*
useful-mappings tips.txt /*useful-mappings*
usenet intro.txt /*usenet*
@@ -10208,7 +10209,7 @@ user-cmd-ambiguous map.txt /*user-cmd-ambiguous*
user-commands map.txt /*user-commands*
user-functions eval.txt /*user-functions*
user-manual usr_toc.txt /*user-manual*
using-<Plug> usr_41.txt /*using-<Plug>*
using-<Plug> usr_51.txt /*using-<Plug>*
using-menus gui.txt /*using-menus*
using-scripts repeat.txt /*using-scripts*
using-xxd tips.txt /*using-xxd*
@@ -10244,7 +10245,9 @@ usr_42.txt usr_42.txt /*usr_42.txt*
usr_43.txt usr_43.txt /*usr_43.txt*
usr_44.txt usr_44.txt /*usr_44.txt*
usr_45.txt usr_45.txt /*usr_45.txt*
usr_46.txt usr_46.txt /*usr_46.txt*
usr_50.txt usr_50.txt /*usr_50.txt*
usr_51.txt usr_51.txt /*usr_51.txt*
usr_52.txt usr_52.txt /*usr_52.txt*
usr_90.txt usr_90.txt /*usr_90.txt*
usr_toc.txt usr_toc.txt /*usr_toc.txt*
utf-8 mbyte.txt /*utf-8*
@@ -10570,7 +10573,7 @@ vim9-const vim9.txt /*vim9-const*
vim9-curly vim9.txt /*vim9-curly*
vim9-debug repeat.txt /*vim9-debug*
vim9-declaration vim9.txt /*vim9-declaration*
vim9-declarations usr_46.txt /*vim9-declarations*
vim9-declarations usr_52.txt /*vim9-declarations*
vim9-differences vim9.txt /*vim9-differences*
vim9-export vim9.txt /*vim9-export*
vim9-final vim9.txt /*vim9-final*
@@ -10589,7 +10592,7 @@ vim9-rationale vim9.txt /*vim9-rationale*
vim9-reload vim9.txt /*vim9-reload*
vim9-s-namespace vim9.txt /*vim9-s-namespace*
vim9-scopes vim9.txt /*vim9-scopes*
vim9-script-intro usr_46.txt /*vim9-script-intro*
vim9-script-intro usr_52.txt /*vim9-script-intro*
vim9-types vim9.txt /*vim9-types*
vim9-unpack-ignore vim9.txt /*vim9-unpack-ignore*
vim9-user-command vim9.txt /*vim9-user-command*
@@ -10772,15 +10775,15 @@ workshop workshop.txt /*workshop*
workshop-support workshop.txt /*workshop-support*
workshop.txt workshop.txt /*workshop.txt*
wrap-off intro.txt /*wrap-off*
write-compiler-plugin usr_41.txt /*write-compiler-plugin*
write-compiler-plugin usr_51.txt /*write-compiler-plugin*
write-device editing.txt /*write-device*
write-fail editing.txt /*write-fail*
write-filetype-plugin usr_41.txt /*write-filetype-plugin*
write-library-script usr_41.txt /*write-library-script*
write-local-help usr_41.txt /*write-local-help*
write-filetype-plugin usr_51.txt /*write-filetype-plugin*
write-library-script usr_51.txt /*write-library-script*
write-local-help usr_51.txt /*write-local-help*
write-permissions editing.txt /*write-permissions*
write-plugin usr_41.txt /*write-plugin*
write-plugin-quickload usr_41.txt /*write-plugin-quickload*
write-plugin usr_51.txt /*write-plugin*
write-plugin-quickload usr_51.txt /*write-plugin-quickload*
write-quit editing.txt /*write-quit*
write-readonly editing.txt /*write-readonly*
writefile() builtin.txt /*writefile()*

11
runtime/doc/todo.txt
View File

@@ -1,4 +1,4 @@
*todo.txt* For Vim version 8.2. Last change: 2022 May 12
*todo.txt* For Vim version 8.2. Last change: 2022 May 14
VIM REFERENCE MANUAL by Bram Moolenaar
@@ -41,13 +41,20 @@ browser use: https://github.com/vim/vim/issues/1234
Once Vim9 is stable:
- Use Vim9 for more runtime files.
- Check code coverage, add more tests if needed.
vim9expr.c
vim9instr.c
vim9script.c
vim9type.c
- Inlude new set of colors: #9795
- Adjust intro message to say "help version9".
Graduate FEAT_CINDENT and FEAT_SMARTINDENT ?
Update the user manual:
- Move most of usr_52.txt into usr_41.txt
- Make usr_41.txt only about basic script writing
- Fill usr_50.txt as an "advanced section" of usr_41.txt
Further Vim9 improvements, possibly after launch:
- Check performance with callgrind and kcachegrind.
getline()/substitute()/setline() in #5632

849
runtime/doc/usr_41.txt
View File

@@ -1,4 +1,4 @@
*usr_41.txt* For Vim version 8.2. Last change: 2022 May 09
*usr_41.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
@@ -19,12 +19,6 @@ script. There are a lot of them, thus this is a long chapter.
|41.8| Lists and Dictionaries
|41.9| Exceptions
|41.10| Various remarks
|41.11| Writing a plugin
|41.12| Writing a filetype plugin
|41.13| Writing a compiler plugin
|41.14| Writing a plugin that loads quickly
|41.15| Writing library scripts
|41.16| Distributing Vim scripts
Next chapter: |usr_42.txt| Add new menus
Previous chapter: |usr_40.txt| Make new commands
@@ -42,14 +36,10 @@ Syntax files are also Vim scripts. As are files that set options for a
specific file type. A complicated macro can be defined by a separate Vim
script file. You can think of other uses yourself.
If you are familiar with Python, you can find a comparison between
Python and Vim script here, with pointers to other documents:
https://gist.github.com/yegappan/16d964a37ead0979b05e655aa036cad0
And if you are familiar with JavaScript:
https://w0rp.com/blog/post/vim-script-for-the-javascripter/
Vim script comes in two flavors: legacy and |Vim9|. Since this help file is
for new users, we'll teach you the newer and more convenient |Vim9| syntax.
While legacy script is particular for Vim, |Vim9| script looks more like other
languages, such as JavaScript and TypeScript.
To try out Vim script the best way is to edit a script file and source it.
Basically: >
@@ -1928,839 +1918,6 @@ are script-local.
If you split your plugin into parts, you can use `import` and `export` to
share items between those parts. See `:export` for the details.
==============================================================================
*41.11* Writing a plugin *write-plugin*
You can write a Vim script in such a way that many people can use it. This is
called a plugin. Vim users can drop your script in their plugin directory and
use its features right away |add-plugin|.
There are actually two types of plugins:
global plugins: For all types of files.
filetype plugins: Only for files of a specific type.
In this section the first type is explained. Most items are also relevant for
writing filetype plugins. The specifics for filetype plugins are in the next
section |write-filetype-plugin|.
NAME
First of all you must choose a name for your plugin. The features provided
by the plugin should be clear from its name. And it should be unlikely that
someone else writes a plugin with the same name but which does something
different.
A script that corrects typing mistakes could be called "typecorrect.vim". We
will use it here as an example.
For the plugin to work for everybody, it should follow a few guidelines. This
will be explained step-by-step. The complete example plugin is at the end.
BODY
Let's start with the body of the plugin, the lines that do the actual work: >
14 iabbrev teh the
15 iabbrev otehr other
16 iabbrev wnat want
17 iabbrev synchronisation
18 \ synchronization
The actual list should be much longer, of course.
The line numbers have only been added to explain a few things, don't put them
in your plugin file!
FIRST LINE
>
1 vim9script noclear
You need to use `vimscript` as the very first command. Best is to put it in
the very first line.
The script we are writing will have a `finish` command to bail out when it is
loaded a second time. To avoid the items defined in the script are lost the
"noclear" argument is used. More info about this at |vim9-reload|.
HEADER
You will probably add new corrections to the plugin and soon have several
versions lying around. And when distributing this file, people will want to
know who wrote this wonderful plugin and where they can send remarks.
Therefore, put a header at the top of your plugin: >
2 # Vim global plugin for correcting typing mistakes
3 # Last Change: 2021 Dec 30
4 # Maintainer: Bram Moolenaar <Bram@vim.org>
About copyright and licensing: Since plugins are very useful and it's hardly
worth restricting their distribution, please consider making your plugin
either public domain or use the Vim |license|. A short note about this near
the top of the plugin should be sufficient. Example: >
5 # License: This file is placed in the public domain.
LINE CONTINUATION AND AVOIDING SIDE EFFECTS *use-cpo-save*
In line 18 above, the line-continuation mechanism is used |line-continuation|.
Users with 'compatible' set will run into trouble here, they will get an error
message. We can't just reset 'compatible', because that has a lot of side
effects. Instead, we will set the 'cpoptions' option to its Vim default
value and restore it later. That will allow the use of line-continuation and
make the script work for most people. It is done like this: >
11 var save_cpo = &cpo
12 set cpo&vim
..
42 &cpo = save_cpo
We first store the old value of 'cpoptions' in the "save_cpo" variable. At
the end of the plugin this value is restored.
Notice that "save_cpo" is a script-local variable. A global variable could
already be in use for something else. Always use script-local variables for
things that are only used in the script.
NOT LOADING
It is possible that a user doesn't always want to load this plugin. Or the
system administrator has dropped it in the system-wide plugin directory, but a
user has his own plugin he wants to use. Then the user must have a chance to
disable loading this specific plugin. These lines will make it possible: >
7 if exists("g:loaded_typecorrect")
8 finish
9 endif
10 g:loaded_typecorrect = 1
This also avoids that when the script is loaded twice it would pointlessly
redefine functions and cause trouble for autocommands that are added twice.
The name is recommended to start with "g:loaded_" and then the file name of
the plugin, literally. The "g:" is prepended to make the variable global, so
that other places can check whether its functionality is available. Without
"g:" it would be local to the script.
Using `finish` stops Vim from reading the rest of the file, it's much quicker
than using if-endif around the whole file, since Vim would still need to parse
the commands to find the `endif`.
MAPPING
Now let's make the plugin more interesting: We will add a mapping that adds a
correction for the word under the cursor. We could just pick a key sequence
for this mapping, but the user might already use it for something else. To
allow the user to define which keys a mapping in a plugin uses, the <Leader>
item can be used: >
22 map <unique> <Leader>a <Plug>TypecorrAdd;
The "<Plug>TypecorrAdd;" thing will do the work, more about that further on.
The user can set the "g:mapleader" variable to the key sequence that he wants
plugin mappings to start with. Thus if the user has done: >
g:mapleader = "_"
the mapping will define "_a". If the user didn't do this, the default value
will be used, which is a backslash. Then a map for "\a" will be defined.
Note that <unique> is used, this will cause an error message if the mapping
already happened to exist. |:map-<unique>|
But what if the user wants to define his own key sequence? We can allow that
with this mechanism: >
21 if !hasmapto('<Plug>TypecorrAdd;')
22 map <unique> <Leader>a <Plug>TypecorrAdd;
23 endif
This checks if a mapping to "<Plug>TypecorrAdd;" already exists, and only
defines the mapping from "<Leader>a" if it doesn't. The user then has a
chance of putting this in his vimrc file: >
map ,c <Plug>TypecorrAdd;
Then the mapped key sequence will be ",c" instead of "_a" or "\a".
PIECES
If a script gets longer, you often want to break up the work in pieces. You
can use functions or mappings for this. But you don't want these functions
and mappings to interfere with the ones from other scripts. For example, you
could define a function Add(), but another script could try to define the same
function. To avoid this, we define the function local to the script.
Fortunately, in |Vim9| script this is the default. In a legacy script you
would need to prefix the name with "s:".
We will define a function that adds a new typing correction: >
30 def Add(from: string, correct: bool)
31 var to = input("type the correction for " .. from .. ": ")
32 exe ":iabbrev " .. from .. " " .. to
..
36 enddef
Now we can call the function Add() from within this script. If another
script also defines Add(), it will be local to that script and can only
be called from that script. There can also be a global g:Add() function,
which is again another function.
<SID> can be used with mappings. It generates a script ID, which identifies
the current script. In our typing correction plugin we use it like this: >
24 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
..
28 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
Thus when a user types "\a", this sequence is invoked: >
\a -> <Plug>TypecorrAdd; -> <SID>Add -> :call <SID>Add(...)
If another script also maps <SID>Add, it will get another script ID and
thus define another mapping.
Note that instead of Add() we use <SID>Add() here. That is because the
mapping is typed by the user, thus outside of the script context. The <SID>
is translated to the script ID, so that Vim knows in which script to look for
the Add() function.
This is a bit complicated, but it's required for the plugin to work together
with other plugins. The basic rule is that you use <SID>Add() in mappings and
Add() in other places (the script itself, autocommands, user commands).
We can also add a menu entry to do the same as the mapping: >
26 noremenu <script> Plugin.Add\ Correction <SID>Add
The "Plugin" menu is recommended for adding menu items for plugins. In this
case only one item is used. When adding more items, creating a submenu is
recommended. For example, "Plugin.CVS" could be used for a plugin that offers
CVS operations "Plugin.CVS.checkin", "Plugin.CVS.checkout", etc.
Note that in line 28 ":noremap" is used to avoid that any other mappings cause
trouble. Someone may have remapped ":call", for example. In line 24 we also
use ":noremap", but we do want "<SID>Add" to be remapped. This is why
"<script>" is used here. This only allows mappings which are local to the
script. |:map-<script>| The same is done in line 26 for ":noremenu".
|:menu-<script>|
<SID> AND <Plug> *using-<Plug>*
Both <SID> and <Plug> are used to avoid that mappings of typed keys interfere
with mappings that are only to be used from other mappings. Note the
difference between using <SID> and <Plug>:
<Plug> is visible outside of the script. It is used for mappings which the
user might want to map a key sequence to. <Plug> is a special code
that a typed key will never produce.
To make it very unlikely that other plugins use the same sequence of
characters, use this structure: <Plug> scriptname mapname
In our example the scriptname is "Typecorr" and the mapname is "Add".
We add a semicolon as the terminator. This results in
"<Plug>TypecorrAdd;". Only the first character of scriptname and
mapname is uppercase, so that we can see where mapname starts.
<SID> is the script ID, a unique identifier for a script.
Internally Vim translates <SID> to "<SNR>123_", where "123" can be any
number. Thus a function "<SID>Add()" will have a name "<SNR>11_Add()"
in one script, and "<SNR>22_Add()" in another. You can see this if
you use the ":function" command to get a list of functions. The
translation of <SID> in mappings is exactly the same, that's how you
can call a script-local function from a mapping.
USER COMMAND
Now let's add a user command to add a correction: >
38 if !exists(":Correct")
39 command -nargs=1 Correct :call Add(<q-args>, false)
40 endif
The user command is defined only if no command with the same name already
exists. Otherwise we would get an error here. Overriding the existing user
command with ":command!" is not a good idea, this would probably make the user
wonder why the command he defined himself doesn't work. |:command|
If it did happen you can find out who to blame with: >
verbose command Correct
SCRIPT VARIABLES
When a variable starts with "s:" it is a script variable. It can only be used
inside a script. Outside the script it's not visible. This avoids trouble
with using the same variable name in different scripts. The variables will be
kept as long as Vim is running. And the same variables are used when sourcing
the same script again. |s:var|
The nice thing about |Vim9| script is that variables are local to the script
by default. You can prepend "s:" if you like, but you do not need to. And
functions in the script can also use the script variables without a prefix.
Script-local variables can also be used in functions, autocommands and user
commands that are defined in the script. Thus they are the perfect way to
share information between parts of your plugin, without it leaking out. In
our example we can add a few lines to count the number of corrections: >
19 var count = 4
..
30 def Add(from: string, correct: bool)
..
34 count += 1
35 echo "you now have " .. count .. " corrections"
36 enddef
"count" is declared and initialized to 4 in the script itself. When later
the Add() function is called, it increments "count". It doesn't matter from
where the function was called, since it has been defined in the script, it
will use the local variables from this script.
THE RESULT
Here is the resulting complete example: >
1 vim9script noclear
2 # Vim global plugin for correcting typing mistakes
3 # Last Change: 2021 Dec 30
4 # Maintainer: Bram Moolenaar <Bram@vim.org>
5 # License: This file is placed in the public domain.
6
7 if exists("g:loaded_typecorrect")
8 finish
9 endif
10 g:loaded_typecorrect = 1
11 var save_cpo = &cpo
12 set cpo&vim
13
14 iabbrev teh the
15 iabbrev otehr other
16 iabbrev wnat want
17 iabbrev synchronisation
18 \ synchronization
19 var count = 4
20
21 if !hasmapto('<Plug>TypecorrAdd;')
22 map <unique> <Leader>a <Plug>TypecorrAdd;
23 endif
24 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
25
26 noremenu <script> Plugin.Add\ Correction <SID>Add
27
28 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
29
30 def Add(from: string, correct: bool)
31 var to = input("type the correction for " .. from .. ": ")
32 exe ":iabbrev " .. from .. " " .. to
33 if correct | exe "normal viws\<C-R>\" \b\e" | endif
34 count += 1
35 echo "you now have " .. count .. " corrections"
36 enddef
37
38 if !exists(":Correct")
39 command -nargs=1 Correct call Add(<q-args>, false)
40 endif
41
42 &cpo = save_cpo
Line 33 wasn't explained yet. It applies the new correction to the word under
the cursor. The |:normal| command is used to use the new abbreviation. Note
that mappings and abbreviations are expanded here, even though the function
was called from a mapping defined with ":noremap".
DOCUMENTATION *write-local-help*
It's a good idea to also write some documentation for your plugin. Especially
when its behavior can be changed by the user. See |add-local-help| for how
they are installed.
Here is a simple example for a plugin help file, called "typecorrect.txt": >
1 *typecorrect.txt* Plugin for correcting typing mistakes
2
3 If you make typing mistakes, this plugin will have them corrected
4 automatically.
5
6 There are currently only a few corrections. Add your own if you like.
7
8 Mappings:
9 <Leader>a or <Plug>TypecorrAdd;
10 Add a correction for the word under the cursor.
11
12 Commands:
13 :Correct {word}
14 Add a correction for {word}.
15
16 *typecorrect-settings*
17 This plugin doesn't have any settings.
The first line is actually the only one for which the format matters. It will
be extracted from the help file to be put in the "LOCAL ADDITIONS:" section of
help.txt |local-additions|. The first "*" must be in the first column of the
first line. After adding your help file do ":help" and check that the entries
line up nicely.
You can add more tags inside ** in your help file. But be careful not to use
existing help tags. You would probably use the name of your plugin in most of
them, like "typecorrect-settings" in the example.
Using references to other parts of the help in || is recommended. This makes
it easy for the user to find associated help.
FILETYPE DETECTION *plugin-filetype*
If your filetype is not already detected by Vim, you should create a filetype
detection snippet in a separate file. It is usually in the form of an
autocommand that sets the filetype when the file name matches a pattern.
Example: >
au BufNewFile,BufRead *.foo setlocal filetype=foofoo
Write this single-line file as "ftdetect/foofoo.vim" in the first directory
that appears in 'runtimepath'. For Unix that would be
"~/.vim/ftdetect/foofoo.vim". The convention is to use the name of the
filetype for the script name.
You can make more complicated checks if you like, for example to inspect the
contents of the file to recognize the language. Also see |new-filetype|.
SUMMARY *plugin-special*
Summary of special things to use in a plugin:
var name Variable local to the script.
<SID> Script-ID, used for mappings and functions local to
the script.
hasmapto() Function to test if the user already defined a mapping
for functionality the script offers.
<Leader> Value of "mapleader", which the user defines as the
keys that plugin mappings start with.
map <unique> Give a warning if a mapping already exists.
noremap <script> Use only mappings local to the script, not global
mappings.
exists(":Cmd") Check if a user command already exists.
==============================================================================
*41.12* Writing a filetype plugin *write-filetype-plugin* *ftplugin*
A filetype plugin is like a global plugin, except that it sets options and
defines mappings for the current buffer only. See |add-filetype-plugin| for
how this type of plugin is used.
First read the section on global plugins above |41.11|. All that is said there
also applies to filetype plugins. There are a few extras, which are explained
here. The essential thing is that a filetype plugin should only have an
effect on the current buffer.
DISABLING
If you are writing a filetype plugin to be used by many people, they need a
chance to disable loading it. Put this at the top of the plugin: >
# Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
finish
endif
b:did_ftplugin = 1
This also needs to be used to avoid that the same plugin is executed twice for
the same buffer (happens when using an ":edit" command without arguments).
Now users can disable loading the default plugin completely by making a
filetype plugin with only these lines: >
vim9script
b:did_ftplugin = 1
This does require that the filetype plugin directory comes before $VIMRUNTIME
in 'runtimepath'!
If you do want to use the default plugin, but overrule one of the settings,
you can write the different setting in a script: >
setlocal textwidth=70
Now write this in the "after" directory, so that it gets sourced after the
distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
"~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
"b:did_ftplugin", but it is ignored here.
OPTIONS
To make sure the filetype plugin only affects the current buffer use the >
setlocal
command to set options. And only set options which are local to a buffer (see
the help for the option to check that). When using `:setlocal` for global
options or options local to a window, the value will change for many buffers,
and that is not what a filetype plugin should do.
When an option has a value that is a list of flags or items, consider using
"+=" and "-=" to keep the existing value. Be aware that the user may have
changed an option value already. First resetting to the default value and
then changing it is often a good idea. Example: >
setlocal formatoptions& formatoptions+=ro
MAPPINGS
To make sure mappings will only work in the current buffer use the >
map <buffer>
command. This needs to be combined with the two-step mapping explained above.
An example of how to define functionality in a filetype plugin: >
if !hasmapto('<Plug>JavaImport;')
map <buffer> <unique> <LocalLeader>i <Plug>JavaImport;
endif
noremap <buffer> <unique> <Plug>JavaImport; oimport ""<Left><Esc>
|hasmapto()| is used to check if the user has already defined a map to
<Plug>JavaImport;. If not, then the filetype plugin defines the default
mapping. This starts with |<LocalLeader>|, which allows the user to select
the key(s) he wants filetype plugin mappings to start with. The default is a
backslash.
"<unique>" is used to give an error message if the mapping already exists or
overlaps with an existing mapping.
|:noremap| is used to avoid that any other mappings that the user has defined
interferes. You might want to use ":noremap <script>" to allow remapping
mappings defined in this script that start with <SID>.
The user must have a chance to disable the mappings in a filetype plugin,
without disabling everything. Here is an example of how this is done for a
plugin for the mail filetype: >
# Add mappings, unless the user didn't want this.
if !exists("g:no_plugin_maps") && !exists("g:no_mail_maps")
# Quote text by inserting "> "
if !hasmapto('<Plug>MailQuote;')
vmap <buffer> <LocalLeader>q <Plug>MailQuote;
nmap <buffer> <LocalLeader>q <Plug>MailQuote;
endif
vnoremap <buffer> <Plug>MailQuote; :s/^/> /<CR>
nnoremap <buffer> <Plug>MailQuote; :.,$s/^/> /<CR>
endif
Two global variables are used:
|g:no_plugin_maps| disables mappings for all filetype plugins
|g:no_mail_maps| disables mappings for the "mail" filetype
USER COMMANDS
To add a user command for a specific file type, so that it can only be used in
one buffer, use the "-buffer" argument to |:command|. Example: >
command -buffer Make make %:r.s
VARIABLES
A filetype plugin will be sourced for each buffer of the type it's for. Local
script variables will be shared between all invocations. Use local buffer
variables |b:var| if you want a variable specifically for one buffer.
FUNCTIONS
When defining a function, this only needs to be done once. But the filetype
plugin will be sourced every time a file with this filetype will be opened.
This construct makes sure the function is only defined once: >
if !exists("*Func")
def Func(arg)
...
enddef
endif
<
UNDO *undo_indent* *undo_ftplugin*
When the user does ":setfiletype xyz" the effect of the previous filetype
should be undone. Set the b:undo_ftplugin variable to the commands that will
undo the settings in your filetype plugin. Example: >
let b:undo_ftplugin = "setlocal fo< com< tw< commentstring<"
\ .. "| unlet b:match_ignorecase b:match_words b:match_skip"
Using ":setlocal" with "<" after the option name resets the option to its
global value. That is mostly the best way to reset the option value.
This does require removing the "C" flag from 'cpoptions' to allow line
continuation, as mentioned above |use-cpo-save|.
For undoing the effect of an indent script, the b:undo_indent variable should
be set accordingly.
Both these variables use legacy script syntax, not |Vim9| syntax.
FILE NAME
The filetype must be included in the file name |ftplugin-name|. Use one of
these three forms:
.../ftplugin/stuff.vim
.../ftplugin/stuff_foo.vim
.../ftplugin/stuff/bar.vim
"stuff" is the filetype, "foo" and "bar" are arbitrary names.
SUMMARY *ftplugin-special*
Summary of special things to use in a filetype plugin:
<LocalLeader> Value of "maplocalleader", which the user defines as
the keys that filetype plugin mappings start with.
map <buffer> Define a mapping local to the buffer.
noremap <script> Only remap mappings defined in this script that start
with <SID>.
setlocal Set an option for the current buffer only.
command -buffer Define a user command local to the buffer.
exists("*s:Func") Check if a function was already defined.
Also see |plugin-special|, the special things used for all plugins.
==============================================================================
*41.13* Writing a compiler plugin *write-compiler-plugin*
A compiler plugin sets options for use with a specific compiler. The user can
load it with the |:compiler| command. The main use is to set the
'errorformat' and 'makeprg' options.
Easiest is to have a look at examples. This command will edit all the default
compiler plugins: >
next $VIMRUNTIME/compiler/*.vim
Type `:next` to go to the next plugin file.
There are two special items about these files. First is a mechanism to allow
a user to overrule or add to the default file. The default files start with: >
vim9script
if exists("g:current_compiler")
finish
endif
g:current_compiler = "mine"
When you write a compiler file and put it in your personal runtime directory
(e.g., ~/.vim/compiler for Unix), you set the "current_compiler" variable to
make the default file skip the settings.
*:CompilerSet*
The second mechanism is to use ":set" for ":compiler!" and ":setlocal" for
":compiler". Vim defines the ":CompilerSet" user command for this. However,
older Vim versions don't, thus your plugin should define it then. This is an
example: >
if exists(":CompilerSet") != 2
command -nargs=* CompilerSet setlocal <args>
endif
CompilerSet errorformat& " use the default 'errorformat'
CompilerSet makeprg=nmake
When you write a compiler plugin for the Vim distribution or for a system-wide
runtime directory, use the mechanism mentioned above. When
"current_compiler" was already set by a user plugin nothing will be done.
When you write a compiler plugin to overrule settings from a default plugin,
don't check "current_compiler". This plugin is supposed to be loaded
last, thus it should be in a directory at the end of 'runtimepath'. For Unix
that could be ~/.vim/after/compiler.
==============================================================================
*41.14* Writing a plugin that loads quickly *write-plugin-quickload*
A plugin may grow and become quite long. The startup delay may become
noticeable, while you hardly ever use the plugin. Then it's time for a
quickload plugin.
The basic idea is that the plugin is loaded twice. The first time user
commands and mappings are defined that offer the functionality. The second
time the functions that implement the functionality are defined.
It may sound surprising that quickload means loading a script twice. What we
mean is that it loads quickly the first time, postponing the bulk of the
script to the second time, which only happens when you actually use it. When
you always use the functionality it actually gets slower!
This uses a FuncUndefined autocommand. Since Vim 7 there is an alternative:
use the |autoload| functionality |41.15|. That will also use |Vim9| script
instead of legacy script that is used here.
The following example shows how it's done: >
" Vim global plugin for demonstrating quick loading
" Last Change: 2005 Feb 25
" Maintainer: Bram Moolenaar <Bram@vim.org>
" License: This file is placed in the public domain.
if !exists("s:did_load")
command -nargs=* BNRead call BufNetRead(<f-args>)
map <F19> :call BufNetWrite('something')<CR>
let s:did_load = 1
exe 'au FuncUndefined BufNet* source ' .. expand('<sfile>')
finish
endif
function BufNetRead(...)
echo 'BufNetRead(' .. string(a:000) .. ')'
" read functionality here
endfunction
function BufNetWrite(...)
echo 'BufNetWrite(' .. string(a:000) .. ')'
" write functionality here
endfunction
When the script is first loaded "s:did_load" is not set. The commands between
the "if" and "endif" will be executed. This ends in a |:finish| command, thus
the rest of the script is not executed.
The second time the script is loaded "s:did_load" exists and the commands
after the "endif" are executed. This defines the (possible long)
BufNetRead() and BufNetWrite() functions.
If you drop this script in your plugin directory Vim will execute it on
startup. This is the sequence of events that happens:
1. The "BNRead" command is defined and the <F19> key is mapped when the script
is sourced at startup. A |FuncUndefined| autocommand is defined. The
":finish" command causes the script to terminate early.
2. The user types the BNRead command or presses the <F19> key. The
BufNetRead() or BufNetWrite() function will be called.
3. Vim can't find the function and triggers the |FuncUndefined| autocommand
event. Since the pattern "BufNet*" matches the invoked function, the
command "source fname" will be executed. "fname" will be equal to the name
of the script, no matter where it is located, because it comes from
expanding "<sfile>" (see |expand()|).
4. The script is sourced again, the "s:did_load" variable exists and the
functions are defined.
Notice that the functions that are loaded afterwards match the pattern in the
|FuncUndefined| autocommand. You must make sure that no other plugin defines
functions that match this pattern.
==============================================================================
*41.15* Writing library scripts *write-library-script*
Some functionality will be required in several places. When this becomes more
than a few lines you will want to put it in one script and use it from many
scripts. We will call that one script a library script.
Manually loading a library script is possible, so long as you avoid loading it
when it's already done. You can do this with the |exists()| function.
Example: >
if !exists('*MyLibFunction')
runtime library/mylibscript.vim
endif
MyLibFunction(arg)
Here you need to know that MyLibFunction() is defined in a script
"library/mylibscript.vim" in one of the directories in 'runtimepath'.
To make this a bit simpler Vim offers the autoload mechanism. Then the
example looks like this: >
mylib#myfunction(arg)
That's a lot simpler, isn't it? Vim will recognize the function name by the
embedded "#" character and when it's not defined search for the script
"autoload/mylib.vim" in 'runtimepath'. That script must define the
"mylib#myfunction()" function.
You can put many other functions in the mylib.vim script, you are free to
organize your functions in library scripts. But you must use function names
where the part before the '#' matches the script name. Otherwise Vim would
not know what script to load.
If you get really enthusiastic and write lots of library scripts, you may
want to use subdirectories. Example: >
netlib#ftp#read('somefile')
For Unix the library script used for this could be:
~/.vim/autoload/netlib/ftp.vim
Where the function is defined like this: >
def netlib#ftp#read(fname: string)
# Read the file fname through ftp
enddef
Notice that the name the function is defined with is exactly the same as the
name used for calling the function. And the part before the last '#'
exactly matches the subdirectory and script name.
You can use the same mechanism for variables: >
var weekdays = dutch#weekdays
This will load the script "autoload/dutch.vim", which should contain something
like: >
var dutch#weekdays = ['zondag', 'maandag', 'dinsdag', 'woensdag',
\ 'donderdag', 'vrijdag', 'zaterdag']
Further reading: |autoload|.
==============================================================================
*41.16* Distributing Vim scripts *distribute-script*
Vim users will look for scripts on the Vim website: http://www.vim.org.
If you made something that is useful for others, share it!
Another place is github. But there you need to know where to find it! The
advantage is that most plugin managers fetch plugins from github. You'll have
to use your favorite search engine to find them.
Vim scripts can be used on any system. However, there might not be a tar or
gzip command. If you want to pack files together and/or compress them the
"zip" utility is recommended.
For utmost portability use Vim itself to pack scripts together. This can be
done with the Vimball utility. See |vimball|.
It's good if you add a line to allow automatic updating. See |glvs-plugins|.
==============================================================================
Next chapter: |usr_42.txt| Add new menus

6
runtime/doc/usr_45.txt
View File

@@ -1,4 +1,4 @@
*usr_45.txt* For Vim version 8.2. Last change: 2020 Jun 11
*usr_45.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
@@ -15,7 +15,7 @@ in various languages is explained.
|45.4| Editing files with a different encoding
|45.5| Entering language text
Next chapter: |usr_46.txt| Write plugins using Vim9 script
Next chapter: |usr_50.txt| Advanced Vim script writing
Previous chapter: |usr_44.txt| Your own syntax highlighted
Table of contents: |usr_toc.txt|
@@ -408,6 +408,6 @@ Don't type the spaces. See |i_CTRL-V_digit| for the details.
==============================================================================
Next chapter: |usr_46.txt| Write plugins using Vim9 script
Next chapter: |usr_50.txt| Advanced Vim script writing
Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl:

25
runtime/doc/usr_50.txt Normal file
View File

@@ -0,0 +1,25 @@
*usr_50.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
Advanced Vim script writing
TODO - this chapter is to be written
|50.1| Writing stuff
Next chapter: |usr_51.txt| Create a plugin
Previous chapter: |usr_45.txt| Select your language (local)
Table of contents: |usr_toc.txt|
==============================================================================
*50.1* Writing stuff
TODO
==============================================================================
Next chapter: |usr_51.txt| Create a plugin
Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl:

860
runtime/doc/usr_51.txt Normal file
View File

@@ -0,0 +1,860 @@
*usr_51.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
Write plugins
Plugins can be used to define settings for a specific type of file, syntax
highlighting and many other things. This chapter explains how to write the
most common Vim plugins.
|51.1| Writing a generic plugin
|51.2| Writing a filetype plugin
|51.3| Writing a compiler plugin
|51.4| Writing a plugin that loads quickly
|51.5| Writing library scripts
|51.6| Distributing Vim scripts
Next chapter: |usr_52.txt| Write plugins using Vim9 script
Previous chapter: |usr_50.txt| Advanced Vim script writing
Table of contents: |usr_toc.txt|
==============================================================================
*51.1* Writing a generic plugin *write-plugin*
You can write a Vim script in such a way that many people can use it. This is
called a plugin. Vim users can drop your script in their plugin directory and
use its features right away |add-plugin|.
There are actually two types of plugins:
global plugins: For all types of files.
filetype plugins: Only for files of a specific type.
In this section the first type is explained. Most items are also relevant for
writing filetype plugins. The specifics for filetype plugins are in the next
section |write-filetype-plugin|.
NAME
First of all you must choose a name for your plugin. The features provided
by the plugin should be clear from its name. And it should be unlikely that
someone else writes a plugin with the same name but which does something
different.
A script that corrects typing mistakes could be called "typecorrect.vim". We
will use it here as an example.
For the plugin to work for everybody, it should follow a few guidelines. This
will be explained step-by-step. The complete example plugin is at the end.
BODY
Let's start with the body of the plugin, the lines that do the actual work: >
14 iabbrev teh the
15 iabbrev otehr other
16 iabbrev wnat want
17 iabbrev synchronisation
18 \ synchronization
The actual list should be much longer, of course.
The line numbers have only been added to explain a few things, don't put them
in your plugin file!
FIRST LINE
>
1 vim9script noclear
You need to use `vimscript` as the very first command. Best is to put it in
the very first line.
The script we are writing will have a `finish` command to bail out when it is
loaded a second time. To avoid that the items defined in the script are lost
the "noclear" argument is used. More info about this at |vim9-reload|.
HEADER
You will probably add new corrections to the plugin and soon have several
versions lying around. And when distributing this file, people will want to
know who wrote this wonderful plugin and where they can send remarks.
Therefore, put a header at the top of your plugin: >
2 # Vim global plugin for correcting typing mistakes
3 # Last Change: 2021 Dec 30
4 # Maintainer: Bram Moolenaar <Bram@vim.org>
About copyright and licensing: Since plugins are very useful and it's hardly
worth restricting their distribution, please consider making your plugin
either public domain or use the Vim |license|. A short note about this near
the top of the plugin should be sufficient. Example: >
5 # License: This file is placed in the public domain.
LINE CONTINUATION AND AVOIDING SIDE EFFECTS *use-cpo-save*
In line 18 above, the line-continuation mechanism is used |line-continuation|.
Users with 'compatible' set will run into trouble here, they will get an error
message. We can't just reset 'compatible', because that has a lot of side
effects. Instead, we will set the 'cpoptions' option to its Vim default
value and restore it later. That will allow the use of line-continuation and
make the script work for most people. It is done like this: >
11 var save_cpo = &cpo
12 set cpo&vim
..
42 &cpo = save_cpo
We first store the old value of 'cpoptions' in the "save_cpo" variable. At
the end of the plugin this value is restored.
Notice that "save_cpo" is a script-local variable. A global variable could
already be in use for something else. Always use script-local variables for
things that are only used in the script.
NOT LOADING
It is possible that a user doesn't always want to load this plugin. Or the
system administrator has dropped it in the system-wide plugin directory, but a
user has his own plugin he wants to use. Then the user must have a chance to
disable loading this specific plugin. These lines will make it possible: >
7 if exists("g:loaded_typecorrect")
8 finish
9 endif
10 g:loaded_typecorrect = 1
This also avoids that when the script is loaded twice it would pointlessly
redefine functions and cause trouble for autocommands that are added twice.
The name is recommended to start with "g:loaded_" and then the file name of
the plugin, literally. The "g:" is prepended to make the variable global, so
that other places can check whether its functionality is available. Without
"g:" it would be local to the script.
Using `finish` stops Vim from reading the rest of the file, it's much quicker
than using if-endif around the whole file, since Vim would still need to parse
the commands to find the `endif`.
MAPPING
Now let's make the plugin more interesting: We will add a mapping that adds a
correction for the word under the cursor. We could just pick a key sequence
for this mapping, but the user might already use it for something else. To
allow the user to define which keys a mapping in a plugin uses, the <Leader>
item can be used: >
22 map <unique> <Leader>a <Plug>TypecorrAdd;
The "<Plug>TypecorrAdd;" thing will do the work, more about that further on.
The user can set the "g:mapleader" variable to the key sequence that he wants
plugin mappings to start with. Thus if the user has done: >
g:mapleader = "_"
the mapping will define "_a". If the user didn't do this, the default value
will be used, which is a backslash. Then a map for "\a" will be defined.
Note that <unique> is used, this will cause an error message if the mapping
already happened to exist. |:map-<unique>|
But what if the user wants to define his own key sequence? We can allow that
with this mechanism: >
21 if !hasmapto('<Plug>TypecorrAdd;')
22 map <unique> <Leader>a <Plug>TypecorrAdd;
23 endif
This checks if a mapping to "<Plug>TypecorrAdd;" already exists, and only
defines the mapping from "<Leader>a" if it doesn't. The user then has a
chance of putting this in his vimrc file: >
map ,c <Plug>TypecorrAdd;
Then the mapped key sequence will be ",c" instead of "_a" or "\a".
PIECES
If a script gets longer, you often want to break up the work in pieces. You
can use functions or mappings for this. But you don't want these functions
and mappings to interfere with the ones from other scripts. For example, you
could define a function Add(), but another script could try to define the same
function. To avoid this, we define the function local to the script.
Fortunately, in |Vim9| script this is the default. In a legacy script you
would need to prefix the name with "s:".
We will define a function that adds a new typing correction: >
30 def Add(from: string, correct: bool)
31 var to = input("type the correction for " .. from .. ": ")
32 exe ":iabbrev " .. from .. " " .. to
..
36 enddef
Now we can call the function Add() from within this script. If another
script also defines Add(), it will be local to that script and can only
be called from that script. There can also be a global g:Add() function,
which is again another function.
<SID> can be used with mappings. It generates a script ID, which identifies
the current script. In our typing correction plugin we use it like this: >
24 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
..
28 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
Thus when a user types "\a", this sequence is invoked: >
\a -> <Plug>TypecorrAdd; -> <SID>Add -> :call <SID>Add(...)
If another script also maps <SID>Add, it will get another script ID and
thus define another mapping.
Note that instead of Add() we use <SID>Add() here. That is because the
mapping is typed by the user, thus outside of the script context. The <SID>
is translated to the script ID, so that Vim knows in which script to look for
the Add() function.
This is a bit complicated, but it's required for the plugin to work together
with other plugins. The basic rule is that you use <SID>Add() in mappings and
Add() in other places (the script itself, autocommands, user commands).
We can also add a menu entry to do the same as the mapping: >
26 noremenu <script> Plugin.Add\ Correction <SID>Add
The "Plugin" menu is recommended for adding menu items for plugins. In this
case only one item is used. When adding more items, creating a submenu is
recommended. For example, "Plugin.CVS" could be used for a plugin that offers
CVS operations "Plugin.CVS.checkin", "Plugin.CVS.checkout", etc.
Note that in line 28 ":noremap" is used to avoid that any other mappings cause
trouble. Someone may have remapped ":call", for example. In line 24 we also
use ":noremap", but we do want "<SID>Add" to be remapped. This is why
"<script>" is used here. This only allows mappings which are local to the
script. |:map-<script>| The same is done in line 26 for ":noremenu".
|:menu-<script>|
<SID> AND <Plug> *using-<Plug>*
Both <SID> and <Plug> are used to avoid that mappings of typed keys interfere
with mappings that are only to be used from other mappings. Note the
difference between using <SID> and <Plug>:
<Plug> is visible outside of the script. It is used for mappings which the
user might want to map a key sequence to. <Plug> is a special code
that a typed key will never produce.
To make it very unlikely that other plugins use the same sequence of
characters, use this structure: <Plug> scriptname mapname
In our example the scriptname is "Typecorr" and the mapname is "Add".
We add a semicolon as the terminator. This results in
"<Plug>TypecorrAdd;". Only the first character of scriptname and
mapname is uppercase, so that we can see where mapname starts.
<SID> is the script ID, a unique identifier for a script.
Internally Vim translates <SID> to "<SNR>123_", where "123" can be any
number. Thus a function "<SID>Add()" will have a name "<SNR>11_Add()"
in one script, and "<SNR>22_Add()" in another. You can see this if
you use the ":function" command to get a list of functions. The
translation of <SID> in mappings is exactly the same, that's how you
can call a script-local function from a mapping.
USER COMMAND
Now let's add a user command to add a correction: >
38 if !exists(":Correct")
39 command -nargs=1 Correct :call Add(<q-args>, false)
40 endif
The user command is defined only if no command with the same name already
exists. Otherwise we would get an error here. Overriding the existing user
command with ":command!" is not a good idea, this would probably make the user
wonder why the command he defined himself doesn't work. |:command|
If it did happen you can find out who to blame with: >
verbose command Correct
SCRIPT VARIABLES
When a variable starts with "s:" it is a script variable. It can only be used
inside a script. Outside the script it's not visible. This avoids trouble
with using the same variable name in different scripts. The variables will be
kept as long as Vim is running. And the same variables are used when sourcing
the same script again. |s:var|
The nice thing about |Vim9| script is that variables are local to the script
by default. You can prepend "s:" if you like, but you do not need to. And
functions in the script can also use the script variables without a prefix.
Script-local variables can also be used in functions, autocommands and user
commands that are defined in the script. Thus they are the perfect way to
share information between parts of your plugin, without it leaking out. In
our example we can add a few lines to count the number of corrections: >
19 var count = 4
..
30 def Add(from: string, correct: bool)
..
34 count += 1
35 echo "you now have " .. count .. " corrections"
36 enddef
"count" is declared and initialized to 4 in the script itself. When later
the Add() function is called, it increments "count". It doesn't matter from
where the function was called, since it has been defined in the script, it
will use the local variables from this script.
THE RESULT
Here is the resulting complete example: >
1 vim9script noclear
2 # Vim global plugin for correcting typing mistakes
3 # Last Change: 2021 Dec 30
4 # Maintainer: Bram Moolenaar <Bram@vim.org>
5 # License: This file is placed in the public domain.
6
7 if exists("g:loaded_typecorrect")
8 finish
9 endif
10 g:loaded_typecorrect = 1
11 var save_cpo = &cpo
12 set cpo&vim
13
14 iabbrev teh the
15 iabbrev otehr other
16 iabbrev wnat want
17 iabbrev synchronisation
18 \ synchronization
19 var count = 4
20
21 if !hasmapto('<Plug>TypecorrAdd;')
22 map <unique> <Leader>a <Plug>TypecorrAdd;
23 endif
24 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
25
26 noremenu <script> Plugin.Add\ Correction <SID>Add
27
28 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
29
30 def Add(from: string, correct: bool)
31 var to = input("type the correction for " .. from .. ": ")
32 exe ":iabbrev " .. from .. " " .. to
33 if correct | exe "normal viws\<C-R>\" \b\e" | endif
34 count += 1
35 echo "you now have " .. count .. " corrections"
36 enddef
37
38 if !exists(":Correct")
39 command -nargs=1 Correct call Add(<q-args>, false)
40 endif
41
42 &cpo = save_cpo
Line 33 wasn't explained yet. It applies the new correction to the word under
the cursor. The |:normal| command is used to use the new abbreviation. Note
that mappings and abbreviations are expanded here, even though the function
was called from a mapping defined with ":noremap".
DOCUMENTATION *write-local-help*
It's a good idea to also write some documentation for your plugin. Especially
when its behavior can be changed by the user. See |add-local-help| for how
they are installed.
Here is a simple example for a plugin help file, called "typecorrect.txt": >
1 *typecorrect.txt* Plugin for correcting typing mistakes
2
3 If you make typing mistakes, this plugin will have them corrected
4 automatically.
5
6 There are currently only a few corrections. Add your own if you like.
7
8 Mappings:
9 <Leader>a or <Plug>TypecorrAdd;
10 Add a correction for the word under the cursor.
11
12 Commands:
13 :Correct {word}
14 Add a correction for {word}.
15
16 *typecorrect-settings*
17 This plugin doesn't have any settings.
The first line is actually the only one for which the format matters. It will
be extracted from the help file to be put in the "LOCAL ADDITIONS:" section of
help.txt |local-additions|. The first "*" must be in the first column of the
first line. After adding your help file do ":help" and check that the entries
line up nicely.
You can add more tags inside ** in your help file. But be careful not to use
existing help tags. You would probably use the name of your plugin in most of
them, like "typecorrect-settings" in the example.
Using references to other parts of the help in || is recommended. This makes
it easy for the user to find associated help.
FILETYPE DETECTION *plugin-filetype*
If your filetype is not already detected by Vim, you should create a filetype
detection snippet in a separate file. It is usually in the form of an
autocommand that sets the filetype when the file name matches a pattern.
Example: >
au BufNewFile,BufRead *.foo setlocal filetype=foofoo
Write this single-line file as "ftdetect/foofoo.vim" in the first directory
that appears in 'runtimepath'. For Unix that would be
"~/.vim/ftdetect/foofoo.vim". The convention is to use the name of the
filetype for the script name.
You can make more complicated checks if you like, for example to inspect the
contents of the file to recognize the language. Also see |new-filetype|.
SUMMARY *plugin-special*
Summary of special things to use in a plugin:
var name Variable local to the script.
<SID> Script-ID, used for mappings and functions local to
the script.
hasmapto() Function to test if the user already defined a mapping
for functionality the script offers.
<Leader> Value of "mapleader", which the user defines as the
keys that plugin mappings start with.
map <unique> Give a warning if a mapping already exists.
noremap <script> Use only mappings local to the script, not global
mappings.
exists(":Cmd") Check if a user command already exists.
==============================================================================
*51.2* Writing a filetype plugin *write-filetype-plugin* *ftplugin*
A filetype plugin is like a global plugin, except that it sets options and
defines mappings for the current buffer only. See |add-filetype-plugin| for
how this type of plugin is used.
First read the section on global plugins above |51.1|. All that is said there
also applies to filetype plugins. There are a few extras, which are explained
here. The essential thing is that a filetype plugin should only have an
effect on the current buffer.
DISABLING
If you are writing a filetype plugin to be used by many people, they need a
chance to disable loading it. Put this at the top of the plugin: >
# Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
finish
endif
b:did_ftplugin = 1
This also needs to be used to avoid that the same plugin is executed twice for
the same buffer (happens when using an ":edit" command without arguments).
Now users can disable loading the default plugin completely by making a
filetype plugin with only these lines: >
vim9script
b:did_ftplugin = 1
This does require that the filetype plugin directory comes before $VIMRUNTIME
in 'runtimepath'!
If you do want to use the default plugin, but overrule one of the settings,
you can write the different setting in a script: >
setlocal textwidth=70
Now write this in the "after" directory, so that it gets sourced after the
distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
"~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
"b:did_ftplugin", but it is ignored here.
OPTIONS
To make sure the filetype plugin only affects the current buffer use the >
setlocal
command to set options. And only set options which are local to a buffer (see
the help for the option to check that). When using `:setlocal` for global
options or options local to a window, the value will change for many buffers,
and that is not what a filetype plugin should do.
When an option has a value that is a list of flags or items, consider using
"+=" and "-=" to keep the existing value. Be aware that the user may have
changed an option value already. First resetting to the default value and
then changing it is often a good idea. Example: >
setlocal formatoptions& formatoptions+=ro
MAPPINGS
To make sure mappings will only work in the current buffer use the >
map <buffer>
command. This needs to be combined with the two-step mapping explained above.
An example of how to define functionality in a filetype plugin: >
if !hasmapto('<Plug>JavaImport;')
map <buffer> <unique> <LocalLeader>i <Plug>JavaImport;
endif
noremap <buffer> <unique> <Plug>JavaImport; oimport ""<Left><Esc>
|hasmapto()| is used to check if the user has already defined a map to
<Plug>JavaImport;. If not, then the filetype plugin defines the default
mapping. This starts with |<LocalLeader>|, which allows the user to select
the key(s) he wants filetype plugin mappings to start with. The default is a
backslash.
"<unique>" is used to give an error message if the mapping already exists or
overlaps with an existing mapping.
|:noremap| is used to avoid that any other mappings that the user has defined
interferes. You might want to use ":noremap <script>" to allow remapping
mappings defined in this script that start with <SID>.
The user must have a chance to disable the mappings in a filetype plugin,
without disabling everything. Here is an example of how this is done for a
plugin for the mail filetype: >
# Add mappings, unless the user didn't want this.
if !exists("g:no_plugin_maps") && !exists("g:no_mail_maps")
# Quote text by inserting "> "
if !hasmapto('<Plug>MailQuote;')
vmap <buffer> <LocalLeader>q <Plug>MailQuote;
nmap <buffer> <LocalLeader>q <Plug>MailQuote;
endif
vnoremap <buffer> <Plug>MailQuote; :s/^/> /<CR>
nnoremap <buffer> <Plug>MailQuote; :.,$s/^/> /<CR>
endif
Two global variables are used:
|g:no_plugin_maps| disables mappings for all filetype plugins
|g:no_mail_maps| disables mappings for the "mail" filetype
USER COMMANDS
To add a user command for a specific file type, so that it can only be used in
one buffer, use the "-buffer" argument to |:command|. Example: >
command -buffer Make make %:r.s
VARIABLES
A filetype plugin will be sourced for each buffer of the type it's for. Local
script variables will be shared between all invocations. Use local buffer
variables |b:var| if you want a variable specifically for one buffer.
FUNCTIONS
When defining a function, this only needs to be done once. But the filetype
plugin will be sourced every time a file with this filetype will be opened.
This construct makes sure the function is only defined once: >
if !exists("*Func")
def Func(arg)
...
enddef
endif
<
UNDO *undo_indent* *undo_ftplugin*
When the user does ":setfiletype xyz" the effect of the previous filetype
should be undone. Set the b:undo_ftplugin variable to the commands that will
undo the settings in your filetype plugin. Example: >
let b:undo_ftplugin = "setlocal fo< com< tw< commentstring<"
\ .. "| unlet b:match_ignorecase b:match_words b:match_skip"
Using ":setlocal" with "<" after the option name resets the option to its
global value. That is mostly the best way to reset the option value.
This does require removing the "C" flag from 'cpoptions' to allow line
continuation, as mentioned above |use-cpo-save|.
For undoing the effect of an indent script, the b:undo_indent variable should
be set accordingly.
Both these variables use legacy script syntax, not |Vim9| syntax.
FILE NAME
The filetype must be included in the file name |ftplugin-name|. Use one of
these three forms:
.../ftplugin/stuff.vim
.../ftplugin/stuff_foo.vim
.../ftplugin/stuff/bar.vim
"stuff" is the filetype, "foo" and "bar" are arbitrary names.
SUMMARY *ftplugin-special*
Summary of special things to use in a filetype plugin:
<LocalLeader> Value of "maplocalleader", which the user defines as
the keys that filetype plugin mappings start with.
map <buffer> Define a mapping local to the buffer.
noremap <script> Only remap mappings defined in this script that start
with <SID>.
setlocal Set an option for the current buffer only.
command -buffer Define a user command local to the buffer.
exists("*s:Func") Check if a function was already defined.
Also see |plugin-special|, the special things used for all plugins.
==============================================================================
*51.3* Writing a compiler plugin *write-compiler-plugin*
A compiler plugin sets options for use with a specific compiler. The user can
load it with the |:compiler| command. The main use is to set the
'errorformat' and 'makeprg' options.
Easiest is to have a look at examples. This command will edit all the default
compiler plugins: >
next $VIMRUNTIME/compiler/*.vim
Type `:next` to go to the next plugin file.
There are two special items about these files. First is a mechanism to allow
a user to overrule or add to the default file. The default files start with: >
vim9script
if exists("g:current_compiler")
finish
endif
g:current_compiler = "mine"
When you write a compiler file and put it in your personal runtime directory
(e.g., ~/.vim/compiler for Unix), you set the "current_compiler" variable to
make the default file skip the settings.
*:CompilerSet*
The second mechanism is to use ":set" for ":compiler!" and ":setlocal" for
":compiler". Vim defines the ":CompilerSet" user command for this. However,
older Vim versions don't, thus your plugin should define it then. This is an
example: >
if exists(":CompilerSet") != 2
command -nargs=* CompilerSet setlocal <args>
endif
CompilerSet errorformat& " use the default 'errorformat'
CompilerSet makeprg=nmake
When you write a compiler plugin for the Vim distribution or for a system-wide
runtime directory, use the mechanism mentioned above. When
"current_compiler" was already set by a user plugin nothing will be done.
When you write a compiler plugin to overrule settings from a default plugin,
don't check "current_compiler". This plugin is supposed to be loaded
last, thus it should be in a directory at the end of 'runtimepath'. For Unix
that could be ~/.vim/after/compiler.
==============================================================================
*51.4* Writing a plugin that loads quickly *write-plugin-quickload*
A plugin may grow and become quite long. The startup delay may become
noticeable, while you hardly ever use the plugin. Then it's time for a
quickload plugin.
The basic idea is that the plugin is loaded twice. The first time user
commands and mappings are defined that offer the functionality. The second
time the functions that implement the functionality are defined.
It may sound surprising that quickload means loading a script twice. What we
mean is that it loads quickly the first time, postponing the bulk of the
script to the second time, which only happens when you actually use it. When
you always use the functionality it actually gets slower!
This uses a FuncUndefined autocommand. Since Vim 7 there is an alternative:
use the |autoload| functionality |51.5|. That will also use |Vim9| script
instead of legacy script that is used here.
The following example shows how it's done: >
" Vim global plugin for demonstrating quick loading
" Last Change: 2005 Feb 25
" Maintainer: Bram Moolenaar <Bram@vim.org>
" License: This file is placed in the public domain.
if !exists("s:did_load")
command -nargs=* BNRead call BufNetRead(<f-args>)
map <F19> :call BufNetWrite('something')<CR>
let s:did_load = 1
exe 'au FuncUndefined BufNet* source ' .. expand('<sfile>')
finish
endif
function BufNetRead(...)
echo 'BufNetRead(' .. string(a:000) .. ')'
" read functionality here
endfunction
function BufNetWrite(...)
echo 'BufNetWrite(' .. string(a:000) .. ')'
" write functionality here
endfunction
When the script is first loaded "s:did_load" is not set. The commands between
the "if" and "endif" will be executed. This ends in a |:finish| command, thus
the rest of the script is not executed.
The second time the script is loaded "s:did_load" exists and the commands
after the "endif" are executed. This defines the (possible long)
BufNetRead() and BufNetWrite() functions.
If you drop this script in your plugin directory Vim will execute it on
startup. This is the sequence of events that happens:
1. The "BNRead" command is defined and the <F19> key is mapped when the script
is sourced at startup. A |FuncUndefined| autocommand is defined. The
":finish" command causes the script to terminate early.
2. The user types the BNRead command or presses the <F19> key. The
BufNetRead() or BufNetWrite() function will be called.
3. Vim can't find the function and triggers the |FuncUndefined| autocommand
event. Since the pattern "BufNet*" matches the invoked function, the
command "source fname" will be executed. "fname" will be equal to the name
of the script, no matter where it is located, because it comes from
expanding "<sfile>" (see |expand()|).
4. The script is sourced again, the "s:did_load" variable exists and the
functions are defined.
Notice that the functions that are loaded afterwards match the pattern in the
|FuncUndefined| autocommand. You must make sure that no other plugin defines
functions that match this pattern.
==============================================================================
*51.5* Writing library scripts *write-library-script*
Some functionality will be required in several places. When this becomes more
than a few lines you will want to put it in one script and use it from many
scripts. We will call that one script a library script.
Manually loading a library script is possible, so long as you avoid loading it
when it's already done. You can do this with the |exists()| function.
Example: >
if !exists('*MyLibFunction')
runtime library/mylibscript.vim
endif
MyLibFunction(arg)
Here you need to know that MyLibFunction() is defined in a script
"library/mylibscript.vim" in one of the directories in 'runtimepath'.
To make this a bit simpler Vim offers the autoload mechanism. Then the
example looks like this: >
mylib#myfunction(arg)
That's a lot simpler, isn't it? Vim will recognize the function name by the
embedded "#" character and when it's not defined search for the script
"autoload/mylib.vim" in 'runtimepath'. That script must define the
"mylib#myfunction()" function.
You can put many other functions in the mylib.vim script, you are free to
organize your functions in library scripts. But you must use function names
where the part before the '#' matches the script name. Otherwise Vim would
not know what script to load.
If you get really enthusiastic and write lots of library scripts, you may
want to use subdirectories. Example: >
netlib#ftp#read('somefile')
For Unix the library script used for this could be:
~/.vim/autoload/netlib/ftp.vim
Where the function is defined like this: >
def netlib#ftp#read(fname: string)
# Read the file fname through ftp
enddef
Notice that the name the function is defined with is exactly the same as the
name used for calling the function. And the part before the last '#'
exactly matches the subdirectory and script name.
You can use the same mechanism for variables: >
var weekdays = dutch#weekdays
This will load the script "autoload/dutch.vim", which should contain something
like: >
var dutch#weekdays = ['zondag', 'maandag', 'dinsdag', 'woensdag',
\ 'donderdag', 'vrijdag', 'zaterdag']
Further reading: |autoload|.
==============================================================================
*51.6* Distributing Vim scripts *distribute-script*
Vim users will look for scripts on the Vim website: http://www.vim.org.
If you made something that is useful for others, share it!
Another place is github. But there you need to know where to find it! The
advantage is that most plugin managers fetch plugins from github. You'll have
to use your favorite search engine to find them.
Vim scripts can be used on any system. However, there might not be a tar or
gzip command. If you want to pack files together and/or compress them the
"zip" utility is recommended.
For utmost portability use Vim itself to pack scripts together. This can be
done with the Vimball utility. See |vimball|.
It's good if you add a line to allow automatic updating. See |glvs-plugins|.
==============================================================================
Next chapter: |usr_52.txt| Write plugins using Vim9 script
Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl:

20
runtime/doc/usr_46.txt → runtime/doc/usr_52.txt
View File

@@ -1,4 +1,4 @@
*usr_46.txt* For Vim version 8.2. Last change: 2020 Jun 14
*usr_52.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
@@ -9,17 +9,17 @@ The Vim9 script language is used for writing plugins, especially larger ones
that use multiple files. This chapter explains how to split up a plugin into
modules, import and export items and keep the rest local.
|46.1| Introduction
|46.2| Variable declarations
|46.3| Functions and types
|46.?| Using a Vim9 script from legacy script
|52.1| Introduction
|52.2| Variable declarations
|52.3| Functions and types
|52.4| Using a Vim9 script from legacy script
Next chapter: |usr_90.txt| Installing Vim
Previous chapter: |usr_45.txt| Select your language (locale)
Previous chapter: |usr_51.txt| Create a plugin
Table of contents: |usr_toc.txt|
==============================================================================
*46.1* Introduction *vim9-script-intro*
*52.1* Introduction *vim9-script-intro*
Vim9 script was designed to make it easier to write large Vim scripts. It
looks more like other script languages, especially Typescript. Also,
@@ -69,7 +69,7 @@ Notice that the assignment `result = GetPart(count)` does not use the `let`
command. That is explained in the next section.
==============================================================================
*46.2* Variable declarations *vim9-declarations*
*52.2* Variable declarations *vim9-declarations*
In Vim9 script variables are declared once with a `:let` or `:const` command.
Assigning a value is done without `:let` and it is not possible to `:unlet`
@@ -108,7 +108,7 @@ Although it's shorter to do: >
let word = condition ? 'yes' : 'no'
==============================================================================
*46.3* Functions and types
*52.3* Functions and types
Legacy Vim script does have type checking, but this happens at runtime, when
the code is executed. And it's permissive, often a computation gives an
@@ -161,7 +161,7 @@ multiple types, you can use the "any" type: >
enddef
==============================================================================
*46.?* Using a Vim9 script from legacy script *source-vim9-script*
*52.4* Using a Vim9 script from legacy script *source-vim9-script*
In some cases you have a legacy Vim script where you want to use items from a
Vim9 script. For example in your .vimrc you want to initialize a plugin. The

4
runtime/doc/usr_90.txt
View File

@@ -1,4 +1,4 @@
*usr_90.txt* For Vim version 8.2. Last change: 2020 Jun 11
*usr_90.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
@@ -15,7 +15,7 @@ upgrading to a new version is done.
|90.4| Common installation issues
|90.5| Uninstalling Vim
Previous chapter: |usr_46.txt| Write plugins using Vim9 script
Previous chapter: |usr_52.txt| Write plugins using Vim9 script
Table of contents: |usr_toc.txt|
==============================================================================

51
runtime/doc/usr_toc.txt
View File

@@ -1,4 +1,4 @@
*usr_toc.txt* For Vim version 8.2. Last change: 2020 Jun 15
*usr_toc.txt* For Vim version 8.2. Last change: 2022 May 13
VIM USER MANUAL - by Bram Moolenaar
@@ -7,7 +7,7 @@
==============================================================================
Overview ~
Getting Started
Getting Started ~
|usr_01.txt| About the manuals
|usr_02.txt| The first steps in Vim
|usr_03.txt| Moving around
@@ -21,7 +21,7 @@ Getting Started
|usr_11.txt| Recovering from a crash
|usr_12.txt| Clever tricks
Editing Effectively
Editing Effectively ~
|usr_20.txt| Typing command-line commands quickly
|usr_21.txt| Go away and come back
|usr_22.txt| Finding the file to edit
@@ -36,24 +36,28 @@ Editing Effectively
|usr_31.txt| Exploiting the GUI
|usr_32.txt| The undo tree
Tuning Vim
Tuning Vim ~
|usr_40.txt| Make new commands
|usr_41.txt| Write a Vim script
|usr_42.txt| Add new menus
|usr_43.txt| Using filetypes
|usr_44.txt| Your own syntax highlighted
|usr_45.txt| Select your language (locale)
|usr_46.txt| Write plugins using Vim9 script
Making Vim Run
Writing Vim script ~
|usr_50.txt| Advanced Vim script writing
|usr_51.txt| Create a plugin
|usr_52.txt| Write plugins using Vim9 script
Making Vim Run ~
|usr_90.txt| Installing Vim
Reference manual
Reference manual ~
|reference_toc| More detailed information for all commands
The user manual is available as a single, ready to print HTML and PDF file
here:
The user manual (an older version) is available as a single, ready to print
HTML and PDF file here:
http://vimdoc.sf.net
==============================================================================
@@ -302,12 +306,6 @@ Make Vim work as you like it.
|41.8| Lists and Dictionaries
|41.9| Exceptions
|41.10| Various remarks
|41.11| Writing a plugin
|41.12| Writing a filetype plugin
|41.13| Writing a compiler plugin
|41.14| Writing a plugin that loads quickly
|41.15| Writing library scripts
|41.16| Distributing Vim scripts
|usr_42.txt| Add new menus
|42.1| Introduction
@@ -340,11 +338,24 @@ Make Vim work as you like it.
|45.4| Editing files with a different encoding
|45.5| Entering language text
|usr_46.txt| Write plugins using Vim9 script
|46.1| Introduction
|46.2| Variable declarations
|46.3| Functions and types
|46.?| Using a Vim9 script from legacy script
==============================================================================
Writing Vim script ~
|usr_50.txt| TODO
|usr_51.txt| Write plugins
|51.1| Writing a generic plugin
|51.2| Writing a filetype plugin
|51.3| Writing a compiler plugin
|51.4| Writing a plugin that loads quickly
|51.5| Writing library scripts
|51.6| Distributing Vim scripts
|usr_52.txt| Write plugins using Vim9 script
|52.1| Introduction
|52.2| Variable declarations
|52.3| Functions and types
|52.4| Using a Vim9 script from legacy script
==============================================================================
Making Vim Run ~

5
runtime/doc/vim9.txt
View File

@@ -1,4 +1,4 @@
*vim9.txt* For Vim version 8.2. Last change: 2022 Apr 28
*vim9.txt* For Vim version 8.2. Last change: 2022 May 13
VIM REFERENCE MANUAL by Bram Moolenaar
@@ -294,7 +294,8 @@ You can use an autoload function if needed, or call a legacy function and have
Reloading a Vim9 script clears functions and variables by default ~
*vim9-reload* *E1149* *E1150*
When loading a legacy Vim script a second time nothing is removed, the
commands will replace existing variables and functions and create new ones.
commands will replace existing variables and functions, create new ones, and
leave removed things hanging around.
When loading a Vim9 script a second time all existing script-local functions
and variables are deleted, thus you start with a clean slate. This is useful