== General ==

I need to use simpler and clearer language.  Things like "get used to not"
are awkward to read. (Most reviewers)

Unicode must be brought into the book. (David Hand)

Use of the words "fail" and "succeed" need to be made consistent (and
perhaps even defined) -- I often use "fail" when discussing PART of a
regex, and "succeed" when referring to the whole thing. (David Hand)

Comments IN the code might be better as textual comments in paragraphs.  
I don't know if he was referring to the |#1-type comments that become
annotated references, or the often-wordy Perl comments... probably the
latter. (David Hand)

Topics like optimization and debugging should perhaps not placed in the
"reference" section of the book -- perhaps have "optimization" nodes
throughout the book, near regex examples that can be made better with a
simple optimization. (David Cantrell)

Chapters 7, 9, and 10 are outside of the realm of the other regex books on
the market, which is a selling point. (David Cantrell)

BIG nitpick, but very important:  m/.../ is not a regex, but the matching
operator.  This distinction must be made very clear, and I must not make a
mistake about this in the text. (David Cantrell)

The organization needs improvement, and distractions need to be removed.
(Several reviewers offered specific examples)

More illustrations, and more REAL USABLE code examples. (Todd Olson)

The questions at the end of each chapter should be more tutorial-level.
(Todd Olson)

Chapter titles are inconsistent in form, and simply renaming them will
help the chapters organize their content internally. (Todd Olson)

Todd provides a new set of chapter titles and organization.  They look
good to me, but perhaps he's not aware that you're trying to keep the
chapters as similarly-lengthed as possible.  This has caused me to merge
things that end up confusing the reviewers.

If I include optimization hints throughout the text, that might diminish
the need for a separate chapter, which would leave debugging to its own
chapter. (Todd Olson)

Todd has suggested a leading chapter on recognizing regexes in code, but I
don't know exactly how to make this a "chapter" in and of itself.  He gave
a good amount of information to include, but perhaps it should be part of
the introductory chapter, which informs the reader of the non-regex things
found in the code examples, as well as Todd's ideas.


== Chapter 2 ==

The introduction to this chapter needs to be more inviting, and less
tripe.  (The first sentence in the 2nd paragraph is great, though.)

The first example should be REAL EXECUTABLE Perl code. (Todd Olson)

Code examples in the first few chapters need to be more of the "I can do
it" variety.  Readers should be able to take the example, type it in, and
run it. (footpad)

Clarify references to topics or applications (such as grep) that may be
obscure to users of a non-Unix OS (such as Windows). (footpad)

Fix Chapter 2's summary -- I put new material in there that was not
actually covered elsewhere in the chapter. (footpad)

