[Standards] Need sanity check on an example in XEP-0393: Message Styling

Sam Whited sam at samwhited.com
Sat Nov 7 15:28:16 UTC 2020



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


More information about the Standards mailing list