Update features.rst

Author: rocky

docs/features.rst

@@ -3,8 +3,7 @@
 Features
 ========
 
-Since this debugger is similar to other_ trepanning_ debuggers_ and *gdb*
-in general, knowledge gained by learning this is transferable to those
+Since this debugger is similar to other_ trepanning_ debuggers_ and *gdb* in general, knowledge gained by learning this is transferable to those
 debuggers and vice versa.
 
 There's a lot of cool stuff here that's not in the stock
@@ -14,32 +13,29 @@ Python debugger *pdb*, or in any other Python debugger that I know about.
 More Exact location information
 -------------------------------
 
-Python reports line information on the granularity of a line. To get
-more precise information, we can (de)parse into Python the byte code
-around a bytecode offset such as the place you are stopped at.
+Python reports line information on the granularity of a line. To get more precise information, we can (de)parse into Python the bytecode
+around a bytecode offset, such as the place you are stopped at.
 
-So far as I know, there is no other debugger that decompile code at runtime.
+So far as I know, there is no other debugger that decompiles code at runtime.
 
 See the `deparse <deparse>`_ command for details.
 
-We use information in the line number table in byte to understand
+We use information in the line number table in bytes to understand
 which lines are breakpointable, and in which module or function the
-line appears in. Use `info line <_info_line>`_ to see this information.
+line appears. Use `info line <_info_line>`_ to see this information.
 
-In the future we may allow specifying an offset to indicate which
+In the future, we may allow specifying an offset to indicate which
 offset to stop at when there are several choices for a given line
 number.
 
 
 Debugging Python bytecode (no source available)
 -----------------------------------------------
 
-You can pass the debugger the name of Python bytecode and many times,
-the debugger will merrily proceed.  This debugger tries very hard find
-the source code. Either by using the current executable search path
+You can pass the debugger the name of Python bytecode, and many times, the debugger will merrily proceed.  This debugger tries very hard to find the source code. Either by using the current executable search path
 (e.g. ``PATH``) or for some by looking inside the bytecode for a
 filename in the main code object (``co_filename``) and applying that
-with a search path which takes into account directory where the
+with a search path that takes into account the directory where the
 bytecode lives.
 
 Failing to find source code this way, and in other situations where
@@ -57,7 +53,7 @@ Source-code Syntax Colorization
 -------------------------------
 
 Terminal source code is colorized via pygments_ . And with that you
-can set the pygments color style, e.g. "colorful", "paraiso-dark". See
+can set the pygments color style, e.g., "colorful", "paraiso-dark". See
 :ref:`set style <set_style>`. Furthermore, we make use of terminal bold
 and emphasized text in debugger output and help text. Of course, you
 can also turn this off. Starting with release 0.6.0, you can use your
@@ -84,16 +80,16 @@ Smart Eval
 ----------
 
 If you want to evaluate the current source line before it is run in
-the code, use ``eval``. To evaluate text of a common fragment of line,
+the code, use ``eval``. To evaluate the text of a common fragment of a line,
 such as the expression part of an *if* statement, you can do that with
 ``eval?``. See :ref:`eval` for more information.
 
 More Stepping Control
 ---------------------
 
-Sometimes you want small steps, and sometimes large stepping.
+Sometimes you want small steps, and sometimes large steps.
 
-This fundamental issue is handled in a couple ways:
+This fundamental issue is handled in a couple of ways:
 
 Step Granularity
 ................
@@ -127,63 +123,57 @@ definitions probably also added to this tedium.
 
 Because we're really handling return events, we can show you the return value. (*pdb* has an "undocumented" *retval* command that doesn't seem to work.)
 
-Debugger Macros via Python Lambda expressions
+Debugger Macros via Python Lambda Expressions
 ---------------------------------------------
 
-There are debugger macros.  In *gdb*, there is a *macro* debugger
-command to extend debugger commands.
+There are debugger macros.  In *gdb*, there is a *macro* debugger command to extend debugger commands.
 
-However Python has its own rich programming language so it seems silly
+However, Python has its own rich programming language, so it seems silly
 to recreate the macro language that is in *gdb*. Simpler and more
 powerful is just to use Python here. A debugger macro here is just a
