@@ -207,16 +207,6 @@ methods.
207
207
X < |ws >
208
208
= head3 C < ws >
209
209
210
- When C < rule > instead of C < token > is used, any whitespace after terms and closing
211
- parenthesis/brackets is turned into a non-capturing call to C < ws > ,
212
- written as C « <.ws> » where C < . > means non-capturing. That is to say:
213
-
214
- rule entry { <key> '=' <value> }
215
-
216
- Is the same as:
217
-
218
- token entry { <key> <.ws> '=' <.ws> <value> <.ws> }
219
-
220
210
The default C < ws > matches zero or more whitespace characters, as long as that
221
211
point is not within a word (in code form, that's C « regex ws { <!ww> \s* } » ):
222
212
@@ -231,6 +221,20 @@ point is not within a word (in code form, that's C«regex ws { <!ww> \s* }»):
231
221
# Successful match: there is a word boundary between ')' and 'b'
232
222
say ')b' ~~ /. <.ws> b/; # OUTPUT: «「)b」»
233
223
224
+ Please bear in mind that we're preceding C < ws > with a dot to avoid capturing,
225
+ which we are not interested in. Since in general whitespace is a separator, this
226
+ is how it's mostly found.
227
+
228
+ When C < rule > instead of C < token > is used, any whitespace after terms and closing
229
+ parenthesis/brackets is turned into a non-capturing call to C < ws > ,
230
+ written as C « <.ws> » where C < . > means non-capturing. That is to say:
231
+
232
+ rule entry { <key> '=' <value> }
233
+
234
+ Is the same as:
235
+
236
+ token entry { <key> <.ws> '=' <.ws> <value> <.ws> }
237
+
234
238
You can also redefine the default C < ws > token:
235
239
236
240
grammar Foo {
0 commit comments