On Sat, Nov 7, 2020, at 09:53, Tedd Sterr wrote: > You don't need to go backwards, you decide whether the current > character is a valid open according to the next character - you have > to do this anyway to check for spaces.
That's fair. I think you may be right that it doesn't violate the rules to decide that both tokens are invalid vs. just the second one, making this underspecified (not just confusing). I'll start a new reply thread with what the implementations I know about do so we can figure out if it's possible to fix this one way or the other. > Given a very-contrived-to-prove-the-point input such as: "*text _text > ~text" You would see the asterisk, decide that's an open, and then > search all the way to end of the string looking for a matching close - > you wouldn't find one, so then you'd have to go back and say the > asterisk isn't an open. Then you'd get to the underscore … It doesn't really matter, but you could also just use your technique here and range over the entire span (or to the first newline if the opening turns out to not have a matching closing) and mark each token as valid or not as you come to it, then when you're done with everything return the tokens you found. You don't have to repeatedly scan, and whether this example works one way or another doesn't change that as far as I can tell. > The directives themselves are identified using a lookahead of one, not > unbounded Yes, you're right, my terminology wasn't correct there. Either way the point is this works this way regardless of how you parse this example, so I don't think it matters WRT whether this example should be strong or not. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
