diff --git a/runtime/doc/api.txt b/runtime/doc/api.txt
index 1ad9f62227..cc497fa5e4 100644
--- a/runtime/doc/api.txt
+++ b/runtime/doc/api.txt
@@ -899,18 +899,24 @@ nvim_get_color_map()                                    *nvim_get_color_map()*
         (`table<string,integer>`) Map of color names and RGB values.
 
 nvim_get_context({opts})                                  *nvim_get_context()*
-    Gets a map of the current editor state.
+    Gets a map (msgpack encoding) of the current editor state:
+    • "bufs" |buffer-list|
+    • "funcs" Vimscript global and |script-local| functions
+    • "gvars" |global-variable|s
+    • "jumps" |jumplist|
+    • "regs" |registers|
+    • "sfuncs" Vimscript |script-local| functions
 
     Attributes: ~
         Since: 0.4.0
 
     Parameters: ~
       • {opts}  (`vim.api.keyset.context?`) Optional parameters.
-                • types: List of |context-types| ("regs", "jumps", "bufs",
-                  "gvars", …) to gather, or empty for "all".
+                • types: List of context types (see above) to gather, or empty
+                  for "all".
 
     Return: ~
-        (`table<string,any>`) map of global |context|.
+        (`table<string,any>`) Editor state as a msgpack-encoded map.
 
 nvim_get_current_buf()                                *nvim_get_current_buf()*
     Gets the current buffer.
@@ -1260,13 +1266,14 @@ nvim_list_wins()                                            *nvim_list_wins()*
         (`integer[]`) List of |window-ID|s
 
 nvim_load_context({dict})                                *nvim_load_context()*
-    Sets the current editor state from the given |context| map.
+    Sets the current editor state from the given map.
 
     Attributes: ~
         Since: 0.4.0
 
     Parameters: ~
-      • {dict}  (`table<string,any>`) |Context| map.
+      • {dict}  (`table<string,any>`) Msgpack-encoded editor state, in the
+                form returned by |nvim_get_context()|.
 
     Return: ~
         (`any`)
diff --git a/runtime/doc/intro.txt b/runtime/doc/intro.txt
index 45890af1b9..68a79bce01 100644
--- a/runtime/doc/intro.txt
+++ b/runtime/doc/intro.txt
@@ -388,19 +388,21 @@ CTRL-\ CTRL-G works the same as |CTRL-\_CTRL-N| for backward compatibility.
 
                                 *:exm* *:exmode* *gQ* *mode-Ex* *Ex-mode* *Ex* *EX* *E501*
 :exm[ode]
-[count]q:               Switch to Ex mode.  This is like typing ":" commands
-                        one after another, except you don't have to keep
-                        pressing ":". Use |:visual| to exit this mode.
+[count]q:               Switch to Ex mode.  This is like the |cmdwin| except
+                        it stays open, in Insert-mode, so can you keep
+                        entering ":" commands (REPL style). Use |:visual| to
+                        exit this mode.
+
+                        If a command moves the cursor or changes the buffer,
+                        the current line is printed.  An empty line moves to
+                        (and prints) the next line.
+
                         Without [count], "q:" opens the regular |cmdwin|.
 
-                        Implementation details: a persistent |cmdwin| where
-                        <Enter> executes the current line as a command
-                        (against the window from which Ex mode was entered)
-                        and stays open, in insert-mode.  Command output is
-                        presented as comment (") lines.  After a command that
-                        moves the cursor or changes the buffer, the current
-                        line is printed.  An empty line moves to (and prints)
-                        the next line.
+                        Implementation: a persistent |cmdwin| where <Enter>
+                        executes the current line as a command (against the
+                        window from which Ex mode was entered). Command output
+                        is presented as comment (") lines.
 
 ==============================================================================
 Window contents                                         *window-contents*
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index ce252108ea..87dc10076f 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -781,13 +781,18 @@ A jump table for the options with a short description can be found at |Q_op|.
 			*'autochdir'* *'acd'* *'noautochdir'* *'noacd'*
 'autochdir' 'acd'	boolean	(default off)
 			global
-	When on, Vim will change the current working directory whenever you
-	open a file, switch buffers, delete a buffer or open/close a window.
-	It will change to the directory containing the file which was opened
-	or selected.  When a buffer has no name it also has no directory, thus
-	the current directory won't change when navigating to it.
+	When on, Nvim will change its global |current-directory| to the parent
+	of the current file, whenever you open a file, switch buffers, delete
+	a buffer or open/close a window.
+
+	When a buffer has no name it also has no directory, thus the current
+	directory won't change when navigating to it.
+
 	Note: When this option is on some plugins may not work.
 
+	Alternatively, consider using |:bcd|, |:lcd|, or |:tcd| in an autocmd,
+	to selectively set a local (not global) directory. See |project-dir|.
+
 			*'autocomplete'* *'ac'* *'noautocomplete'* *'noac'*
 'autocomplete' 'ac'	boolean	(default off)
 			global or local to buffer |global-local|
diff --git a/runtime/doc/plugins.txt b/runtime/doc/plugins.txt
index a3adf3e3bd..315ebf279b 100644
--- a/runtime/doc/plugins.txt
+++ b/runtime/doc/plugins.txt
@@ -138,6 +138,7 @@ This clears the built-in directory-opening autocommands. >lua
       end,
     })
 <
+                                                                       *netrw*
 To enable the legacy "netrw" plugin: >vim
 
     :packadd netrw
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 10f1813873..9660af5c1c 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -4,7 +4,7 @@
                             NVIM REFERENCE MANUAL
 
 
-Repeating commands, Vim scripts and debugging			*repeating*
+Repeating commands						*repeating*
 
 Chapter 26 of the user manual introduces repeating |usr_26.txt|.
 
@@ -213,736 +213,5 @@ Multiple cursors					*mcursor* *multicursor*
 
 todo
 