-lambda expression which returns a string or a list of strings. Each
+lambda expression that returns a string or a list of strings. Each
 string returned should be a debugger command.
 
 We also have *aliases* for the extremely simple situation where you
 want to give an alias to an existing debugger command. But beware:
 some commands, like step_ inspect command suffixes and change their
 behavior accordingly.
 
-We also envision a number of other ways to allow extension of this
-debugger either through additional modules, or user-supplied debugger
-command directories.
+We also envision a number of other ways to allow the extension of this
+debugger either through additional modules or through user-supplied debugger command directories.
 
 Byte-code Instruction Introspection
 ------------------------------------
 
-We do more in the way of looking at the byte codes to give better information. Through this we can provide:
+We do more in the way of looking at the byte codes to give better information. Through this, we can provide:
 
-* a *skip* command. It is like the *jump* command, but you don't have
+* A *skip* command. It is like the *jump* command, but you don't have
   to deal with line numbers.
-* disassembly of code fragments. You can now disassemble relative to
+* Disassembly of code fragments. You can now disassemble relative to
   the stack frames you are currently stopped at.
 * Better interpretation of where you are when inside *execfile* or
-  *exec*. (But really though this is probably a Python compiler
+  *exec*. (But really, though this is probably a Python compiler
   misfeature.)
 * Check that breakpoints are set only where they make sense.
-* A more accurate determination of if you are at a function-defining
+* A more accurate determination of whether you are at a function-defining
   *def* or *class* statements (because the caller instruction contains
   ``MAKE_FUNCTION`` or ``BUILD_CLASS``.)
 
 Even without "deparsing" mentioned above, the ability to disassemble
-where the PC is currently located (see `info pc <info_pc>`_), by line
-number range or byte-offset range lets you tell exactly where you are
-and code is getting run.
+where the PC is currently located (see `info pc <info_pc>`_), by line number range or byte-offset range lets you tell exactly where you are and the code is getting run.
 
 Some Debugger Command Arguments can be Variables and Expressions
 ----------------------------------------------------------------
 
-Commands that take integer arguments like *up*, *list* or
-*disassemble* allow you to use a Python expression which may include
-local or global variables that evaluates to an integer. This
+Commands that take integer arguments like *up*, *list*, or *disassemble* allow you to use a Python expression which may include
+local or global variables that evaluate to an integer. This
 eliminates the need in *gdb* for special "dollar" debugger
-variables. (Note however because of *shlex* parsing ,expressions can't
-have embedded blanks.)
+variables. (Note, however, because of *shlex* parsing, expressions can't have embedded blanks.)
 
 Out-of-Process Debugging
 ------------------------
 
-You can now debug your program in a different process or even a different computer on a different network!
+You can now debug your program in a different process or even on a different computer on a different network!
 
 Egg, Wheel, and Tarballs
 ------------------------
@@ -196,17 +186,17 @@ full instructions and installing from git and by other means.
 Modularity
 ----------
 
-The Debugger plays nice with other trace hooks. You can have several debugger objects.
+The Debugger plays nicely with other trace hooks. You can have several debugger objects.
 
 Many of the things listed below doesn't directly effect end-users, but
 it does eventually by way of more robust and featureful code. And
 keeping developers happy is a good thing.(TM)
 
-* Commands and subcommands are individual classes now, not methods in a class. This means they now have properties like the context in which they can be run, minimum abbreviation name or alias names. To add a new command you basically add a file in a directory.
-* I/O is it's own layer. This simplifies interactive readline behavior from reading commands over a TCP socket.
-* An interface is it's own layer. Local debugging, remote debugging, running debugger commands from a file (``source``) are different interfaces. This means, for example, that we are able to give better error reporting if a debugger command file has an error.
+* Commands and subcommands are individual classes now, not methods in a class. This means they now have properties like the context in which they can be run, a minimum abbreviation name, or alias names. To add a new command, you basically add a file in a directory.
+* I/O is its own layer. This simplifies interactive readline behavior from reading commands over a TCP socket.
+* An interface is its own layer. Local debugging, remote debugging, and running debugger commands from a file (``source``) are different interfaces. This means, for example, that we are able to give better error reporting if a debugger command file has an error.
 * There is an experimental Python-friendly interface for front-ends
-* more testable. Much more unit and functional tests. More of *pydb*'s integration test will eventually be added.
+* more testable. Much more unit and functional tests. More of *pydb*'s integration tests will eventually be added.
 
 Documentation
 -------------