Merge branch 'master' into dev

Author: joonty

README.md

@@ -16,9 +16,19 @@ It's written in Python, and has an object-oriented interface that is easy to ext
 and can even be used from the command-line. It even has unit tests covering
 some of the more critical parts of the code.
 
+# Getting help
+
+If you're having trouble with Vdebug in any way, here are the steps you can take to get help (in the right order):
+
+  1. [Check the issues][3] to see whether it's already come up.
+  2. Visit the **#vdebug** irc channel on freenode, someone is normally there.
+  3. [Open a new issue.][4]
+
 # News
 
-Vdebug now has an irc channel on freenode! If you're running into problems installing, configuring or running vdebug, or you just want to ask a general question, join us on **#vdebug**.
+**19/07/2013:** there's a known issue with Vdebug and Vim 7.4. Take a look at [issue #98][5] to follow updates and fixes.
+
+**11/06/2013:** Vdebug now has an irc channel on freenode! If you're running into problems installing, configuring or running vdebug, or you just want to ask a general question, join us on **#vdebug**.
 
 # Recent version (version 1.4.1)
 
@@ -160,3 +170,6 @@ This plugin is released under the [MIT License][1].
 
 [1]: https://raw.github.com/joonty/vdebug/master/LICENCE
 [2]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+[3]: https://github.com/joonty/vdebug/issues/
+[4]: https://github.com/joonty/vdebug/issues/new
+[5]: https://github.com/joonty/vdebug/issues/98

doc/Vdebug.txt

@@ -190,7 +190,7 @@ able to apply it to your circumstance.
 The most popular DBGP debugger for PHP is Xdebug.
 
 I find that the most effective way to install Xdebug is to use PECL, instead
-of a OS-level package manager such as apitude or yum. You can also compile it
+of a OS-level package manager such as aptitude or yum. You can also compile it
 from source if you're feeling hardy. To install it via PECL, run this from a
 command line (requires root/admin privileges): >
 
@@ -449,7 +449,7 @@ variable name, type, length (if applicable) and value are shown. They are shown
 as a tree, because arrays/lists and objects have children. Hopefully it's
 fairly self-explanatory: right arrows show a closed tree, down arrows show an
 open tree and diamonds show variables that don't have children. These markers
-be customised (see |VdebugOptions|), and will fall back to ASCII equivalents
+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
@@ -481,7 +481,7 @@ can return to the variable context with <F11> (default).
 4.2.3 The stack window                                     *VdebugStackWindow*
 
 The stack window shows the current execution stack, which is a list of files
-and functions/methods that the program has run through to get the current
+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.
 
@@ -513,7 +513,7 @@ to go for help!
 
 This is a bit of an odd one out, as it doesn't show by default and can be
 summoned at will. It lists all the breakpoints that have been set, and shows
-their IDs that can be used to remove them.
+the IDs that can be used to remove them.
 
 To open the window use the command :BreakpointWindow. It's in a table format,
 so hopefully it won't need any more explanation. To close the window again,
@@ -554,7 +554,7 @@ debugging, and the default keys mapped to those commands.
 
     4.3.3 Step in                                        *VdebugCommandStepIn*
     Default key: <F3>
-    Tells the debugger engine to step in to a statement on the current line.
+    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.
 
@@ -825,7 +825,7 @@ g:vdebug_options["server"] (default = "localhost")
 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 for locking up forever!
+    timeout is there to protect your VIM from locking up forever!
 
                                                       *VdebugOptions-on_close*
 g:vdebug_options["on_close"] (default = "detach")