Rework introductory chapters to ensure a gradual slope throughout the
book: that is, be sure that beginners can understand the material in the
first chapters, where the most help is probably needed. (#2)

Chapter 2 should introduce regexes in a less "foreign" way -- the document
'perlretut' is a good example.  Don't make the reader think "regexes are
hard before they're done with the first page. (#2)

Familiarize user with non-regex concepts, such as the $_ variable and the
<DATA> filehandle (and __DATA__ marker).  This might be good pre-regex
content for Chapter 1. (#2)

Regarding <DATA>:  another reviewer suggested not using it at all (Todd
Olson).  But other people I have talked to say that readers want
self-contained examples.  They want to be able to copy the code as it is
and run it, and using <DATA> allows this.  I'll fight for including <DATA>
in the book.

The above reviewer also suggested introducing (?: ... ) for grouping,
rather than ( ... ), because the latter also captures the part of the
string it matches.  I have decided AGAINST this, because it introduces a
more complex element first -- the '?:' part of (?: ) requires explanation
that the reader is NOT prepared for. (#2)

Another reviewer said I should change the way I refer to ( ... ), which is
an option.  I should call them "parentheses", not "grouping parentheses".  
I'll see how that works. (Todd Olson)

Mention that regex libraries are available for C, C++, etc. (David
Cantrell)  But perhaps only as a footnote. (Todd Olson)

Consider not using "Ruby" in examples, to avoid potential advocacy wars.
(David Cantrell)

2.1.2's section heading should be changed to better match the content.
(Todd Olson)

2.1.4 uses "it is important to know", which one reviewer finds
"irritating".  I'll find a better way to write it. (Todd Olson)

2.2.2 should make it clear that backslashing just any character you want
can be dangerous.  Only non-alphanumerics should be backslashed to match
themselves.  I should state this explicitly. (David Hand)

2.2.2 can probably hold the information on interpolation, since the escape
sequences like \f and \t are the same as in a double-quoted string (almost
-- the difference is slight and related to the /x modifier).  The "almost"
clause is small enough, though, that this is a good idea. (David Cantrell)

The footnote in 2.2.5 should perhaps mention when . DOES match \n, but
that involves a reference to the /s modifier, which the reader shouldn't
have thrust upon themself, so I don't think it should be added. (David
Cantrell)

One reviewer says I never mention regexes are used often for merely
testing data.  I thought I did, but I'll make it more clear in the
chapter.  Regexes are, in truth, success/failure tests. (Todd Olson)

2.2.3.3 mentions "nested character classes" which still don't exist.  
I'll either remove it totally, or include a footnote to a URL that
explains how they might be supported. (David Hand)

Case insensitivity should be left until later (like, the chapter on
pattern modifiers). (David Hand)

Have a diagram for 2.3.2 (which it will be), instead of the text with gray
backgrounds. (David Cantrell)

The use of \t and \n in 2.4.1 was called "premature", but I really expect
the reader to have already used simple things like that.  I guess that's
another thing to put in the introductory chapter. (David Hand)

The questions at the end need to be re-ordered to go from easy to
difficult, and need to be less complex.  I'll tone them down to high
school level. (Todd Olson)


== Chapter 3 ==

Don't mention Perl 6, which is undergoing constant (re)development. (#2)

Use figures to *show* what's going on, not *tell* (such as figure 3.7).
(#2)

A clearer figure for 3.2.1 is needed (Friedl's is excellent).  I'll make a
better one. (David Cantrell)

In 3.3.1, I should mention that variable names can be made up of "word
characters", since there's a macro (\w) for those. (David Hand)

Use the standard "\b = word boundary" mnemonic in the table where \b is
introduced. (David Hand)

There's a paragraph explaining WHERE \b and \B match -- this would be
better off as a table of results and a paragraph accompanying the table.
(David Hand)

I use the $ anchor before I explain it.  Must adjust that. (David Hand)


== Chapter 4 ==

I should make a clear note of the slow-down associated with the $`, $&,
and $' variables. (David Hand)

And I need to make it clear that @- and @+ do NOT have such a slow-down.

Chapter may need to be re-organized.  It combines rarely-used features
(such as the matching variables -- I disagree here) with more commonly
used ones.  It talks about scope, which is a difficult subject, and not
regex-related. (#2)

It uses potentially "arcane" variables, like the $. variable.  Examples
should probably be more common-place or practical; they should help the
reader become familiar with regexes, and not other features of Perl. (#2)

The obscure regex variable $^N is an advanced feature, and probably
doesn't deserve the same treatment as the $<DIGIT> variables. (#2)

Oh, and the use of "$DIGIT" in the text is unclear.  I should make it
clear that DIGIT is a placeholder for an actual number, either by
italicizing it, or using "$1, $2, $3, etc.". (David Hand)

The explanation of capturing parentheses needs to be a little simpler to
understand, and the greediness explanation needs less ambiguity.  It is
mentioned that ungreedy matches "do the least work possible", which is a
fib. (#2)

The explanation of m//'s return value belongs somewhere else entirely.  
Since Todd stated that regexes are true/false tests, the simplest return
value case should be in chapter 2. (David Hand)

I repeat an idea in a paragraph in 4.3.1, and it should be cut. (David
Hand)

Section 4.3.2 doesn't fit in well with 4.3, and will be moved to 4.2
instead. (David Hand)

The use of the "fat comma" => is perhaps misleading in the split()
example.  I might get rid of it, because it makes it look like data is
going TO $number, not FROM it. (David Hand)


== Chapter 5 ==

Suffers from organizational issues again.  The (?modifiers) feature should
get its own section, because of its importance. (#2)

Several reviwers were confused by the inclusion of the /o (compile-once
modifier), but I think it should still be included.  If I can introduce it
and make its use clear, simply, then the intricacies of its use can be
divulged in the later chapter on optimization.

The /x modifier should be covered more thoroughly. (#2)

The information on qr// needs to be rechecked for accuracy (about it being
a speed improvement in the cases where I say it is). (#2)

The /c modifier is left out and included in the next chapter, since it
relates directly and ONLY to global matching.  Perhaps some of chapter 6
should be put into this chapter?  (#2)

The 'pgrep' program in 5.3.1.1 appears to have been lifted directly from
another book.  I don't THINK I copied it, since it's a pretty simple
program, but if Manning would prefer I mention it's similar to 'pgrep'
(which stands, I would imagine, for "Perl grep") in another Perl text, I
will do so. (Todd Olson)

Section 5.4 needs to be reorganized. (David Hand)

There should be a reference to a place explaining why NOT to parse HTML
with a regex, and what to do instead. (David Hand)

Section 5.4.1.2 will be dedicated to (?:imsx-imsx), and (?:) alone will
have its own subsection. (David Hand)


== Chapter 6 ==

\G needs better detail. (David Hand)

Let reader know about Parse::Yapp, Parse::RecDescent, etc. (David Hand)


== Chapter 7 ==

Examples using @- and @+ validate their introduction earlier in the book,
but might be confusing.  My reason for introducing the variables and using
them in examples is this:  often, when people ask about how to get certain
information out of a regex, the answer to their question is to use those
arrays, and they never KNEW about the arrays because they'd never read
about them, and I'm trying to fix that.  This book is not trying to change
inexperienced regex users into beginner regex users that need yet ANOTHER
book, but rather to get them to the intermediate stage where they
understand all the documentation, and understand some of the more advanced
concepts in the book. (#2)

The word-grid example should use simpler words. (#2)

Substitution should be moved further forward in the book. (#2, Todd Olson)

My note about how substitution works on a copy of the original string
should be made more clear. (David Hand)

Example 7.4.2 is a bit confusing.  I'll clear it up.  I'll also include
the FAQ entry. (David Hand)

7.5.1 and 7.5.3 don't fit into the rest of 7.5.  I'll relocate them.  
(David Hand)

Example 7.7, while good, is a bit hard to follow.  I'll try to clear it
up.  (David Hand)


== Chapter 8 ==

Section 8.1.3 has a code example that doesn't agree with the text. (#2,
David Hand)

I should explain why alternation is safer in 8.1.6.1. (David Hand)

Expand on the "sexeger" concept. (#2)

Exercise 8 is all wrong.  I never changed it after I reorganized the rest
of the chapter.  I'll replace it. (David Hand)


== Chapter 9 ==

The explanations of $`, $&, and $' is muddled.  I'll clear up the examples
and explanations. (David Hand)

I need to explain the techniques I use in the code in 9.1.3. (David Hand)

Section 9.2.2 is very unclear.  I'll break it up into smaller pieces of
information and explain each part individually. (David Hand)

Section 9.2.3 is a great place to showcase a recursive regex, so I'll use
one there and explain the process. (David Hand)

I need to clarify what the condition in a (?(cond)true|false) can be.
(David Hand)


== Chapter 10 ==

My "idiom" talk is a little strained.  I'll reword it, or find some other
approach entirely. (David Hand)

Talk about the Activestate Visual Regex Debugger, part of Komodo. (#2)

Terminology error:  "quad" should be "octet". (David Cantrell)

10.2.2 will be reworded:  Because NFA engines have more interest in the
regex than DFA engines,... (David Hand)

10.2.3.3 needs its illustration.  I'll get on that. (David Hand)

10.3.2 needs to be a bit more explicit and clear. (David Hand)

I should mention \G in section 10.4. (David Hand)

10.4.3 mentions optimization, not debugging.  I'll rearrange the section
to make the chapter flow better. (David Hand)