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
Update the XRegExp constructor (more specifically the runTokens function) to pass preceding tokens to token handler functions. Alternatively they could be made available on the token handler context (like the existing this.captureNames and this.hasNamedCapture).
In addition to this being a generally useful feature that could enable more powerful syntax addons, this would enable much better handling of where (?:) separators are inserted when stripping whitespace (with flag x) and comments out of a pattern. Currently the getContextualTokenSeparator function is used for this, but it's not very robust. E.g. it avoids adding (?:) if the preceding character is (, but it doesn't deal with (?<name> and other cases where a separator isn't needed.
It would make things even easier if preceding tokens were annotated with a type string (provided as a new property on the options argument of XRegExp.addToken). E.g. from XRegExp('(?<name>\n.)', 'x') you could get:
Then the getContextualTokenSeparator function can easily check whether the preceding token is something that requires the (?:) separator be added.
This above idea of making preceding tokens available to token handler functions would require special handling for the reparse option, since only the final reparsed version of token should be added to the list of prior tokens.
After this change:
Check whether the lines in build.js for handling (?:) are still needed.
Consider removing the cleanup of double (?:)(?:).
Upgrade to support at least (?<name> as an additional case when (?:) doesn't need to be added.
Following up on slevithan#164, this
change prevents a `(?:)` from being inserted in the following places:
* At the beginning of a non-capturing group (the end is already handled)
* Before or after a `|`
* At the beginning or the end of the pattern
This solution isn't as complete as the one suggested in
slevithan#179, but it's a decent
stopgap.
Update the XRegExp constructor (more specifically the
runTokens
function) to pass preceding tokens to token handler functions. Alternatively they could be made available on the token handler context (like the existingthis.captureNames
andthis.hasNamedCapture
).In addition to this being a generally useful feature that could enable more powerful syntax addons, this would enable much better handling of where
(?:)
separators are inserted when stripping whitespace (with flagx
) and comments out of a pattern. Currently thegetContextualTokenSeparator
function is used for this, but it's not very robust. E.g. it avoids adding(?:)
if the preceding character is(
, but it doesn't deal with(?<name>
and other cases where a separator isn't needed.It would make things even easier if preceding tokens were annotated with a
type
string (provided as a new property on theoptions
argument ofXRegExp.addToken
). E.g. fromXRegExp('(?<name>\n.)', 'x')
you could get:Then the
getContextualTokenSeparator
function can easily check whether the preceding token is something that requires the(?:)
separator be added.This above idea of making preceding tokens available to token handler functions would require special handling for the
reparse
option, since only the final reparsed version of token should be added to the list of prior tokens.After this change:
build.js
for handling(?:)
are still needed.(?:)(?:)
.(?<name>
as an additional case when(?:)
doesn't need to be added.See related discussion in #164 (comment).
The text was updated successfully, but these errors were encountered: