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
Sometimes a replacement/macro only makes sense with some surrounding context, tries should contain marker information as to how many of the first bytes of the match should be emitted and where to position the output buffer.
Ex.
If I want to replace "bar" but only in the case that it appears as "foobarbaz", the trie can contain "foobarbaz" and link it to an operation but should indicate that the first 3 characters should be treated as non-matched (to emit "foo"/give it to a handler that matches "foo" or a subset before executing the operation at the position of "bar") and the input buffer's position should be 3 before the end of the match (to allow "bar" to be emitted/matched similar to "foo" from the pre- case)
The text was updated successfully, but these errors were encountered:
Current design is to unify the two trie structures and demand (via generic constraints) that a start-end pair must be present for all terminal trie nodes that indicates the section of the path to terminal that should be used as the located token.
Yes I think this is needed for real world templates. For example in my CSS I have "background-color: white" and I want to prompt for a new color. When the replacement is applied it should only change "white" if it's immediately after "background-color:".
Sometimes a replacement/macro only makes sense with some surrounding context, tries should contain marker information as to how many of the first bytes of the match should be emitted and where to position the output buffer.
Ex.
If I want to replace "bar" but only in the case that it appears as "foobarbaz", the trie can contain "foobarbaz" and link it to an operation but should indicate that the first 3 characters should be treated as non-matched (to emit "foo"/give it to a handler that matches "foo" or a subset before executing the operation at the position of "bar") and the input buffer's position should be 3 before the end of the match (to allow "bar" to be emitted/matched similar to "foo" from the pre- case)
The text was updated successfully, but these errors were encountered: