RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/bwrrp/xspattern.js/issues/9 below:

replace · Issue #9 · bwrrp/xspattern.js · GitHub

Pricing

Saved searches Use saved searches to filter your results more quickly

Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert Additional navigation options

Feature request: let's make this compatible with XPath's fn:matches and fn:replace #9

Description

The patterns used in XPath are very much alike the xs:patterns used in the XSD spec, with the following changes:

Flags

s: the dot-all flag
i: the case insensitive flag
m: the multiline flag
x: the whitespace flag

Partial matches and matching the beginning and end of the input

XPath adds the ^ and $ characters: https://www.w3.org/TR/xpath-functions-31/#matching-start-and-end.
The fn:matches should return true when only a substring of the input matches the pattern, there is basically an implicit .* before and after the query.

Captured subexpressions

https://www.w3.org/TR/xpath-functions-31/#captured-subexpressions I think this may be implemented by recording the start and end of an expression in the whynot program, and output those when the execution is done? Thankfully there is no eagerness involved, returning any match is sufficient.
Non capturing subexpressions, the (?:) variant.

Reluctant quantifiers

See https://www.w3.org/TR/xpath-functions-31/#reluctant-quantifiers.

We only have to be able to parse them for fn:matches,
actually resolving them only affects functions like fn:replace.

Backreferences

Parsing backreferences, this already makes sense to do, but just throw a readable not-supported error when we see them. They should not be syntax errors.
See https://www.w3.org/TR/xpath-functions-31/#back-references for more info. We could implement these backreferences by matching anything in them and filter out the different paths through the whynot execution path to see whether there was an actual match?

Unkown unicode blocks

https://www.w3.org/TR/xpath-functions-31/#unicode-block-names: A regular expression that uses a Unicode block name that is not defined in the version(s) of Unicode supported by the processor (for example \p{IsBadBlockName}) is deemed to be invalid. We could switch this on the language level.

I think it would be cool to implement these features in this library, enabled when a language option is passed to the compile function for example.

You can’t perform that action at this time.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3