bug#22036: 25.0.50; (emacs) Lax Search

[Eli Zaretskii]

> Date: Fri, 27 Nov 2015 20:30:00 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Mostly minor suggestions.  And I realize that some of the problems
> mentioned here are not new - they were already present in node `Special
> Isearch', for example.  But things have deteriorated a bit more, I
> think.  If you can make improvements, that will help readers.

Thanks.  I made most of the changes you suggested; the few comments
below are where I did not.

> 1. "Normally, you'd want", "are normally perceived as equivalent",
> "letter-case differences usually don't matter", "normally ignore the
> case", "Searches in Emacs normally perform"...
> 
> Please rephrase such text.  There is nothing "normal" about one behavior
> or abnormal about the opposite behavior.  There is no norm, here.

I replaced a few of these with "by default", especially where that
alludes to Emacs behavior.  I didn't replace all of them: this is the
"normal" style in the manual, with more than 200 occurrences all over.
I see no reason to replace all of them, and even less reasons to
replace all of them just in this node.

> 3. Why is regexp search not handled here as well?  Why send someone off
> to node `Regexp Search' for info about lax matching during regexp
> search?  Maybe there is a good reason, but as one user I would expect,
> a priori, to read all about lax matching here.

There's a fundamental dilemma when documenting a complex feature such
as this one.  You cannot document it in a single large section,
because it will be too large.  When the description is broken into
several sections and subsections, the dilemma is how to give a
newcomer the big picture without risking drowning them in the details.
What you see is a compromise: some repetition, and some details
stashed in their own subsections and just hinted upon in the general
overview description.

> 7. Everything in this manual is "in Emacs", so you can drop that phrase
> everywhere.

Again, "everywhere" is too radical, IMO.  Dropped a few.

> 8. The explanation of case matching here seems to repeat what is said
> about it in node `Special Isearch'.  More factoring needed, perhaps.

See above: it doesn't repeat, it just summarizes and sends to another
section for details.

> 12. Choose whether you want the term "character folding" to refer to (1)
> the general category of folding of chars, including specific kinds of
> character folding such as case folding and whitespace folding, or (2)
> what is called by the search and replace UI "character folding",
> which is just another specific kind of (character) folding.

I did decide: the text I wrote speaks for itself, I think.  Whether
this is a good decision or needs some corrections -- the time will
tell.  Let the text hit the street, and let's see if there are any
complaints.

> 15. "typing an explicit variant of a character, such as `ä'".  Consider
> adding the char name after this char, or do something else to help
> readers see that what is quoted is not just the letter "a".

I very much doubt we need this with Unicode-capable fonts all around
us.  But if I'm wrong, we will see bug reports.

Thanks.