<?xml version="1.0" encoding="UTF-8"?>
<commit>
  <added type="array"/>
  <modified type="array">
    <modified>
      <diff>@@ -13,9 +13,6 @@ source'd files in their arrays.
 
 1. SETUP
 
-Although debuggers are useful for novice, right now code setup is not
-really but novices. Some assembly is required. 
-
 To get the code, install git and run in a zsh shell:
 
   git-clone git://github.com/rocky/zshdb.git
@@ -25,15 +22,10 @@ To get the code, install git and run in a zsh shell:
 If you've got a suitable zsh installed, then
   make &amp;&amp; make test
 
-To simplify demonstration/testing there is a little program testing.sh
-in the same directory zshdb lives in the source code which gets run
-when zshdb is run without any options. so to run this demo code:
-  ./zshdb # in the zshdb project
-
-Or try on a real program such as perhaps:
+To try on a real program such as perhaps /etc/zsh/zshrc:
   ./zshdb /etc/zsh/zshrc # substitute .../zshrc with your favorite zsh script
 
-If you are happy (which I doubt), install via:
+If you are happy and &quot;make test&quot; above worked, install via:
   sudo make install
 
 and uninstall with 
@@ -43,14 +35,6 @@ See INSTALL for generic configure installation instructions.
 
 2. WHAT'S HERE, WHAT'S NOT and WHY NOT
 
-Usually when folks write programs such as a debugger, initially there
-will be a number of useful commands minimally done. Since I sort of
-know where I want to wind up (somewhere along the lines of bashdb),
-initially I've been focusing on the skeleton and framework rather than
-the features no matter how useful they may be. So for example, Unit
-tests and a some integration tests work, even though there no command
-to set breakpoints.
-
 What's missing falls into a two categories:
 
   * Stuff that can be ported in a straightforward way from bashdb
@@ -68,7 +52,7 @@ get a list of commands and some help for each.
 
 3. WHAT'S NOT HERE YET IN DETAIL
 
-3.a) Showing frame arguments and subshell nesting for the frame
+3.a) Showing frame arguments
 
 This can done with or without support from zsh, albeit faster with
 help from zsh. Changing scope when changing frames however has to be
@@ -78,21 +62,23 @@ done with zsh support.
 
 3.c) lots of other stuff including...
 
-  display expressions, signal handling, command completion.
+  display expressions, signal handling, 
+  debugger commands:
+     debug
+     condition
+     file
+     handle
+     history
+     pwd
+     signal
+     tty
+     watch
 
   None of this is rocket science. Should be pretty straight-forward to
   add.
 
 4. WHAT MAY NEED MORE WORK AND SUPPORT FROM ZSH
 
-4.a) line number information
-
-We rely on zsh to give line numbers. In some cases the numbers can be
-funky. Languages which grew up without debuggers tend to be sloppy
-about tracking line number information accurately, because nobody care
-about it that much, so folks don't notice. (But in truth better line
-numbers also means more accurate error reporting information as well.)
- 
-4.c) stopping points that can be used for breakpoint
+4.a) stopping points that can be used for breakpoint
 
 </diff>
      <filename>README</filename>
    </modified>
  </modified>
  <removed type="array"/>
  <parents type="array">
    <parent>
      <id>b5ab94e920dd9a665ef9bf0d2a6fc7a8174a5bd0</id>
    </parent>
  </parents>
  <author>
    <name>R. Bernstein</name>
    <email>rocky@gnu.org</email>
  </author>
  <url>http://github.com/rocky/zshdb/commit/c11836dc6a1820e0da839b2a0a9f993556f3739f</url>
  <id>c11836dc6a1820e0da839b2a0a9f993556f3739f</id>
  <committed-date>2009-06-19T06:21:19-07:00</committed-date>
  <authored-date>2009-06-19T06:21:19-07:00</authored-date>
  <message>Revise as appropriate</message>
  <tree>f5b92800d71fe9191eb942c2556da49b85b3b49d</tree>
  <committer>
    <name>R. Bernstein</name>
    <email>rocky@gnu.org</email>
  </committer>
</commit>
