Lines Matching refs:what
1148 running any of them. (Because I keep forgetting what they all are.)
1568 5. Comprehensive information about what went wrong is now returned by
2296 9. The restrictions on what a pattern can contain when partial matching is
2452 correctly handled. The rule now is that both the assertion and what follows
2868 double what it should be. I removed one of the increments, but Craig sent a
3138 what I have chosen to do makes the common cases work: PCRE now takes note
3432 compiler treats it as an empty string (which was what was wanted) but it is
3676 byte characters or as UTF-8, which is what "perltest" was being required to
3677 do for the non-UTF-8 and UTF-8 tests, respectively. Essentially what you
3683 the end of the subject string, contrary to the documentation and to what
3715 14. Added forward references in named backreferences (if you see what I mean).
4260 -q that suppresses the output of matching lines, which was what -s was
4343 compiler options, which is what is needed, but I have no means of testing
4475 what's available on my current Linux desktop machine.
4771 only to what follows. PCRE has been changed to follow suit. However, if it
4802 Java package. This provides some syntactic sugar for simple cases of what my
4804 as (?>x*). In other words, if what is inside (?>...) is just a single repeated
4896 to vary what happens:
5000 what is wanted and the second points to where the information is to be placed.
5080 because what follows is always an absolute path. (Later: it turns out that this
5086 (i) A callout function now has three choices for what it returns:
5335 Totally extraordinary, but if that's what it takes...
5371 pattern, which is not what we want. Replace // by /(?#)/ in order to avoid this
5915 a subpattern that had matched an empty string, e.g. /(a|)\1*/. It now does what
