summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMiodrag Tokić <miki@loonies.io>2015-05-19 18:07:34 +0200
committerMiodrag Tokić <miki@loonies.io>2015-05-19 18:07:34 +0200
commit7de7c1b2619852b5fc831280bfcd3a3cd03553cf (patch)
treeace29e8d55692545a4b463e281b39320b249f042 /doc
parentb9cf8d1867ba8d2e60d11d3c6144eadc2d11a162 (diff)
downloadvdebug-7de7c1b2619852b5fc831280bfcd3a3cd03553cf.zip
Remove trailing whitespace
Remove trailing whitespace in the help file.
Diffstat (limited to 'doc')
-rw-r--r--doc/Vdebug.txt164
1 files changed, 82 insertions, 82 deletions
diff --git a/doc/Vdebug.txt b/doc/Vdebug.txt
index 69b6928..53c4292 100644
--- a/doc/Vdebug.txt
+++ b/doc/Vdebug.txt
@@ -71,11 +71,11 @@ CONTENTS *Vdebug-contents*
==============================================================================
1. Introduction *VdebugIntro*
-So what does this plugin actually do?
+So what does this plugin actually do?
It provides an interface for debugging scripts, allowing you to halt execution,
view the variables at the current position and find out exactly what's going on
-in your program. It supports the DBGP protocol, which includes all types of
+in your program. It supports the DBGP protocol, which includes all types of
breakpoint, code snippet evaluation, and more.
------------------------------------------------------------------------------
@@ -151,15 +151,15 @@ The Github page for the plugin is https://github.com/joonty/vdebug, and the VIM
scripts URL is http://www.vim.org/scripts/script.php?script_id=4170.
By far the easiest way to install is by using a plugin manager, e.g. vundle
-(https://github.com/gmarik/vundle/) or pathogen
+(https://github.com/gmarik/vundle/) or pathogen
(https://github.com/tpope/vim-pathogen.git). If you have one of these, follow
the normal installation procedure.
If you aren't using a plugin manager, you have to do it the long way. Either
clone the Github repository or download the ZIP from VIM scripts.
-Move the contents of each folder in the plugin (e.g. syntax/, plugin/) into
-the corresponding folder in your VIM home directory - create the directories
+Move the contents of each folder in the plugin (e.g. syntax/, plugin/) into
+the corresponding folder in your VIM home directory - create the directories
if they don't exist. The VIM home directory is: >
$HOME/.vim
<
@@ -173,8 +173,8 @@ or: >
C:\Documents and Settings\[User name]\
<
-You may also use the system plugin directory for VIM on your system if you want
-to install for all users.
+You may also use the system plugin directory for VIM on your system if you want
+to install for all users.
==============================================================================
3. Setting up the debugging environment *VdebugSetUp*
@@ -200,8 +200,8 @@ command line (requires root/admin privileges): >
<
When this finishes, it will tell you about a library (.so on *nix, .dll on
Windows) that needs to be included. Copy down the file path, as we need to add
-it as a zend extension. This can be done in the PHP INI file, but in Ubuntu
-I can add a new file to /etc/php5/conf.d/ that contains all the configuration
+it as a zend extension. This can be done in the PHP INI file, but in Ubuntu
+I can add a new file to /etc/php5/conf.d/ that contains all the configuration
options and gets loaded automatically by PHP.
Add these options to the INI file: >
@@ -260,9 +260,9 @@ this, you're ready to go.
NOTE: You may have a problem when trying to do an "eval". If you get an error
mentioning something about not providing a length then you need to patch the
-client.py file in the Python remote debugger source code. I've created a patch
+client.py file in the Python remote debugger source code. I've created a patch
that you can get at https://gist.github.com/3348076. It will only apply cleanly
-if it's for the same version as the package you downloaded.
+if it's for the same version as the package you downloaded.
If using unix you can use the `patch` command to apply the changes, e.g: >
@@ -273,8 +273,8 @@ If you're still having trouble, drop me an email.
------------------------------------------------------------------------------
3.3 Ruby set up *VdebugSetUpRuby*
-Like Python, Ruby has an standalone debugging tool that you can use from the
-command line, but to use Vdebug in conjunction with your Ruby scripts you will
+Like Python, Ruby has an standalone debugging tool that you can use from the
+command line, but to use Vdebug in conjunction with your Ruby scripts you will
have to get the "rdbgp.rb" script that comes bundled with Komodo Edit/IDE by
Activestate.
@@ -312,25 +312,25 @@ If you're still having trouble, drop me an email.
------------------------------------------------------------------------------
3.4 Perl set up *VdebugSetUpPerl*
-Perl is one of the trickier languages to set up, unless you have very specific
+Perl is one of the trickier languages to set up, unless you have very specific
instructions on what to do. Fortunately, that's what I'm going to give you!
-Like Python and Ruby, Activestate provide a standalone module that you can use
+Like Python and Ruby, Activestate provide a standalone module that you can use
to remotely debug Perl applications. What makes this more difficult than Python
and Ruby is that the debugging script changes and, as far as I can see, breaks
after a particular version. That means you have to get the right version from
Activestate, and working that out on your own is a bit of a pain.
Fortunately, I'm going to make it easy for you and give you the exact version
-to download. Go to the archive at
-http://downloads.activestate.com/Komodo/releases/archive/4.x/4.4.1/remotedebugging
+to download. Go to the archive at
+http://downloads.activestate.com/Komodo/releases/archive/4.x/4.4.1/remotedebugging
and download the archive with "Perl" in the name that suits your operating system.
Just a reminder that, from here, the instructions are for Linux. Activestate
have instructions for other systems on their website.
-Unpack the archive somewhere on your system. There is a perl5db.pl script that
-you will need to include to enable debugging. To do this you need to set some
+Unpack the archive somewhere on your system. There is a perl5db.pl script that
+you will need to include to enable debugging. To do this you need to set some
environment variables to point to the directory containing this file: >
export PERL5LIB=/path/to/Komodo-PerlRemoteDebugging-xxx/
export PERL5DB="BEGIN { require q($PERL5LIB/perl5db.pl)}"
@@ -368,12 +368,12 @@ is the port.
------------------------------------------------------------------------------
3.6 TCL/Wish set up *VdebugSetUpTcl*
-Like Python and Ruby, Tcl and Wish have an standalone debugging tool that you
-can use from the command line, which has again been made available by
+Like Python and Ruby, Tcl and Wish have an standalone debugging tool that you
+can use from the command line, which has again been made available by
ActiveState.
-Go to http://code.activestate.com/komodo/remotedebugging/, download the Tcl
-client for your OS and extract it. Inside this package is a binary file called
+Go to http://code.activestate.com/komodo/remotedebugging/, download the Tcl
+client for your OS and extract it. Inside this package is a binary file called
dbgp_tcldebug that we will use instead of the tcl/wish binary. It accepts the
script as an option, along with the vdebug server address and port.
@@ -386,7 +386,7 @@ To debug a wish script called "mywishscript.tcl", run the following: >
path/to/dbgp_tcldebug -dbgp localhost:9000 -app-file mywishscript.tcl \
-app-shell /usr/bin/wish
<
-Note that the only difference is the app shell argument.
+Note that the only difference is the app shell argument.
There is a known error with using "tix", however, as it appears that Activestate's
debugger engine doesn't support it.
@@ -437,7 +437,7 @@ This shows the current position of the debugger. The file will automatically
change as the debugger pauses in different parts of the code, and the current
line is shown with a "->" sign in the margin.
-Don't edit the contents of the file when in debug mode, and especially don't
+Don't edit the contents of the file when in debug mode, and especially don't
edit without saving - this causes problems when swapping between files.
You can set line breakpoints here with the <F10> key or :Breakpoint, and can
@@ -455,13 +455,13 @@ can be customised (see |VdebugOptions|), and will fall back to ASCII equivalents
if multi byte support is not enabled in the VIM configuration.
To open a closed tree, navigate to a line with a closed tree (right arrow) and
-press <enter> (<cr>) or double-click if you have mouse-support enabled. This
+press <enter> (<cr>) or double-click if you have mouse-support enabled. This
will open the tree, and show all the children.
There are two style options for the watch window: expanded (default) and compact.
The expanded version has a new line between each variable, and uses separator
strings to indicate relationships. The compact version has a variable on each
-line, and works better for smaller screens. To set this option, see
+line, and works better for smaller screens. To set this option, see
|VdebugOptions-watch_window_style|.
The watch window automatically updates every time the debugger pauses, so
@@ -487,7 +487,7 @@ and functions/methods that the program has run through to get to the current
position. The top entry ([0]) is always the current position, and the entries
below show the path the script has taken.
-Like the watch window, the stack will update automatically every time the
+Like the watch window, the stack will update automatically every time the
debugger pauses. You can jump to a place in the stack by putting your cursor
over a line and pressing <enter> (<cr>) or by double clicking with your mouse
(if you have mouse support enabled).
@@ -553,13 +553,13 @@ debugging, and the default keys mapped to those commands.
Tells the debugger engine to step to the next statement, e.g. the next line
of the script. Useful for going through a problem section of the script
with a fine toothcomb.
-
+
4.3.3 Step in *VdebugCommandStepIn*
Default key: <F3>
Tells the debugger engine to step into a statement on the current line.
For instance, if there's a function call on the current line it will jump to
the start of that function.
-
+
4.3.4 Step out *VdebugCommandStepOut*
Default key: <F4>
Tells the debugger engine to step out of the current statement into the
@@ -571,7 +571,7 @@ debugging, and the default keys mapped to those commands.
currently sitting. One of the most useful commands, as it means that
setting a hard breakpoint is not always necessary. This only works if the
cursor is in the source window, otherwise it doesn't make sense! But it
- also doesn't need to be a point in the current file, just somewhere that
+ also doesn't need to be a point in the current file, just somewhere that
the execution is going to hit.
4.3.6 Detach *VdebugCommandDetach*
@@ -658,10 +658,10 @@ type breakpoint is covered in the previous section, |VdebugSetLineBreakpoint|.
at the first line of the function. Note that the syntax for <function-name>
varies between debugger engine and is NOT well documented. In fact, Xdebug
doesn't mention how to set a breakpoint on class/object methods, and I have
- had limited success in doing so. Global functions work without a problem,
+ had limited success in doing so. Global functions work without a problem,
e.g: >
-
- :Breakpoint call open_file
+
+ :Breakpoint call open_file
<
In PHP, it seems that you need to use static method syntax to break at
methods, even if the method isn't static. If I have a class called Foo and
@@ -675,17 +675,17 @@ type breakpoint is covered in the previous section, |VdebugSetLineBreakpoint|.
Sets a breakpoint to activate when a function returns. The debugger stops
at the return line of the function. Note that this suffers from the same
problem as <call>, and setting class/object methods may not be possible.
- Read the call documentation for more on that. However, global functions
+ Read the call documentation for more on that. However, global functions
work without a problem. E.g: >
-
- :Breakpoint return open_file
+
+ :Breakpoint return open_file
<
:Breakpoint watch <variable-or-address> *VdebugSetBreakpoints-watch*
Sets a breakpoint to activate when a variable or address is written. This
is not supported by Xdebug, so don't get your hopes up. Still, if it did
work then it might look like this: >
-
+
:Breakpoint watch $myvar
<
@@ -740,7 +740,7 @@ The result is shown on the watch window. E.g: >
4.5.2 Evaluating highlighted expressions *VdebugEvalHighlighted*
Use visual highlighting (default command "v") to select an expression that you
-want to evaluate and type "<Leader>e" (leader key followed by the letter "e").
+want to evaluate and type "<Leader>e" (leader key followed by the letter "e").
The result of the evaluation is shown on the watch window.
------------------------------------------------------------------------------
@@ -754,11 +754,11 @@ some debugger engines.
==============================================================================
5. Options *VdebugOptions*
-There are two ways of setting options for Vdebug. The options are stored in a
-Vim dictionary (the equivalent of an associative array in PHP or a hash in Ruby).
+There are two ways of setting options for Vdebug. The options are stored in a
+Vim dictionary (the equivalent of an associative array in PHP or a hash in Ruby).
This dictionary can be modified using the global variable "g:vdebug_options".
-However, as you may want to change options on the fly, a command (:VdebugOpt)
-has been added for your convenience so that you can easily get and set options
+However, as you may want to change options on the fly, a command (:VdebugOpt)
+has been added for your convenience so that you can easily get and set options
without having to use Vim dictionary syntax.
I've found that the best way of setting options is to use the dictionary in your
@@ -811,39 +811,39 @@ if you don't set them.
Here is a list of all the available options.
*VdebugOptions-port*
-g:vdebug_options["port"] (default = 9000)
+g:vdebug_options["port"] (default = 9000)
This sets the port that Vdebug will use to listen for connections. Xdebug
defaults to 9000, and it's the normal port for DBGP, so only change it if
you also change the port that the engine uses.
*VdebugOptions-server*
-g:vdebug_options["server"] (default = "localhost")
+g:vdebug_options["server"] (default = "localhost")
Sets the address that Vdebug will use to listen for connections. It
defaults to localhost, as it assumes that the debugger engine will be
running on the same machine and also connecting to localhost. If you want
to debug a script on a different machine, look at |VdebugRemote|.
*VdebugOptions-timeout*
-g:vdebug_options["timeout"] (default = 20)
+g:vdebug_options["timeout"] (default = 20)
Number of seconds to wait for when listening for a connection. VIM will
lock up due to the server socket listening for a client connection, so this
timeout is there to protect your VIM from locking up forever!
*VdebugOptions-on_close*
-g:vdebug_options["on_close"] (default = "detach")
+g:vdebug_options["on_close"] (default = "detach")
The default action when stopping the debugger. By default, it will detach
the debugger engine meaning that the script will execute until it finishes.
The other option is "stop", which means that the script will be killed
immediately.
*VdebugOptions-break_on_open*
-g:vdebug_options["break_on_open"] (default = 1)
+g:vdebug_options["break_on_open"] (default = 1)
This determines whether the debugger should stop on the first line of the
script, or just immediately start running until it hits a pre-defined
breakpoint.
*VdebugOptions-ide_key*
-g:vdebug_options["ide_key"] (default = empty)
+g:vdebug_options["ide_key"] (default = empty)
The IDE key that Vdebug will watch for with incoming connections. This
allows you to differentiate between connections, and only start a session
when this key matches the incoming key. This is empty by default, which
@@ -852,14 +852,14 @@ g:vdebug_options["ide_key"] (default = empty)
|VdebugIDEKey| for more information.
*VdebugOptions-path_maps*
-g:vdebug_options["path_maps"] (default = {})
+g:vdebug_options["path_maps"] (default = {})
This is only used for debugging a script on a remote machine. This is used
to map remote file paths to local file paths, as they are very likely to be
different. This is a VimL dictionary of mappings between remote files (keys)
and local files (values).
*VdebugOptions-debug_window_level*
-g:vdebug_options["debug_window_level"] (default = 0)
+g:vdebug_options["debug_window_level"] (default = 0)
Sets the amount of information sent to the log window, |VdebugLogWindow|.
The default value, 0, only shows errors. The other options are 1
(information) and 2 (debug). The latter option is not ideal to use, as it
@@ -868,43 +868,43 @@ g:vdebug_options["debug_window_level"] (default = 0)
debugging.
*VdebugOptions-debug_file_level*
-g:vdebug_options["debug_file_level"] (default = 0)
+g:vdebug_options["debug_file_level"] (default = 0)
Sets the amount of information written to the log file, which is set with
- the |VdebugOptions-debug_file| option. The default value, 0, only shows
+ the |VdebugOptions-debug_file| option. The default value, 0, only shows
errors. The other options are 1 (information) and 2 (debug).
*VdebugOptions-debug_file*
-g:vdebug_options["debug_file"] (default = empty)
+g:vdebug_options["debug_file"] (default = empty)
Sets the path to the log file, which writes information set by
|VdebugOptions-debug_file_level|. This is empty by default, meaning that
file logging is turned off. Enter a file path to enable file logging.
*VdebugOptions-watch_window_style*
-g:vdebug_options["watch_window_style"] (default = 'expanded')
+g:vdebug_options["watch_window_style"] (default = 'expanded')
Sets the style of the watch window, 'expanded' or 'compact'. The compact
version works better for smaller screens, but the expanded version looks
a bit nicer in my opinion.
*VdebugOptions-marker_default*
-g:vdebug_options["marker_default"] (default = '⬦')
+g:vdebug_options["marker_default"] (default = '⬦')
Sets the marker used for a variable in the watch window that has no
children. A "*" symbol is used if multi byte support is not enabled.
*VdebugOptions-marker_closed_tree*
-g:vdebug_options["marker_closed_tree"] (default = '▸')
+g:vdebug_options["marker_closed_tree"] (default = '▸')
Sets the marker used for a variable in the watch window that does have
- children, but the tree is currently closed. A "+" symbol is used if multi
+ children, but the tree is currently closed. A "+" symbol is used if multi
byte support is not enabled.
*VdebugOptions-marker_open_tree*
-g:vdebug_options["marker_open_tree"] (default = '▾')
+g:vdebug_options["marker_open_tree"] (default = '▾')
Sets the marker used for a variable in the watch window that does have
- children, and the tree is currently open. A "-" symbol is used if multi
+ children, and the tree is currently open. A "-" symbol is used if multi
byte support is not enabled.
*VdebugOptions-continuous_mode*
-g:vdebug_options["continuous_mode"] (default = 0)
- If enabled, Vdebug will start listening immediately after a debugging
+g:vdebug_options["continuous_mode"] (default = 0)
+ If enabled, Vdebug will start listening immediately after a debugging
session has finished, allowing for constant debugging across separate
requests. Press <F6> during a debugging session to stop this, or <Ctrl-C>
when Vdebug is listening.
@@ -920,7 +920,7 @@ others are mapped only when Vdebug starts up, and unmapped when it shuts down.
Not only this, but any commands that you have already mapped to these keys will
be remembered and restored when you come out of debugging mode.
-If you would still like to remap the default keys, this is possible using the
+If you would still like to remap the default keys, this is possible using the
key map dictionary, g:vdebug_keymap: >
let g:vdebug_keymap = {
@@ -948,19 +948,19 @@ Any options that you don't set will use the default value.
==============================================================================
7. Setting debugger features *VdebugFeatures*
-The DBGP protocol allows you to set features for debugging, such as the max
+The DBGP protocol allows you to set features for debugging, such as the max
length of data that the debugger returns. You can set these features in the Vim
-dictionary g:vdebug_features, and they will be sent to the debugger when you
+dictionary g:vdebug_features, and they will be sent to the debugger when you
start a new debugging session.
For example: >
let g:vdebug_features['max_depth'] = 2048
<
-This will send the command to the debugger to set the "max_depth" feature to
+This will send the command to the debugger to set the "max_depth" feature to
2048.
-For a list of features supported by DBGP see
+For a list of features supported by DBGP see
http://xdebug.org/docs-dbgp.php#feature-names.
==============================================================================
@@ -975,16 +975,16 @@ You can tell Vdebug to use an IDE key with the option
"g:vdebug_options['ide_key']" (see |VdebugOptions-ide_key|). This is empty by
default, so all connections will be picked up, even if an IDE key has been set
on the debugger engine side of things. It's useful to leave the IDE key option
-empty if you're having trouble getting a connection, as it's one less thing to
+empty if you're having trouble getting a connection, as it's one less thing to
have to worry about.
If you do set an IDE key and a connection comes in with a different IDE key, it
will be ignored (and there will be a message saying so).
-However, I find it best to leave out the IDE key all the time, as I use VIM for
+However, I find it best to leave out the IDE key all the time, as I use VIM for
all my debugging and don't have to juggle multiple connections at a time.
-Setting an IDE key varies between debugger implementations. For example, Xdebug
+Setting an IDE key varies between debugger implementations. For example, Xdebug
can be initiated from the browser with the GET variable
XDEBUG_SESSION_START=<ide-key>, where <ide-key> is the key for that session.
From the command line, the environment variable "XDEBUG_CONFIG" holds the IDE
@@ -999,7 +999,7 @@ use your machine's IP and debugger port, and you can pick up the remote
connection.
There are a couple of hurdles to overcome in doing this:
-
+
1. File paths are unlikely to be the same on the local and remote machines
2. You need to bind Vdebug to the right address, and make sure there's a
network route between the two machines.
@@ -1038,19 +1038,19 @@ the basic information:
machine or router
I'll give an example of my own here. I had two machines on an internal network,
-one was my desktop (192.168.1.1) and the other was a server (192.168.1.2) running
-the script that I wanted to debug on my desktop. I configured Xdebug on the
+one was my desktop (192.168.1.1) and the other was a server (192.168.1.2) running
+the script that I wanted to debug on my desktop. I configured Xdebug on the
server to use my desktop's IP address as the remote host. I then set the Vdebug
server address to be "192.168.1.1" (NOT "localhost") in the options: >
let g:vdebug_options['server'] = "192.168.1.1"
<
I also had to set an Xdebug option "remote_connect_back=on" in the INI file on
-the server. This combination of things allowed me to accept remote connections
+the server. This combination of things allowed me to accept remote connections
on my desktop.
The two machines don't have to be on an internal network, but if they aren't
-then I can all but guarantee that you will have to route port 9000 to your
+then I can all but guarantee that you will have to route port 9000 to your
machine using your router, as it will be blocked by default.
==============================================================================
@@ -1063,7 +1063,7 @@ it to this list.
Q. I can't get the debugger to run! Pressing <F5> does nothing.
A. The most common reason for this is that your VIM installation is not
- compiled with Python support. To check this, run "vim --version" and check
+ compiled with Python support. To check this, run "vim --version" and check
for any mention of Python. If it is compiled with Python support, try
remapping the start key to something else, e.g: >
:let g:vdebug_keymap['run'] = '<C-s>'
@@ -1107,13 +1107,13 @@ it to this list.
Q. I can't use the eval commands when debugging a Python script - I keep
getting an error about not providing length. How can I fix it?
- A. This is addressed in |VdebugSetUpPython|. A patch needs to be applied
+ A. This is addressed in |VdebugSetUpPython|. A patch needs to be applied
to the debugger engine code.
- Q. I am debugging a PHP script and VDebug won't stop at my breakpoint, but
+ Q. I am debugging a PHP script and VDebug won't stop at my breakpoint, but
it will stop at other breakpoints. What do I do?
- A. You should try reproducing this case outside of your (likely large)
- codebase. In the meantime, you can use the xdebug_break() function to
+ A. You should try reproducing this case outside of your (likely large)
+ codebase. In the meantime, you can use the xdebug_break() function to
hardcode a breakpoint in your file.
Q. I keep getting error <x> when doing <y>.
@@ -1134,12 +1134,12 @@ it to this list.
==============================================================================
11. Acknowledgements *VdebugAcknowledgements*
-This plugin was inspired by the original Xdebug plugin created by Seung Woo Shin
+This plugin was inspired by the original Xdebug plugin created by Seung Woo Shin
(<segv <at> sayclub.com>),
http://www.vim.org/scripts/script.php?script_id=1152. There are even a few
remnants of the original code, but not many. He showed us all that it was
possible.
Thanks to everyone who's contributed ideas and code so far, including Githubbers
-teranex, qstrahl, artnez, csomme and beatle. Also thanks to Gareth Oslar to
+teranex, qstrahl, artnez, csomme and beatle. Also thanks to Gareth Oslar to
pointing out that Vdebug (almost) worked with NodeJS.