*/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