Copy edits for the regexp sections in the manuals
* doc/lispref/searching.texi (Regexp Backslash): * doc/emacs/search.texi (Regexps, Regexp Backslash): Copy edits from Jay Bingham (bug#41970).
This commit is contained in:
parent
e195ac3df0
commit
60a15fae02
2 changed files with 44 additions and 44 deletions
|
@ -1027,24 +1027,9 @@ you search for @samp{a.*?$} against the text @samp{abbab} followed by
|
|||
a newline, it matches the whole string. Since it @emph{can} match
|
||||
starting at the first @samp{a}, it does.
|
||||
|
||||
@item @kbd{\@{@var{n}\@}}
|
||||
is a postfix operator specifying @var{n} repetitions---that is, the
|
||||
preceding regular expression must match exactly @var{n} times in a
|
||||
row. For example, @samp{x\@{4\@}} matches the string @samp{xxxx} and
|
||||
nothing else.
|
||||
|
||||
@item @kbd{\@{@var{n},@var{m}\@}}
|
||||
is a postfix operator specifying between @var{n} and @var{m}
|
||||
repetitions---that is, the preceding regular expression must match at
|
||||
least @var{n} times, but no more than @var{m} times. If @var{m} is
|
||||
omitted, then there is no upper limit, but the preceding regular
|
||||
expression must match at least @var{n} times.@* @samp{\@{0,1\@}} is
|
||||
equivalent to @samp{?}. @* @samp{\@{0,\@}} is equivalent to
|
||||
@samp{*}. @* @samp{\@{1,\@}} is equivalent to @samp{+}.
|
||||
|
||||
@item @kbd{[ @dots{} ]}
|
||||
is a @dfn{character set}, beginning with @samp{[} and terminated by
|
||||
@samp{]}.
|
||||
is a @dfn{a set of alternative characters}, beginning with @samp{[}
|
||||
and terminated by @samp{]}.
|
||||
|
||||
In the simplest case, the characters between the two brackets are what
|
||||
this set can match. Thus, @samp{[ad]} matches either one @samp{a} or
|
||||
|
@ -1132,12 +1117,12 @@ to depend on this behavior; it is better to quote the special character anyway,
|
|||
regardless of where it appears.
|
||||
|
||||
As a @samp{\} is not special inside a character alternative, it can
|
||||
never remove the special meaning of @samp{-} or @samp{]}. So you
|
||||
should not quote these characters when they have no special meaning
|
||||
either. This would not clarify anything, since backslashes can
|
||||
legitimately precede these characters where they @emph{have} special
|
||||
meaning, as in @samp{[^\]} (@code{"[^\\]"} for Lisp string syntax),
|
||||
which matches any single character except a backslash.
|
||||
never remove the special meaning of @samp{-}, @samp{^} or @samp{]}.
|
||||
So you should not quote these characters when they have no special
|
||||
meaning either. This would not clarify anything, since backslashes
|
||||
can legitimately precede these characters where they @emph{have}
|
||||
special meaning, as in @samp{[^\]} (@code{"[^\\]"} for Lisp string
|
||||
syntax), which matches any single character except a backslash.
|
||||
|
||||
@node Regexp Backslash
|
||||
@section Backslash in Regular Expressions
|
||||
|
@ -1202,11 +1187,11 @@ matches the same text that matched the @var{d}th occurrence of a
|
|||
@samp{\( @dots{} \)} construct. This is called a @dfn{back
|
||||
reference}.
|
||||
|
||||
After the end of a @samp{\( @dots{} \)} construct, the matcher remembers
|
||||
the beginning and end of the text matched by that construct. Then,
|
||||
later on in the regular expression, you can use @samp{\} followed by the
|
||||
digit @var{d} to mean ``match the same text matched the @var{d}th time
|
||||
by the @samp{\( @dots{} \)} construct''.
|
||||
After the end of a @samp{\( @dots{} \)} construct, the matcher
|
||||
remembers the beginning and end of the text matched by that construct.
|
||||
Then, later on in the regular expression, you can use @samp{\}
|
||||
followed by the digit @var{d} to mean ``match the same text matched
|
||||
the @var{d}th @samp{\( @dots{} \)} construct''.
|
||||
|
||||
The strings matching the first nine @samp{\( @dots{} \)} constructs
|
||||
appearing in a regular expression are assigned numbers 1 through 9 in
|
||||
|
@ -1223,6 +1208,21 @@ If a particular @samp{\( @dots{} \)} construct matches more than once
|
|||
(which can easily happen if it is followed by @samp{*}), only the last
|
||||
match is recorded.
|
||||
|
||||
@item @kbd{\@{@var{m}\@}}
|
||||
is a postfix operator specifying @var{m} repetitions---that is, the
|
||||
preceding regular expression must match exactly @var{m} times in a
|
||||
row. For example, @samp{x\@{4\@}} matches the string @samp{xxxx} and
|
||||
nothing else.
|
||||
|
||||
@item @kbd{\@{@var{m},@var{n}\@}}
|
||||
is a postfix operator specifying between @var{m} and @var{n}
|
||||
repetitions---that is, the preceding regular expression must match at
|
||||
least @var{m} times, but no more than @var{n} times. If @var{n} is
|
||||
omitted, then there is no upper limit, but the preceding regular
|
||||
expression must match at least @var{m} times.@* @samp{\@{0,1\@}} is
|
||||
equivalent to @samp{?}. @* @samp{\@{0,\@}} is equivalent to
|
||||
@samp{*}. @* @samp{\@{1,\@}} is equivalent to @samp{+}.
|
||||
|
||||
@item \`
|
||||
matches the empty string, but only at the beginning of the string or
|
||||
buffer (or its accessible portion) being matched against.
|
||||
|
|
|
@ -549,12 +549,12 @@ can act. It is poor practice to depend on this behavior; quote the
|
|||
special character anyway, regardless of where it appears.
|
||||
|
||||
As a @samp{\} is not special inside a character alternative, it can
|
||||
never remove the special meaning of @samp{-} or @samp{]}. So you
|
||||
should not quote these characters when they have no special meaning
|
||||
either. This would not clarify anything, since backslashes can
|
||||
legitimately precede these characters where they @emph{have} special
|
||||
meaning, as in @samp{[^\]} (@code{"[^\\]"} for Lisp string syntax),
|
||||
which matches any single character except a backslash.
|
||||
never remove the special meaning of @samp{-}, @samp{^} or @samp{]}.
|
||||
So you should not quote these characters when they have no special
|
||||
meaning either. This would not clarify anything, since backslashes
|
||||
can legitimately precede these characters where they @emph{have}
|
||||
special meaning, as in @samp{[^\]} (@code{"[^\\]"} for Lisp string
|
||||
syntax), which matches any single character except a backslash.
|
||||
|
||||
In practice, most @samp{]} that occur in regular expressions close a
|
||||
character alternative and hence are special. However, occasionally a
|
||||
|
@ -823,21 +823,21 @@ the characters that stand for them.
|
|||
matches any character whose syntax is not @var{code}.
|
||||
|
||||
@cindex category, regexp search for
|
||||
@item \c@var{c}
|
||||
matches any character whose category is @var{c}. Here @var{c} is a
|
||||
character that represents a category: thus, @samp{c} for Chinese
|
||||
characters or @samp{g} for Greek characters in the standard category
|
||||
table. You can see the list of all the currently defined categories
|
||||
with @kbd{M-x describe-categories @key{RET}}. You can also define
|
||||
your own categories in addition to the standard ones using the
|
||||
@item \c@var{code}
|
||||
matches any character whose category is @var{code}. Here @var{code}
|
||||
is a character that represents a category: thus, @samp{code} for
|
||||
Chinese characters or @samp{g} for Greek characters in the standard
|
||||
category table. You can see the list of all the currently defined
|
||||
categories with @kbd{M-x describe-categories @key{RET}}. You can also
|
||||
define your own categories in addition to the standard ones using the
|
||||
@code{define-category} function (@pxref{Categories}).
|
||||
|
||||
@item \C@var{c}
|
||||
matches any character whose category is not @var{c}.
|
||||
@item \C@var{code}
|
||||
matches any character whose category is not @var{code}.
|
||||
@end table
|
||||
|
||||
The following regular expression constructs match the empty string---that is,
|
||||
they don't use up any characters---but whether they match depends on the
|
||||
they don't consume any characters---but whether they match depends on the
|
||||
context. For all, the beginning and end of the accessible portion of
|
||||
the buffer are treated as if they were the actual beginning and end of
|
||||
the buffer.
|
||||
|
|
Loading…
Add table
Reference in a new issue