-==============================================================================
-Using Vim scripts					*using-scripts*
-
-For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|.
-
-					*:so* *:source*
-:so[urce] {file}	Runs |Ex-command|s or Lua code (".lua" files) from
-			{file}. Triggers the |SourcePre| autocommand.
-
-:[range]so[urce]	Read Ex commands or Lua code from the [range] of lines
-			in the current buffer.  When [range] is omitted read
-			all lines.  The buffer is treated as Lua code if its
-			'filetype' is "lua" or its filename ends with ".lua".
-
-			When sourcing commands or Lua code from the current
-			buffer, the same script-ID |<SID>| is used even if the
-			buffer is sourced multiple times.  If a buffer is
-			sourced more than once, then the functions in the
-			buffer are defined again.
-
-			Implementation detail: When sourcing a [range] of
-			lines that falls inside a folded region, the range
-			will be adjusted to the start and end of the fold,
-			but only if a two line specifiers range was used.
-
-							*:source!*
-:so[urce]! {file}	Runs |Normal-mode| commands from {file}. When used
-			after |:global|, |:argdo|, |:windo|, |:bufdo|, in
-			a loop or when another command follows the display
-			won't be updated while executing the commands.
-
-							*:ru* *:runtime*
-:ru[ntime][!] [where] {file} ..
-			Sources |Ex| commands or Lua code (".lua" files) read
-			from {file} (a relative path) in each directory given
-			by 'runtimepath' and/or 'packpath'.
-			Ignores non-existing files.
-
-			Example: >
-				:runtime syntax/c.vim
-				:runtime syntax/c.lua
-
-<			There can be multiple space-separated {file}
-			arguments. Each {file} is searched for in the first
-			directory from 'runtimepath', then in the second
-			directory, etc.
-
-			When [!] is included, all found files are sourced.
-			Else only the first found file is sourced.
-
-			When [where] is omitted only 'runtimepath' is used.
-			Other values:
-				START	search only under "start" in 'packpath'
-				OPT	search only under "opt" in 'packpath'
-				PACK	search under "start" and "opt" in
-					'packpath'
-				ALL	first use 'runtimepath', then search
-					under "start" and "opt" in 'packpath'
-
-			When {file} contains wildcards it is expanded to all
-			matching files.  Example: >
-				:runtime! plugin/**/*.{vim,lua}
-<			This is what Nvim uses to load the plugin files when
-			starting up.  This similar command: >
-				:runtime plugin/**/*.{vim,lua}
-<			would source the first file only.
-
-			For each {file} pattern, if two `.vim` and `.lua` file
-			names match and differ only in extension, the `.vim`
-			file is sourced first.
-
-			When 'verbose' is one or higher, there is a message
-			when no file could be found.
-			When 'verbose' is two or higher, there is a message
-			about each searched file.
-
-							*:pa* *:packadd* *E919*
-:pa[ckadd][!] {name}	|pack-add| Search for an optional plugin directory in
-			'packpath', source any plugin files found, and add it
-			to 'runtimepath'.  The directory must match: >
-				pack/*/opt/{name}
-<			If the directory pack/*/opt/{name}/after exists it is
-			added at the end of 'runtimepath'.
-
-			Note: Use |vim.pack.add()| to install from a URL.
-
-			If loading packages from "pack/*/start" was skipped,
-			then this directory is searched first: >
-				pack/*/start/{name}
-<
-			Note that {name} is the directory name, not the name
-			of the .vim file.  All files matching the patterns >
-				pack/*/opt/{name}/plugin/**/*.vim
-				pack/*/opt/{name}/plugin/**/*.lua
-<			will be sourced.  This allows for using subdirectories
-			below "plugin", just like with plugins in
-			'runtimepath'.
-
-			If the filetype detection was already enabled (this
-			is usually done with a `syntax enable` or `filetype on`
-			command in your |vimrc|, or automatically during
-			|initialization|), and the package was found in
-			"pack/*/opt/{name}", this command will also look
-			for "{name}/ftdetect/*.vim" files.
-
-			When the optional "!" is given, no plugin/ files or
-			ftdetect/ scripts are loaded, only the matching
-			directories are added to 'runtimepath'.  This is
-			useful in your |init.vim|.  The plugins will then be
-			loaded during the |load-plugins| |initialization| step
-			(note that the loading order will be reversed because
-			each directory is inserted before others), after
-			loading the ftdetect scripts.
-
-			To programmatically decide if `!` is needed during
-			startup, check |v:vim_did_init|: use `!` if 0 (to not
-			duplicate |load-plugins| step), no `!` otherwise (to
-			force load plugin files as otherwise they won't be
-			loaded automatically).
-
-						*:packl* *:packloadall*
-:packl[oadall][!]	Load all packages in the "start" directory under each
-			entry in 'packpath'.
-
-			First all the directories found are added to
-			'runtimepath', then the plugins found in the
-			directories are sourced.  This allows for a plugin to
-			depend on something of another plugin, e.g. an
-			"autoload" directory.  See |packload-two-steps| for
-			how this can be useful.
-
-			This is normally done automatically during startup,
-			after loading your |vimrc| file.  With this command it
-			can be done earlier.
-
-			Packages will be loaded only once.  Using
-			`:packloadall` a second time will have no effect.
-			When the optional ! is added this command will load
-			packages even when done before.
-
-			Note that when using `:packloadall` in the |vimrc|
-			file, the 'runtimepath' option is updated, and later
-			all plugins in 'runtimepath' will be loaded, which
-			means they are loaded again.  Plugins are expected to
-			handle that.
-
-			An error only causes sourcing the script where it
-			happens to be aborted, further plugins will be loaded.
-			See |packages|.
-
-:scripte[ncoding] [encoding]		*:scripte* *:scriptencoding* *E167*
-			Specify the character encoding used in the script.
-			The following lines will be converted from [encoding]
-			to the value of the 'encoding' option, if they are
-			different.  Examples: >
-				scriptencoding iso-8859-5
-				scriptencoding cp932
-<
-			When [encoding] is empty, no conversion is done.  This
-			can be used to restrict conversion to a sequence of
-			lines: >
-				scriptencoding euc-jp
-				... lines to be converted ...
-				scriptencoding
-				... not converted ...
-
-<			When conversion isn't supported by the system, there
-			is no error message and no conversion is done.  When a
-			line can't be converted there is no error and the
-			original line is kept.
-
-			Don't use "ucs-2" or "ucs-4", scripts cannot be in
-			these encodings (they would contain NUL bytes).
-			When a sourced script starts with a BOM (Byte Order
-			Mark) in utf-8 format Vim will recognize it, no need
-			to use ":scriptencoding utf-8" then.
-
-						*:scr* *:scriptnames*
-:scr[iptnames]		List all sourced script names, in the order they were
-			first sourced.  The number is used for the script ID
-			|<SID>|.
-			Also see `getscriptinfo()`.
-
-:scr[iptnames][!] {scriptId}			*:script*
-			Edit script {scriptId}.  Although ":scriptnames name"
-			works, using ":script name" is recommended.
-			When the current buffer can't be |abandon|ed and the !
-			is not present, the command fails.
-
-						*:fini* *:finish* *E168*
-:fini[sh]		Stop sourcing a script.  Can only be used in a Vim
-			script file.  This is a quick way to skip the rest of
-			the file.  If it is used after a |:try| but before the
-			matching |:finally| (if present), the commands
-			following the ":finally" up to the matching |:endtry|
-			are executed first.  This process applies to all
-			nested ":try"s in the script.  The outermost ":endtry"
-			then stops sourcing the script.
-
-All commands and command sequences can be repeated by putting them in a named
-register and then executing it.  There are two ways to get the commands in the
-register:
-- Use the record command "q".  You type the commands once, and while they are
-  being executed they are stored in a register.  Easy, because you can see
-  what you are doing.  If you make a mistake, "p"ut the register into the
-  file, edit the command sequence, and then delete it into the register
-  again.  You can continue recording by appending to the register (use an
-  uppercase letter).
-- Delete or yank the command sequence into the register.
-
-Often used command sequences can be put under a function key with the ':map'
-command.
-
-An alternative is to put the commands in a file, and execute them with the
-':source!' command.  Useful for long command sequences.  Can be combined with
-the ':map' command to put complicated commands under a function key.
-
-The ':source' command reads Ex commands from a file or a buffer line by line.
-You will have to type any needed keyboard input.  The ':source!' command reads
-from a script file character by character, interpreting each character as if
-you typed it.
-
-Example: When you give the ":!ls" command you get the |hit-enter| prompt.  If
-you ':source' a file with the line "!ls" in it, you will have to type the
-<Enter> yourself.  But if you ':source!' a file with the line ":!ls" in it,
-the next characters from that file are read until a <CR> is found.  You will
-not have to type <CR> yourself, unless ":!ls" was the last line in the file.
-
-It is possible to put ':source[!]' commands in the script file, so you can
-make a top-down hierarchy of script files.  The ':source' command can be
-nested as deep as the number of files that can be opened at one time (about
-15).  The ':source!' command can be nested up to 15 levels deep.
-
-You can use the "<script>" string (literally, this is not a special key) inside
-of the sourced file, in places where a file name is expected.  It will be
-replaced by the file name of the sourced file.  For example, if you have a
-"other.vimrc" file in the same directory as your |init.vim| file, you can
-source it from your |init.vim| file with this command: >
-	:source <script>:h/other.vimrc
-
-In script files terminal-dependent key codes are represented by
-terminal-independent two character codes.  This means that they can be used
-in the same way on different kinds of terminals.  The first character of a
-key code is 0x80 or 128, shown on the screen as "~@".  The second one can be
-found in the list |key-notation|.  Any of these codes can also be entered
-with CTRL-V followed by the three digit decimal code.
-
-							*:source_crnl* *W15*
-Windows: Files that are read with ":source" normally have <CR><NL> <EOL>s.
-These always work.  If you are using a file with <NL> <EOL>s (for example, a
-file made on Unix), this will be recognized if 'fileformats' is not empty and
-the first line does not end in a <CR>.  This fails if the first line has
-something like ":map <F1> :help^M", where "^M" is a <CR>.  If the first line
-ends in a <CR>, but following ones don't, you will get an error message,
-because the <CR> from the first lines will be lost.
-
-On other systems, Vim expects ":source"ed files to end in a <NL>.  These
-always work.  If you are using a file with <CR><NL> <EOL>s (for example, a
-file made on MS-Windows), all lines will have a trailing <CR>.  This may cause
-problems for some commands (e.g., mappings).  There is no automatic <EOL>
-detection, because it's common to start with a line that defines a mapping
-that ends in a <CR>, which will confuse the automaton.
-
-							*line-continuation*
-Long lines in a ":source"d Ex command script file can be split by inserting
-a line continuation symbol "\" (backslash) at the start of the next line.
-There can be white space before the backslash, which is ignored.
-
-Example: the lines >
-	:set comments=sr:/*,mb:*,el:*/,
-		     \://,
-		     \b:#,
-		     \:%,
-		     \n:>,
-		     \fb:-
-are interpreted as if they were given in one line: >
-	:set comments=sr:/*,mb:*,el:*/,://,b:#,:%,n:>,fb:-
-
-All leading whitespace characters in the line before a backslash are ignored.
-Note however that trailing whitespace in the line before it cannot be
-inserted freely; it depends on the position where a command is split up
-whether additional whitespace is allowed or not.
-
-When a space is required it's best to put it right after the backslash.  A
-space at the end of a line is hard to see and may be accidentally deleted. >
-	:syn match Comment
-		\ "very long regexp"
-		\ keepend
-
-There is a problem with the ":append" and ":insert" commands: >
-   :1append
-   \asdf
-   .
-The backslash is seen as a line-continuation symbol, thus this results in the
-command: >
-   :1appendasdf
-   .
-To avoid this, add the 'C' flag to the 'cpoptions' option: >
-   :set cpo+=C
-   :1append
-   \asdf
-   .
-   :set cpo-=C
-
-Note that when the commands are inside a function, you need to add the 'C'
-flag when defining the function, it is not relevant when executing it. >
-   :set cpo+=C
-   :function Foo()
-   :1append
-   \asdf
-   .
-   :endfunction
-   :set cpo-=C
-<
-					*line-continuation-comment*
-To add a comment in between the lines start with `'"\ '`.  Notice the space
-after the backslash.  Example: >
-	let array = [
-		"\ first entry comment
-		\ 'first',
-		"\ second entry comment
-		\ 'second',
-		\ ]
-
-Rationale:
-	Most programs work with a trailing backslash to indicate line
-	continuation.  Using this in Vim would cause incompatibility with Vi.
-	For example for this Vi mapping: >
-		:map xx  asdf\
-<	Therefore the unusual leading backslash is used.
-
-	Starting a comment in a continuation line results in all following
-	continuation lines to be part of the comment.  Since it was like this
-	for a long time, when making it possible to add a comment halfway a
-	sequence of continuation lines, it was not possible to use \", since
-	that was a valid continuation line.  Using `'"\ '` comes closest, even
-	though it may look a bit weird.  Requiring the space after the
-	backslash is to make it very unlikely this is a normal comment line.
-
-==============================================================================
-Debugging scripts					*debug-scripts*
-
-Besides the obvious messages that you can add to your scripts to find out what
-they are doing, Vim offers a debug mode.  This allows you to step through a
-sourced file or user function and set breakpoints.
-
-NOTE: The debugging mode is far from perfect.  Debugging will have side
-effects on how Vim works.  You cannot use it to debug everything.  For
-example, the display is messed up by the debugging messages.
-
-An alternative to debug mode is setting the 'verbose' option.  With a bigger
-number it will give more verbose messages about what Vim is doing.
-
-
-STARTING DEBUG MODE						*debug-mode*
-
-To enter debugging mode use one of these methods:
-1. Start Vim with the |-D| argument: >
-	vim -D file.txt
-<  Debugging will start as soon as the first vimrc file is sourced.  This is
-   useful to find out what is happening when Vim is starting up.  A side
-   effect is that Vim will switch the terminal mode before initialisations
-   have finished, with unpredictable results.
-   For a GUI-only version (Windows) the debugging will start as
-   soon as the GUI window has been opened.  To make this happen early, add a
-   ":gui" command in the vimrc file.
-								*:debug*
-2. Run a command with ":debug" prepended.  Debugging will only be done while
-   this command executes.  Useful for debugging a specific script or user
-   function.  And for scripts and functions used by autocommands.  Example: >
-	:debug edit test.txt.gz
-
-3. Set a breakpoint in a sourced file or user function.  You could do this in
-   the command line: >
-	vim -c "breakadd file */explorer.vim" .
-<  This will run Vim and stop in the first line of the "explorer.vim" script.
-   Breakpoints can also be set while in debugging mode.
-
-In debugging mode every executed command is displayed before it is executed.
-Comment lines, empty lines and lines that are not executed are skipped.  When
-a line contains two commands, separated by "|", each command will be displayed
-separately.
-
-
-DEBUG MODE
-
-Once in debugging mode, the usual Ex commands can be used.  For example, to
-inspect the value of a variable: >
-	echo idx
-When inside a user function, this will print the value of the local variable
-"idx".  Prepend "g:" to get the value of a global variable: >
-	echo g:idx
-All commands are executed in the context of the current function or script.
-You can also set options, for example setting or resetting 'verbose' will show
-what happens, but you might want to set it just before executing the lines you
-are interested in: >
-	:set verbose=20
-
-Commands that require updating the screen should be avoided, because their
-effect won't be noticed until after leaving debug mode.  For example: >
-	:help
-won't be very helpful.
-
-There is a separate command-line history for debug mode.
-
-The line number for a function line is relative to the start of the function.
-If you have trouble figuring out where you are, edit the file that defines
-the function in another Vim, search for the start of the function and do
-"99j".  Replace "99" with the line number.
-
-Additionally, these commands can be used:
-							*>cont*
-	cont		Continue execution until the next breakpoint is hit.
-							*>quit*
-	quit		Abort execution.  This is like using CTRL-C, some
-			things might still be executed, doesn't abort
-			everything.  Still stops at the next breakpoint.
-							*>next*
-	next		Execute the command and come back to debug mode when
-			it's finished.  This steps over user function calls
-			and sourced files.
-							*>step*
-	step		Execute the command and come back to debug mode for
-			the next command.  This steps into called user
-			functions and sourced files.
-							*>interrupt*
-	interrupt	This is like using CTRL-C, but unlike ">quit" comes
-			back to debug mode for the next command that is
-			executed.  Useful for testing |:finally| and |:catch|
-			on interrupt exceptions.
-							*>finish*
-	finish		Finish the current script or user function and come
-			back to debug mode for the command after the one that
-			sourced or called it.
-							*>bt*
-							*>backtrace*
-							*>where*
-	backtrace	Show the call stacktrace for current debugging
-			session.
-	bt
-	where
-							*>frame*
-	frame N		Goes to N backtrace level. + and - signs make movement
-			relative.  E.g., ":frame +3" goes three frames up.
-							*>up*
-	up		Goes one level up from call stacktrace.
-							*>down*
-	down		Goes one level down from call stacktrace.
-
-About the additional commands in debug mode:
-- There is no command-line completion for them, you get the completion for the
-  normal Ex commands only.
-- You can shorten them, up to a single character, unless more than one command
-  starts with the same letter.  "f" stands for "finish", use "fr" for "frame".
-- Hitting <CR> will repeat the previous one.  When doing another command, this
-  is reset (because it's not clear what you want to repeat).
-- When you want to use the Ex command with the same name, prepend a colon:
-  ":cont", ":next", ":finish" (or shorter).
-
-The backtrace shows the hierarchy of function calls, e.g.:
-	>bt ~
-	  3 function One[3] ~
-	  2 Two[3] ~
-	->1 Three[3] ~
-	  0 Four ~
-	line 1: let four = 4 ~
-
-The "->" points to the current frame.  Use "up", "down" and "frame N" to
-select another frame.
-
-In the current frame you can evaluate the local function variables.  There is
-no way to see the command at the current line yet.
-
-
-DEFINING BREAKPOINTS
-							*:breaka* *:breakadd*
-:breaka[dd] func [lnum] {name}
-		Set a breakpoint in a function.  Example: >
-			:breakadd func Explore
-<		Doesn't check for a valid function name, thus the breakpoint
-		can be set before the function is defined.
-
-:breaka[dd] file [lnum] {name}
-		Set a breakpoint in a sourced file.  Example: >
-			:breakadd file 43 init.vim
-
-:breaka[dd] here
-		Set a breakpoint in the current line of the current file.
-		Like doing: >
-			:breakadd file <cursor-line> <current-file>
-<		Note that this only works for commands that are executed when
-		sourcing the file, not for a function defined in that file.
-
-:breaka[dd] expr {expression}
-		Sets a breakpoint, that will break whenever the {expression}
-		evaluates to a different value.  Example: >
-			:breakadd expr g:lnum
-<		Will break, whenever the global variable lnum changes.
-
-		Errors in evaluation are suppressed, you can use the name of a
-		variable that does not exist yet.  This also means you will
-		not notice anything if the expression has a mistake.
-
-		Note if you watch a |script-variable| this will break
-		when switching scripts, since the script variable is only
-		valid in the script where it has been defined and if that
-		script is called from several other scripts, this will stop
-		whenever that particular variable will become visible or
-		inaccessible again.
-
-The [lnum] is the line number of the breakpoint.  Vim will stop at or after
-this line.  When omitted line 1 is used.
-
-							*:debug-name*
-{name} is a pattern that is matched with the file or function name.  The
-pattern is like what is used for autocommands.  There must be a full match (as
-if the pattern starts with "^" and ends in "$").  A "*" matches any sequence
-of characters.  'ignorecase' is not used, but "\c" can be used in the pattern
-to ignore case |/\c|.  Don't include the () for the function name!
-
-The match for sourced scripts is done against the full file name.  If no path
-is specified the current directory is used.  Examples: >
-	breakadd file explorer.vim
-matches "explorer.vim" in the current directory. >
-	breakadd file *explorer.vim
-matches ".../plugin/explorer.vim", ".../plugin/iexplorer.vim", etc. >
-	breakadd file */explorer.vim
-matches ".../plugin/explorer.vim" and "explorer.vim" in any other directory.
-
-The match for functions is done against the name as it's shown in the output
-of ":function".  For local functions this means that something like "<SNR>99_"
-is prepended.
-
-Note that functions are first loaded and later executed.  When they are loaded
-the "file" breakpoints are checked, when they are executed the "func"
-breakpoints.
-
-
-DELETING BREAKPOINTS
-						*:breakd* *:breakdel* *E161*
-:breakd[el] {nr}
-		Delete breakpoint {nr}.  Use |:breaklist| to see the number of
-		each breakpoint.
-
-:breakd[el] *
-		Delete all breakpoints.
-
-:breakd[el] func [lnum] {name}
-		Delete a breakpoint in a function.
-
-:breakd[el] file [lnum] {name}
-		Delete a breakpoint in a sourced file.
-
-:breakd[el] here
-		Delete a breakpoint at the current line of the current file.
-
-When [lnum] is omitted, the first breakpoint in the function or file is
-deleted.
-The {name} must be exactly the same as what was typed for the ":breakadd"
-command.  "explorer", "*explorer.vim" and "*explorer*" are different.
-
-
-LISTING BREAKPOINTS
-							*:breakl* *:breaklist*
-:breakl[ist]
-		List all breakpoints.
-
-
-OBSCURE
-
-						*:debugg* *:debuggreedy*
-:debugg[reedy]
-		Read debug mode commands from the normal input stream, instead
-		of getting them directly from the user.  Only useful for test
-		scripts.  Example: >
-		  echo 'q^Mq' | vim -e -s -c debuggreedy -c 'breakadd file script.vim' -S script.vim
-
-:0debugg[reedy]
-		Undo ":debuggreedy": get debug mode commands directly from the
-		user, don't use typeahead for debug commands.
-
-==============================================================================
-Profiling						*profile* *profiling*
-
-Profiling means that Vim measures the time that is spent on executing
-functions and/or scripts.
-
-You can also use the |reltime()| function to measure time.
-
-For profiling syntax highlighting see |:syntime|.
-
-For example, to profile the one_script.vim script file: >
-	:profile start /tmp/one_script_profile
-	:profile file one_script.vim
-	:source one_script.vim
-	:exit
-
-
-:prof[ile] start {fname}			*:prof* *:profile* *E750*
-		Start profiling, write the output in {fname} upon exit or when
-		a `:profile stop` or `:profile dump` command is invoked.
-		"~/" and environment variables in {fname} will be expanded.
-		If {fname} already exists it will be silently overwritten.
-		The variable |v:profiling| is set to one.
-
-:prof[ile] stop
-		Write the collected profiling information to the logfile and
-		stop profiling.  You can use the `:profile start` command to
-		clear the profiling statistics and start profiling again.
-
-:prof[ile] pause
-		Stop profiling until the next `:profile continue` command.
-		Can be used when doing something that should not be counted
-		(e.g., an external command).  Does not nest.
-
-:prof[ile] continue
-		Continue profiling after `:profile pause`.
-
-:prof[ile] func {pattern}
-		Profile function that matches the pattern {pattern}.
-		See |:debug-name| for how {pattern} is used.
-
-:prof[ile][!] file {pattern}
-		Profile script file that matches the pattern {pattern}.
-		See |:debug-name| for how {pattern} is used.
-		This only profiles the script itself, not the functions
-		defined in it.
-		When the [!] is added then all functions defined in the script
-		will also be profiled.
-		Note that profiling only starts when the script is loaded
-		after this command.  A :profile command in the script itself
-		won't work.
-
-:prof[ile] dump
-		Write the current state of profiling to the logfile
-		immediately.  After running this command, Vim continues to
-		collect the profiling statistics.
-
-:profd[el] ...						*:profd* *:profdel*
-		Stop profiling for the arguments specified.  See |:breakdel|
-		for the arguments.  Examples: >
-			profdel func MyFunc
-			profdel file MyScript.vim
-			profdel here
-
-You must always start with a ":profile start fname" command.  The resulting
-file is written when Vim exits.  For example, to profile one specific
-function: >
-	profile start /tmp/vimprofile
-	profile func MyFunc
-
-Here is an example of the output, with line
-numbers prepended for the explanation:
-
-  1 FUNCTION  Test2() ~
-  2 Called 1 time ~
-  3 Total time:   0.155251 ~
-  4  Self time:   0.002006 ~
-  5  ~
-  6 count  total (s)   self (s) ~
-  7	9	       0.000096   for i in range(8) ~
-  8	8   0.153655   0.000410     call Test3() ~
-  9	8	       0.000070   endfor ~
- 10				  " Ask a question ~
- 11	1	       0.001341   echo input("give me an answer: ") ~
-
-The header (lines 1-4) gives the time for the whole function.  The "Total"
-time is the time passed while the function was executing.  The "Self" time is
-the "Total" time reduced by time spent in:
-- other user defined functions
-- sourced scripts
-- executed autocommands
-- external (shell) commands
-
-Lines 7-11 show the time spent in each executed line.  Lines that are not
-executed do not count.  Thus a comment line is never counted.
-
-The Count column shows how many times a line was executed.  Note that the
-"for" command in line 7 is executed one more time as the following lines.
-That is because the line is also executed to detect the end of the loop.
-
-The time Vim spends waiting for user input isn't counted at all.  Thus how
-long you take to respond to the input() prompt is irrelevant.
-
-Profiling should give a good indication of where time is spent, but keep in
-mind there are various things that may clobber the results:
-
-- Real elapsed time is measured, if other processes are busy they may cause
-  delays at unpredictable moments.  You may want to run the profiling several
-  times and use the lowest results.
-
-- If you have several commands in one line you only get one time.  Split the
-  line to see the time for the individual commands.
-
-- The time of the lines added up is mostly less than the time of the whole
-  function.  There is some overhead in between.
-
-- Functions that are deleted before Vim exits will not produce profiling
-  information.  You can check the |v:profiling| variable if needed: >
-	:if !v:profiling
-	:   delfunc MyFunc
-	:endif
-<
-- Profiling may give weird results on multi-processor systems, when sleep
-  mode kicks in or the processor frequency is reduced to save power.
-
-- The "self" time is wrong when a function is used recursively.
-
-==============================================================================
-Context							*Context* *context*
-
-The editor state is represented by the Context concept. This includes things
-like the current |jumplist|, values of |registers|, and more, described below.
-
-							*context-types*
-The following Context items are supported:
-	"jumps"		|jumplist|
-	"regs"		|registers|
-	"bufs"		|buffer-list|
-	"gvars"		|global-variable|s
-	"sfuncs"	|script-local| functions
-	"funcs"		global and |script-local| functions
-
-							*context-dict*
-Context objects are dictionaries with the following key-value pairs:
-- "jumps", "regs", "bufs", "gvars":
-      |readfile()|-style |List| representation of corresponding msgpack
-      objects (see |msgpackdump()| and |msgpackparse()|).
-- "funcs" (includes |script-local| functions as well):
-      |List| of |:function| definitions.
-
 
  vim:tw=78:ts=8:noet:ft=help:norl:
diff --git a/runtime/doc/vimeval.txt b/runtime/doc/vimeval.txt
index 91cffe7e0b..28c675fc54 100644
--- a/runtime/doc/vimeval.txt
+++ b/runtime/doc/vimeval.txt
@@ -4,7 +4,7 @@
 		  VIM REFERENCE MANUAL	  by Bram Moolenaar
 
 
-Expression evaluation	*vimscript* *expression* *expr* *E15* *eval* *eval.txt*
+Expression evaluation			*expression* *expr* *E15* *eval* *eval.txt*
 
 Using expressions is introduced in chapter 41 of the user manual |usr_41.txt|.
 
diff --git a/runtime/doc/vimscript.txt b/runtime/doc/vimscript.txt
new file mode 100644
index 0000000000..8b55f19cdc
--- /dev/null
+++ b/runtime/doc/vimscript.txt
@@ -0,0 +1,723 @@
+*vimscript.txt*    Nvim
+
+
+                            NVIM REFERENCE MANUAL
+
+
+Vimscript and debugging						*vimscript*
+
+This reference describes commands for running and debugging Vimscript.
+For details on authoring Vimscript, see: |expression| |vimscript-functions|
+
+                                      Type |gO| to see the table of contents.
+
+==============================================================================
+Using Vimscript						*using-scripts*
+
+For writing a Vim script, see chapter 41 of the user manual |usr_41.txt|.
+
+					*:so* *:source*
+:so[urce] {file}	Runs |Ex-command|s or Lua code (".lua" files) from
+			{file}. Triggers the |SourcePre| autocommand.
+
+:[range]so[urce]	Read Ex commands or Lua code from the [range] of lines
+			in the current buffer.  When [range] is omitted read
+			all lines.  The buffer is treated as Lua code if its
+			'filetype' is "lua" or its filename ends with ".lua".
+
+			When sourcing commands or Lua code from the current
+			buffer, the same script-ID |<SID>| is used even if the
+			buffer is sourced multiple times.  If a buffer is
+			sourced more than once, then the functions in the
+			buffer are defined again.
+
+			Implementation detail: When sourcing a [range] of
+			lines that falls inside a folded region, the range
+			will be adjusted to the start and end of the fold,
+			but only if a two line specifiers range was used.
+
+							*:source!*
+:so[urce]! {file}	Runs |Normal-mode| commands from {file}. When used
+			after |:global|, |:argdo|, |:windo|, |:bufdo|, in
+			a loop or when another command follows the display
+			won't be updated while executing the commands.
+
+							*:ru* *:runtime*
+:ru[ntime][!] [where] {file} ..
+			Sources |Ex| commands or Lua code (".lua" files) read
+			from {file} (a relative path) in each directory given
+			by 'runtimepath' and/or 'packpath'.
+			Ignores non-existing files.
+
+			Example: >
+				:runtime syntax/c.vim
+				:runtime syntax/c.lua
+
+<			There can be multiple space-separated {file}
+			arguments. Each {file} is searched for in the first
+			directory from 'runtimepath', then in the second
+			directory, etc.
+
+			When [!] is included, all found files are sourced.
+			Else only the first found file is sourced.
+
+			When [where] is omitted only 'runtimepath' is used.
+			Other values:
+				START	search only under "start" in 'packpath'
+				OPT	search only under "opt" in 'packpath'
+				PACK	search under "start" and "opt" in
+					'packpath'
+				ALL	first use 'runtimepath', then search
+					under "start" and "opt" in 'packpath'
+
+			When {file} contains wildcards it is expanded to all
+			matching files.  Example: >
+				:runtime! plugin/**/*.{vim,lua}
+<			This is what Nvim uses to load the plugin files when
+			starting up.  This similar command: >
+				:runtime plugin/**/*.{vim,lua}
+<			would source the first file only.
+
+			For each {file} pattern, if two `.vim` and `.lua` file
+			names match and differ only in extension, the `.vim`
+			file is sourced first.
+
+			When 'verbose' is one or higher, there is a message
+			when no file could be found.
+			When 'verbose' is two or higher, there is a message
+			about each searched file.
+
+							*:pa* *:packadd* *E919*
+:pa[ckadd][!] {name}	|pack-add| Search for an optional plugin directory in
+			'packpath', source any plugin files found, and add it
+			to 'runtimepath'.  The directory must match: >
+				pack/*/opt/{name}
+<			If the directory pack/*/opt/{name}/after exists it is
+			added at the end of 'runtimepath'.
+
+			Note: Use |vim.pack.add()| to install from a URL.
+
+			If loading packages from "pack/*/start" was skipped,
+			then this directory is searched first: >
+				pack/*/start/{name}
+<
+			Note that {name} is the directory name, not the name
+			of the .vim file.  All files matching the patterns >
+				pack/*/opt/{name}/plugin/**/*.vim
+				pack/*/opt/{name}/plugin/**/*.lua
+<			will be sourced.  This allows for using subdirectories
+			below "plugin", just like with plugins in
+			'runtimepath'.
+
+			If the filetype detection was already enabled (this
+			is usually done with a `syntax enable` or `filetype on`
+			command in your |vimrc|, or automatically during
+			|initialization|), and the package was found in
+			"pack/*/opt/{name}", this command will also look
+			for "{name}/ftdetect/*.vim" files.
+
+			When the optional "!" is given, no plugin/ files or
+			ftdetect/ scripts are loaded, only the matching
+			directories are added to 'runtimepath'.  This is
+			useful in your |init.vim|.  The plugins will then be
+			loaded during the |load-plugins| |initialization| step
+			(note that the loading order will be reversed because
+			each directory is inserted before others), after
+			loading the ftdetect scripts.
+
+			To programmatically decide if `!` is needed during
+			startup, check |v:vim_did_init|: use `!` if 0 (to not
+			duplicate |load-plugins| step), no `!` otherwise (to
+			force load plugin files as otherwise they won't be
+			loaded automatically).
+
+						*:packl* *:packloadall*
+:packl[oadall][!]	Load all packages in the "start" directory under each
+			entry in 'packpath'.
+
+			First all the directories found are added to
+			'runtimepath', then the plugins found in the
+			directories are sourced.  This allows for a plugin to
+			depend on something of another plugin, e.g. an
+			"autoload" directory.  See |packload-two-steps| for
+			how this can be useful.
+
+			This is normally done automatically during startup,
+			after loading your |vimrc| file.  With this command it
+			can be done earlier.
+
+			Packages will be loaded only once.  Using
+			`:packloadall` a second time will have no effect.
+			When the optional ! is added this command will load
+			packages even when done before.
+
+			Note that when using `:packloadall` in the |vimrc|
+			file, the 'runtimepath' option is updated, and later
+			all plugins in 'runtimepath' will be loaded, which
+			means they are loaded again.  Plugins are expected to
+			handle that.
+
+			An error only causes sourcing the script where it
+			happens to be aborted, further plugins will be loaded.
+			See |packages|.
+
+:scripte[ncoding] [encoding]		*:scripte* *:scriptencoding* *E167*
+			Specify the character encoding used in the script.
+			The following lines will be converted from [encoding]
+			to the value of the 'encoding' option, if they are
+			different.  Examples: >
+				scriptencoding iso-8859-5
+				scriptencoding cp932
+<
+			When [encoding] is empty, no conversion is done.  This
+			can be used to restrict conversion to a sequence of
+			lines: >
+				scriptencoding euc-jp
+				... lines to be converted ...
+				scriptencoding
+				... not converted ...
+
+<			When conversion isn't supported by the system, there
+			is no error message and no conversion is done.  When a
+			line can't be converted there is no error and the
+			original line is kept.
+
+			Don't use "ucs-2" or "ucs-4", scripts cannot be in
+			these encodings (they would contain NUL bytes).
+			When a sourced script starts with a BOM (Byte Order
+			Mark) in utf-8 format Vim will recognize it, no need
+			to use ":scriptencoding utf-8" then.
+
+						*:scr* *:scriptnames*
+:scr[iptnames]		List all sourced script names, in the order they were
+			first sourced.  The number is used for the script ID
+			|<SID>|.
+			Also see `getscriptinfo()`.
+
+:scr[iptnames][!] {scriptId}			*:script*
+			Edit script {scriptId}.  Although ":scriptnames name"
+			works, using ":script name" is recommended.
+			When the current buffer can't be |abandon|ed and the !
+			is not present, the command fails.
+
+						*:fini* *:finish* *E168*
+:fini[sh]		Stop sourcing a script.  Can only be used in a Vim
+			script file.  This is a quick way to skip the rest of
+			the file.  If it is used after a |:try| but before the
+			matching |:finally| (if present), the commands
+			following the ":finally" up to the matching |:endtry|
+			are executed first.  This process applies to all
+			nested ":try"s in the script.  The outermost ":endtry"
+			then stops sourcing the script.
+
+All commands and command sequences can be repeated by putting them in a named
+register and then executing it.  There are two ways to get the commands in the
+register:
+- Use the record command "q".  You type the commands once, and while they are
+  being executed they are stored in a register.  Easy, because you can see
+  what you are doing.  If you make a mistake, "p"ut the register into the
+  file, edit the command sequence, and then delete it into the register
+  again.  You can continue recording by appending to the register (use an
+  uppercase letter).
+- Delete or yank the command sequence into the register.
+
+Often used command sequences can be put under a function key with the ':map'
+command.
+
+An alternative is to put the commands in a file, and execute them with the
+':source!' command.  Useful for long command sequences.  Can be combined with
+the ':map' command to put complicated commands under a function key.
+
+The ':source' command reads Ex commands from a file or a buffer line by line.
+You will have to type any needed keyboard input.  The ':source!' command reads
+from a script file character by character, interpreting each character as if
+you typed it.
+
+Example: When you give the ":!ls" command you get the |hit-enter| prompt.  If
+you ':source' a file with the line "!ls" in it, you will have to type the
+<Enter> yourself.  But if you ':source!' a file with the line ":!ls" in it,
+the next characters from that file are read until a <CR> is found.  You will
+not have to type <CR> yourself, unless ":!ls" was the last line in the file.
+
+It is possible to put ':source[!]' commands in the script file, so you can
+make a top-down hierarchy of script files.  The ':source' command can be
+nested as deep as the number of files that can be opened at one time (about
+15).  The ':source!' command can be nested up to 15 levels deep.
+
+You can use the "<script>" string (literally, this is not a special key) inside
+of the sourced file, in places where a file name is expected.  It will be
+replaced by the file name of the sourced file.  For example, if you have a
+"other.vimrc" file in the same directory as your |init.vim| file, you can
+source it from your |init.vim| file with this command: >
+	:source <script>:h/other.vimrc
+
+In script files terminal-dependent key codes are represented by
+terminal-independent two character codes.  This means that they can be used
+in the same way on different kinds of terminals.  The first character of a
+key code is 0x80 or 128, shown on the screen as "~@".  The second one can be
+found in the list |key-notation|.  Any of these codes can also be entered
+with CTRL-V followed by the three digit decimal code.
+
+							*:source_crnl* *W15*
+Windows: Files that are read with ":source" normally have <CR><NL> <EOL>s.
+These always work.  If you are using a file with <NL> <EOL>s (for example, a
+file made on Unix), this will be recognized if 'fileformats' is not empty and
+the first line does not end in a <CR>.  This fails if the first line has
+something like ":map <F1> :help^M", where "^M" is a <CR>.  If the first line
+ends in a <CR>, but following ones don't, you will get an error message,
+because the <CR> from the first lines will be lost.
+
+On other systems, Vim expects ":source"ed files to end in a <NL>.  These
+always work.  If you are using a file with <CR><NL> <EOL>s (for example, a
+file made on MS-Windows), all lines will have a trailing <CR>.  This may cause
+problems for some commands (e.g., mappings).  There is no automatic <EOL>
+detection, because it's common to start with a line that defines a mapping
+that ends in a <CR>, which will confuse the automaton.
+
+							*line-continuation*
+Long lines in a ":source"d Ex command script file can be split by inserting
+a line continuation symbol "\" (backslash) at the start of the next line.
+There can be white space before the backslash, which is ignored.
+
+Example: the lines >
+	:set comments=sr:/*,mb:*,el:*/,
+		     \://,
+		     \b:#,
+		     \:%,
+		     \n:>,
+		     \fb:-
+are interpreted as if they were given in one line: >
+	:set comments=sr:/*,mb:*,el:*/,://,b:#,:%,n:>,fb:-
+
+All leading whitespace characters in the line before a backslash are ignored.
+Note however that trailing whitespace in the line before it cannot be
+inserted freely; it depends on the position where a command is split up
+whether additional whitespace is allowed or not.
+
+When a space is required it's best to put it right after the backslash.  A
+space at the end of a line is hard to see and may be accidentally deleted. >
+	:syn match Comment
+		\ "very long regexp"
+		\ keepend
+
+There is a problem with the ":append" and ":insert" commands: >
+   :1append
+   \asdf
+   .
+The backslash is seen as a line-continuation symbol, thus this results in the
+command: >
+   :1appendasdf
+   .
+To avoid this, add the 'C' flag to the 'cpoptions' option: >
+   :set cpo+=C
+   :1append
+   \asdf
+   .
+   :set cpo-=C
+
+Note that when the commands are inside a function, you need to add the 'C'
+flag when defining the function, it is not relevant when executing it. >
+   :set cpo+=C
+   :function Foo()
+   :1append
+   \asdf
+   .
+   :endfunction
+   :set cpo-=C
+<
+					*line-continuation-comment*
+To add a comment in between the lines start with `'"\ '`.  Notice the space
+after the backslash.  Example: >
+	let array = [
+		"\ first entry comment
+		\ 'first',
+		"\ second entry comment
+		\ 'second',
+		\ ]
+
+Rationale:
+	Most programs work with a trailing backslash to indicate line
+	continuation.  Using this in Vim would cause incompatibility with Vi.
+	For example for this Vi mapping: >
+		:map xx  asdf\
+<	Therefore the unusual leading backslash is used.
+
+	Starting a comment in a continuation line results in all following
+	continuation lines to be part of the comment.  Since it was like this
+	for a long time, when making it possible to add a comment halfway a
+	sequence of continuation lines, it was not possible to use \", since
+	that was a valid continuation line.  Using `'"\ '` comes closest, even
+	though it may look a bit weird.  Requiring the space after the
+	backslash is to make it very unlikely this is a normal comment line.
+
+==============================================================================
+Debugging scripts					*debug-scripts*
+
+Besides the obvious messages that you can add to your scripts to find out what
+they are doing, Vim offers a debug mode.  This allows you to step through a
+sourced file or user function and set breakpoints.
+
+NOTE: The debugging mode is far from perfect.  Debugging will have side
+effects on how Vim works.  You cannot use it to debug everything.  For
+example, the display is messed up by the debugging messages.
+
+An alternative to debug mode is setting the 'verbose' option.  With a bigger
+number it will give more verbose messages about what Vim is doing.
+
+
+STARTING DEBUG MODE						*debug-mode*
+
+To enter debugging mode use one of these methods:
+1. Start Vim with the |-D| argument: >
+	vim -D file.txt
+<  Debugging will start as soon as the first vimrc file is sourced.  This is
+   useful to find out what is happening when Vim is starting up.  A side
+   effect is that Vim will switch the terminal mode before initialisations
+   have finished, with unpredictable results.
+   For a GUI-only version (Windows) the debugging will start as
+   soon as the GUI window has been opened.  To make this happen early, add a
+   ":gui" command in the vimrc file.
+								*:debug*
+2. Run a command with ":debug" prepended.  Debugging will only be done while
+   this command executes.  Useful for debugging a specific script or user
+   function.  And for scripts and functions used by autocommands.  Example: >
+	:debug edit test.txt.gz
+
+3. Set a breakpoint in a sourced file or user function.  You could do this in
+   the command line: >
+	vim -c "breakadd file */explorer.vim" .
+<  This will run Vim and stop in the first line of the "explorer.vim" script.
+   Breakpoints can also be set while in debugging mode.
+
+In debugging mode every executed command is displayed before it is executed.
+Comment lines, empty lines and lines that are not executed are skipped.  When
+a line contains two commands, separated by "|", each command will be displayed
+separately.
+
+
+DEBUG MODE
+
+Once in debugging mode, the usual Ex commands can be used.  For example, to
+inspect the value of a variable: >
+	echo idx
+When inside a user function, this will print the value of the local variable
+"idx".  Prepend "g:" to get the value of a global variable: >
+	echo g:idx
+All commands are executed in the context of the current function or script.
+You can also set options, for example setting or resetting 'verbose' will show
+what happens, but you might want to set it just before executing the lines you
+are interested in: >
+	:set verbose=20
+
+Commands that require updating the screen should be avoided, because their
+effect won't be noticed until after leaving debug mode.  For example: >
+	:help
+won't be very helpful.
+
+There is a separate command-line history for debug mode.
+
+The line number for a function line is relative to the start of the function.
+If you have trouble figuring out where you are, edit the file that defines
+the function in another Vim, search for the start of the function and do
+"99j".  Replace "99" with the line number.
+
+Additionally, these commands can be used:
+							*>cont*
+	cont		Continue execution until the next breakpoint is hit.
+							*>quit*
+	quit		Abort execution.  This is like using CTRL-C, some
+			things might still be executed, doesn't abort
+			everything.  Still stops at the next breakpoint.
+							*>next*
+	next		Execute the command and come back to debug mode when
+			it's finished.  This steps over user function calls
+			and sourced files.
+							*>step*
+	step		Execute the command and come back to debug mode for
+			the next command.  This steps into called user
+			functions and sourced files.
+							*>interrupt*
+	interrupt	This is like using CTRL-C, but unlike ">quit" comes
+			back to debug mode for the next command that is
+			executed.  Useful for testing |:finally| and |:catch|
+			on interrupt exceptions.
+							*>finish*
+	finish		Finish the current script or user function and come
+			back to debug mode for the command after the one that
+			sourced or called it.
+							*>bt*
+							*>backtrace*
+							*>where*
+	backtrace	Show the call stacktrace for current debugging
+			session.
+	bt
+	where
+							*>frame*
+	frame N		Goes to N backtrace level. + and - signs make movement
+			relative.  E.g., ":frame +3" goes three frames up.
+							*>up*
+	up		Goes one level up from call stacktrace.
+							*>down*
+	down		Goes one level down from call stacktrace.
+
+About the additional commands in debug mode:
+- There is no command-line completion for them, you get the completion for the
+  normal Ex commands only.
+- You can shorten them, up to a single character, unless more than one command
+  starts with the same letter.  "f" stands for "finish", use "fr" for "frame".
+- Hitting <CR> will repeat the previous one.  When doing another command, this
+  is reset (because it's not clear what you want to repeat).
+- When you want to use the Ex command with the same name, prepend a colon:
+  ":cont", ":next", ":finish" (or shorter).
+
+The backtrace shows the hierarchy of function calls, e.g.:
+	>bt ~
+	  3 function One[3] ~
+	  2 Two[3] ~
+	->1 Three[3] ~
+	  0 Four ~
+	line 1: let four = 4 ~
+
+The "->" points to the current frame.  Use "up", "down" and "frame N" to
+select another frame.
+
+In the current frame you can evaluate the local function variables.  There is
+no way to see the command at the current line yet.
+
+
+DEFINING BREAKPOINTS
+							*:breaka* *:breakadd*
+:breaka[dd] func [lnum] {name}
+		Set a breakpoint in a function.  Example: >
+			:breakadd func Explore
+<		Doesn't check for a valid function name, thus the breakpoint
+		can be set before the function is defined.
+
+:breaka[dd] file [lnum] {name}
+		Set a breakpoint in a sourced file.  Example: >
+			:breakadd file 43 init.vim
+
+:breaka[dd] here
+		Set a breakpoint in the current line of the current file.
+		Like doing: >
+			:breakadd file <cursor-line> <current-file>
+<		Note that this only works for commands that are executed when
+		sourcing the file, not for a function defined in that file.
+
+:breaka[dd] expr {expression}
+		Sets a breakpoint, that will break whenever the {expression}
+		evaluates to a different value.  Example: >
+			:breakadd expr g:lnum
+<		Will break, whenever the global variable lnum changes.
+
+		Errors in evaluation are suppressed, you can use the name of a
+		variable that does not exist yet.  This also means you will
+		not notice anything if the expression has a mistake.
+
+		Note if you watch a |script-variable| this will break
+		when switching scripts, since the script variable is only
+		valid in the script where it has been defined and if that
+		script is called from several other scripts, this will stop
+		whenever that particular variable will become visible or
+		inaccessible again.
+
+The [lnum] is the line number of the breakpoint.  Vim will stop at or after
+this line.  When omitted line 1 is used.
+
+							*:debug-name*
+{name} is a pattern that is matched with the file or function name.  The
+pattern is like what is used for autocommands.  There must be a full match (as
+if the pattern starts with "^" and ends in "$").  A "*" matches any sequence
+of characters.  'ignorecase' is not used, but "\c" can be used in the pattern
+to ignore case |/\c|.  Don't include the () for the function name!
+
+The match for sourced scripts is done against the full file name.  If no path
+is specified the current directory is used.  Examples: >
+	breakadd file explorer.vim
+matches "explorer.vim" in the current directory. >
+	breakadd file *explorer.vim
+matches ".../plugin/explorer.vim", ".../plugin/iexplorer.vim", etc. >
+	breakadd file */explorer.vim
+matches ".../plugin/explorer.vim" and "explorer.vim" in any other directory.
+
+The match for functions is done against the name as it's shown in the output
+of ":function".  For local functions this means that something like "<SNR>99_"
+is prepended.
+
+Note that functions are first loaded and later executed.  When they are loaded
+the "file" breakpoints are checked, when they are executed the "func"
+breakpoints.
+
+
+DELETING BREAKPOINTS
+						*:breakd* *:breakdel* *E161*
+:breakd[el] {nr}
+		Delete breakpoint {nr}.  Use |:breaklist| to see the number of
+		each breakpoint.
+
+:breakd[el] *
+		Delete all breakpoints.
+
+:breakd[el] func [lnum] {name}
+		Delete a breakpoint in a function.
+
+:breakd[el] file [lnum] {name}
+		Delete a breakpoint in a sourced file.
+
+:breakd[el] here
+		Delete a breakpoint at the current line of the current file.
+
+When [lnum] is omitted, the first breakpoint in the function or file is
+deleted.
+The {name} must be exactly the same as what was typed for the ":breakadd"
+command.  "explorer", "*explorer.vim" and "*explorer*" are different.
+
+
+LISTING BREAKPOINTS
+							*:breakl* *:breaklist*
+:breakl[ist]
+		List all breakpoints.
+
+
+OBSCURE
+
+						*:debugg* *:debuggreedy*
+:debugg[reedy]
+		Read debug mode commands from the normal input stream, instead
+		of getting them directly from the user.  Only useful for test
+		scripts.  Example: >
+		  echo 'q^Mq' | vim -e -s -c debuggreedy -c 'breakadd file script.vim' -S script.vim
+
+:0debugg[reedy]
+		Undo ":debuggreedy": get debug mode commands directly from the
+		user, don't use typeahead for debug commands.
+
+==============================================================================
+Profiling						*profile* *profiling*
+
+Profiling means that Vim measures the time that is spent on executing
+functions and/or scripts.
+
+You can also use the |reltime()| function to measure time.
+
+For profiling syntax highlighting see |:syntime|.
+
+For example, to profile the one_script.vim script file: >
+	:profile start /tmp/one_script_profile
+	:profile file one_script.vim
+	:source one_script.vim
+	:exit
+
+
+:prof[ile] start {fname}			*:prof* *:profile* *E750*
+		Start profiling, write the output in {fname} upon exit or when
+		a `:profile stop` or `:profile dump` command is invoked.
+		"~/" and environment variables in {fname} will be expanded.
+		If {fname} already exists it will be silently overwritten.
+		The variable |v:profiling| is set to one.
+
+:prof[ile] stop
+		Write the collected profiling information to the logfile and
+		stop profiling.  You can use the `:profile start` command to
+		clear the profiling statistics and start profiling again.
+
+:prof[ile] pause
+		Stop profiling until the next `:profile continue` command.
+		Can be used when doing something that should not be counted
+		(e.g., an external command).  Does not nest.
+
+:prof[ile] continue
+		Continue profiling after `:profile pause`.
+
+:prof[ile] func {pattern}
+		Profile function that matches the pattern {pattern}.
+		See |:debug-name| for how {pattern} is used.
+
+:prof[ile][!] file {pattern}
+		Profile script file that matches the pattern {pattern}.
+		See |:debug-name| for how {pattern} is used.
+		This only profiles the script itself, not the functions
+		defined in it.
+		When the [!] is added then all functions defined in the script
+		will also be profiled.
+		Note that profiling only starts when the script is loaded
+		after this command.  A :profile command in the script itself
+		won't work.
+
+:prof[ile] dump
+		Write the current state of profiling to the logfile
+		immediately.  After running this command, Vim continues to
+		collect the profiling statistics.
+
+:profd[el] ...						*:profd* *:profdel*
+		Stop profiling for the arguments specified.  See |:breakdel|
+		for the arguments.  Examples: >
+			profdel func MyFunc
+			profdel file MyScript.vim
+			profdel here
+
+You must always start with a ":profile start fname" command.  The resulting
+file is written when Vim exits.  For example, to profile one specific
+function: >
+	profile start /tmp/vimprofile
+	profile func MyFunc
+
+Here is an example of the output, with line
+numbers prepended for the explanation:
+
+  1 FUNCTION  Test2() ~
+  2 Called 1 time ~
+  3 Total time:   0.155251 ~
+  4  Self time:   0.002006 ~
+  5  ~
+  6 count  total (s)   self (s) ~
+  7	9	       0.000096   for i in range(8) ~
+  8	8   0.153655   0.000410     call Test3() ~
+  9	8	       0.000070   endfor ~
+ 10				  " Ask a question ~
+ 11	1	       0.001341   echo input("give me an answer: ") ~
+
+The header (lines 1-4) gives the time for the whole function.  The "Total"
+time is the time passed while the function was executing.  The "Self" time is
+the "Total" time reduced by time spent in:
+- other user defined functions
+- sourced scripts
+- executed autocommands
+- external (shell) commands
+
+Lines 7-11 show the time spent in each executed line.  Lines that are not
+executed do not count.  Thus a comment line is never counted.
+
+The Count column shows how many times a line was executed.  Note that the
+"for" command in line 7 is executed one more time as the following lines.
+That is because the line is also executed to detect the end of the loop.
+
+The time Vim spends waiting for user input isn't counted at all.  Thus how
+long you take to respond to the input() prompt is irrelevant.
+
+Profiling should give a good indication of where time is spent, but keep in
+mind there are various things that may clobber the results:
+
+- Real elapsed time is measured, if other processes are busy they may cause
+  delays at unpredictable moments.  You may want to run the profiling several
+  times and use the lowest results.
+
+- If you have several commands in one line you only get one time.  Split the
+  line to see the time for the individual commands.
+
+- The time of the lines added up is mostly less than the time of the whole
+  function.  There is some overhead in between.
+
+- Functions that are deleted before Vim exits will not produce profiling
+  information.  You can check the |v:profiling| variable if needed: >
+	:if !v:profiling
+	:   delfunc MyFunc
+	:endif
+<
+- Profiling may give weird results on multi-processor systems, when sleep
+  mode kicks in or the processor frequency is reduced to save power.
+
+- The "self" time is wrong when a function is used recursively.
+
+
+ vim:tw=78:ts=8:noet:ft=help:norl:
diff --git a/runtime/lua/vim/_meta/api.gen.lua b/runtime/lua/vim/_meta/api.gen.lua
index be346e9373..99485c9a92 100644
--- a/runtime/lua/vim/_meta/api.gen.lua
+++ b/runtime/lua/vim/_meta/api.gen.lua
@@ -1349,12 +1349,18 @@ function vim.api.nvim_get_color_map() end
 --- @return table<string,vim.api.keyset.command_info> # Map of maps describing commands.
 function vim.api.nvim_get_commands(opts) end
 
---- Gets a map of the current editor state.
+--- Gets a map (msgpack encoding) of the current editor state:
+---
+--- - "bufs"    [buffer-list]
+--- - "funcs"   Vimscript global and [script-local] functions
+--- - "gvars"   [global-variable]s
+--- - "jumps"   [jumplist]
+--- - "regs"    [registers]
+--- - "sfuncs"  Vimscript [script-local] functions
 ---
 --- @param opts vim.api.keyset.context? Optional parameters.
---- - types:  List of `context-types` ("regs", "jumps", "bufs",
----   "gvars", …) to gather, or empty for "all".
---- @return table<string,any> # map of global |context|.
+--- - types:  List of context types (see above) to gather, or empty for "all".
+--- @return table<string,any> # Editor state as a msgpack-encoded map.
 function vim.api.nvim_get_context(opts) end
 
 --- Gets the current buffer.
@@ -1658,9 +1664,9 @@ function vim.api.nvim_list_uis() end
 --- @return integer[] # List of |window-ID|s
 function vim.api.nvim_list_wins() end
 
---- Sets the current editor state from the given `context` map.
+--- Sets the current editor state from the given map.
 ---
---- @param dict table<string,any> `Context` map.
+--- @param dict table<string,any> Msgpack-encoded editor state, in the form returned by [nvim_get_context()].
 --- @return any
 function vim.api.nvim_load_context(dict) end
 
diff --git a/runtime/lua/vim/_meta/options.gen.lua b/runtime/lua/vim/_meta/options.gen.lua
index 65d243e4be..a3732f1ae7 100644
--- a/runtime/lua/vim/_meta/options.gen.lua
+++ b/runtime/lua/vim/_meta/options.gen.lua
@@ -99,13 +99,18 @@ vim.o.arshape = vim.o.arabicshape
 vim.go.arabicshape = vim.o.arabicshape
 vim.go.arshape = vim.go.arabicshape
 
---- When on, Vim will change the current working directory whenever you
---- open a file, switch buffers, delete a buffer or open/close a window.
---- It will change to the directory containing the file which was opened
---- or selected.  When a buffer has no name it also has no directory, thus
---- the current directory won't change when navigating to it.
+--- When on, Nvim will change its global `current-directory` to the parent
+--- of the current file, whenever you open a file, switch buffers, delete
+--- a buffer or open/close a window.
+---
+--- When a buffer has no name it also has no directory, thus the current
+--- directory won't change when navigating to it.
+---
 --- Note: When this option is on some plugins may not work.
 ---
+--- Alternatively, consider using `:bcd`, `:lcd`, or `:tcd` in an autocmd,
+--- to selectively set a local (not global) directory. See `project-dir`.
+---
 --- @type boolean
 vim.o.autochdir = false
 vim.o.acd = vim.o.autochdir
diff --git a/src/nvim/api/vim.c b/src/nvim/api/vim.c
index fd3f5eb21a..e66f10dc21 100644
--- a/src/nvim/api/vim.c
+++ b/src/nvim/api/vim.c
@@ -1494,14 +1494,20 @@ DictOf(Integer) nvim_get_color_map(Arena *arena)
   return colors;
 }
 
-/// Gets a map of the current editor state.
+/// Gets a map (msgpack encoding) of the current editor state:
+///
+/// - "bufs"    [buffer-list]
+/// - "funcs"   Vimscript global and [script-local] functions
+/// - "gvars"   [global-variable]s
+/// - "jumps"   [jumplist]
+/// - "regs"    [registers]
+/// - "sfuncs"  Vimscript [script-local] functions
 ///
 /// @param opts  Optional parameters.
-///               - types:  List of |context-types| ("regs", "jumps", "bufs",
-///                 "gvars", …) to gather, or empty for "all".
+///               - types:  List of context types (see above) to gather, or empty for "all".
 /// @param[out]  err  Error details, if any
 ///
-/// @return map of global |context|.
+/// @return Editor state as a msgpack-encoded map.
 Dict nvim_get_context(Dict(context) *opts, Arena *arena, Error *err)
   FUNC_API_SINCE(6)
 {
@@ -1543,9 +1549,9 @@ Dict nvim_get_context(Dict(context) *opts, Arena *arena, Error *err)
   return dict;
 }
 
-/// Sets the current editor state from the given |context| map.
+/// Sets the current editor state from the given map.
 ///
-/// @param  dict  |Context| map.
+/// @param dict  Msgpack-encoded editor state, in the form returned by [nvim_get_context()].
 Object nvim_load_context(Dict dict, Error *err)
   FUNC_API_SINCE(6)
 {
diff --git a/src/nvim/options.lua b/src/nvim/options.lua
index a070861233..da2a545a86 100644
--- a/src/nvim/options.lua
+++ b/src/nvim/options.lua
@@ -237,12 +237,17 @@ local options = {
       cb = 'did_set_autochdir',
       defaults = false,
       desc = [=[
-        When on, Vim will change the current working directory whenever you
-        open a file, switch buffers, delete a buffer or open/close a window.
-        It will change to the directory containing the file which was opened
-        or selected.  When a buffer has no name it also has no directory, thus
-        the current directory won't change when navigating to it.
+        When on, Nvim will change its global |current-directory| to the parent
+        of the current file, whenever you open a file, switch buffers, delete
+        a buffer or open/close a window.
+
+        When a buffer has no name it also has no directory, thus the current
+        directory won't change when navigating to it.
+
         Note: When this option is on some plugins may not work.
+
+        Alternatively, consider using |:bcd|, |:lcd|, or |:tcd| in an autocmd,
+        to selectively set a local (not global) directory. See |project-dir|.
       ]=],
       full_name = 'autochdir',
       scope = { 'global' },