Re: Incomplete/misleading description of GLOB_SUBST and $~ paramter expansion flag

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> This resulted from this line of Sven's:
> 
> if [[ "$cmd1" == $~pat || "$cmd2" == $~pat ]] then
> 
> (again something, I didn't know before and that is hard to infer from
> manuals :-(
> 
> The current description of above items imply, that they affect only file
> name expansion (globbing). The reality is, they prevent globbing
> metacharacters from being quoted in _any_ context where glob pattern is
> used. This includes, but is not limited to, filename expansion.

The patch below cleans up the docs for this and for completion
matching. Still no examples in the `$~foo' case, though.

Bye
 Sven

diff -u od/Zsh/compctl.yo Doc/Zsh/compctl.yo
--- od/Zsh/compctl.yo	Mon Feb  1 10:53:36 1999
+++ Doc/Zsh/compctl.yo	Tue Feb  2 15:08:32 1999
@@ -580,7 +580,8 @@
 a letter followed by a colon and the patterns describing which character
 sequences on the line match which character sequences in the words.
 
-The letters understood are: tt(l), tt(r), tt(m), tt(L), tt(R), and tt(M).
+The letters understood are:
+
 startitem()
 item(tt(m) and tt(M))(
 These describe patterns that match anywhere in the words. The colon should
@@ -605,20 +606,20 @@
 enditem()
 
 Each pattern is either an empty string or consists of a sequence of
-character (possibly quoted), question marks, character classes, and
-correspondence classes. Normal characters match only themselves, question
-marks match any character, and character classes are formed as for
-globbing and match the same characters as there.
-Correspondence classes are formed like character classes with two
-differences: they are delimited by a pair of braces and negated
+characters (possibly quoted with backslashes), question marks,
+character classes, and correspondence classes. Normal characters match
+only themselves, question marks match any character, and character
+classes are formed as for globbing and match the same characters as
+there. Correspondence classes are formed like character classes with
+two differences: they are surrounded by a pair of braces and negated
 classes are not allowed (i.e. the characters tt(!) and tt(^) have no
 special meaning directly after the opening brace).
 
 Correspondence classes are used to conveniently describe that several
 characters on the line match several other characters in the word. For 
-example, if you want to define the any lowercase letter on the line
+example, if you want to define that any lowercase letter on the line
 matches the corresponding uppercase letter in the word all you need to 
-write down is: `tt(m:{a-z}={A-Z})'. More than one correspondence class
+write is: `tt(m:{a-z}={A-Z})'. More than one correspondence class
 may be given on either side of the equal sign, in this case the first
 class on the left says which character matches for the first class on
 the right, the second class on either side work together, and so on.
@@ -643,16 +644,15 @@
 lowercase forms use the substring from the word, so this should be
 used if the exact words produced by the completion code need to be
 used. The uppercase forms use the substring from the command line and
-should be used if the typed string need to be retained.
+should be used if the typed string needs to be retained.
 
 Examples:
 
-startitem()
 The option tt(-o) produces option names in all-lowercase form, without 
 underscores, and without the optional tt(no) at the beginning even
-though the buitlins tt(setopt) and tt(unsetopt) understand opotion
+though the builtins tt(setopt) and tt(unsetopt) understand option
 names with uppercase letters, underscores, and the optional tt(no).
-So we want to be able to say, that in this case an prefix tt(no) and
+So we want to be able to say that in this case an prefix tt(no) and
 any underscore may be ignored when trying to match the produced words, 
 and that uppercase letters on the line match the corresponding
 lowercase letters in the words. This can be done with:
@@ -670,7 +670,7 @@
 uppercase letter on the line matches the corresponding lowercase
 letter in the word. The use of the uppercase forms of the
 specification characters (tt(L) and tt(M)) guarantees that the special 
-wrinting on the command line (and especially the option tt(no)) will
+writing on the command line (and especially the option tt(no)) will
 not be erased.
 
 As a second example we will make completion case insensitive. For this 
@@ -689,7 +689,7 @@
 have to use:
 
 indent(
-tt(compctl -M 'm:{a-z}={A-Z} m:{A-Z}={a-z}')
+tt(compctl -M 'm:{a-zA-Z}={A-Za-z}')
 )
 
 A nice example for the use of tt(*) patterns is partial word
@@ -697,7 +697,7 @@
 complete to strings like tt(comp.source.unix), i.e. you consider the
 word to consist of multiple parts (separated by the dot in the
 example) and each part should be completed separately. Defining such
-forms of matching is simple, for example if we want to separately
+forms of matching is simple. For example, if we want to separately
 complete word parts separated by dots, commas, underscores, and
 hyphens, we can do this by saying:
 
@@ -710,7 +710,7 @@
 word which has the effect we wanted. The second specification is
 needed to make this work when the cursor is in the middle of the word
 and the option tt(COMPLETE_IN_WORD) is set. In this case the
-completion code would normally try to match word that end with the
+completion code would normally try to match words that end with the
 string that is already on the command line, but in our example we
 would like the code to match words even if they contain extra
 characters after the string on the line. Hence we say that the empty
@@ -719,7 +719,7 @@
 
 The form of tt(compctl) that defines the global matching
 specifications is a bit more powerful than described until now. It
-accepts not only one specification strin, but any number of them. When 
+accepts not only one specification string, but any number of them. When 
 completion is attempted, the code first uses the definitions from the
 first string. If no words could be matched with these specifications,
 it tries the whole thing again with the specifications from the second 
@@ -737,10 +737,10 @@
 )
 
 If using the first specification string does not produce matches, the
-second one is tried. The two descriptions it this string say that the
+second one is tried. The two descriptions in this string say that the
 empty string at the beginning and end of the string on the line
 matches any characters at the beginning or end of the word.
-enditem()
+
 texinode(Example)()(Matching Control)(Programmable Completion)
 sect(Example)
 nofill(tt(compctl -u -x 's[tt(PLUS())] c[-1,-f],s[-f+PLUS()]' -g '~/Mail/*(:t)' \ 
diff -u od/Zsh/expn.yo Doc/Zsh/expn.yo
--- od/Zsh/expn.yo	Mon Feb  1 10:53:36 1999
+++ Doc/Zsh/expn.yo	Tue Feb  2 15:16:18 1999
@@ -477,9 +477,10 @@
 pindex(GLOB_SUBST)
 Turn on the tt(GLOB_SUBST) option for the evaluation of
 var(spec); if the `tt(~)' is doubled, turn it off.  When this option is
-set, any pattern characters resulting
-from parameter expansion are eligible for filename expansion and filename
-generation.
+set, the string resulting from the expansion will be interpreted as a
+pattern thus becoming eligible for filename expansion and filename
+generation and usable as a pattern in pattern-matching contexts like
+the `tt(=)' and `tt(!=)' operators in conditions.
 )
 enditem()
 

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx