"No\n\nhttps:" is in the json, but was ignored, but you could also have \n within an option, and then the following options would be ignored.
Something more explicit, like a "|" is much simpler, and that matches the EOS for Markdown tables, which people are used it.
And means you can place the call anywhere in a note, which is more user-friendly.
the simplest parsing would be
\nPOLL: text | option | option\n
parser can then just scan for the sentinel and then end at the newline. it can go anywhere in the text it just has to have the sentinel directly after a newline
actually, probably \n@botnamepubkey question | option | option | option\n would make more sense
think of how easy a line structured parse goes: split all lines, iterate looking for the sentinel, split by | and first segment split by space
anyway, y'alls used to your retarded favorite language which isn't Wirth type that doesn't use line structure and sentinels, whatever. you don't write parsers. that's how i know you don't know how to write a parser. you like braces and parentheses and pointless redundant delimiters like semicolons
I have written all of Alexandria's parsers by hand.
We cannot dictate what the content fields contain or how whitespace is written, so going by whitespace characters is a nightmare, as the users have no idea what their client will do with them, when they publish, and they can't see them and confirm correctness, themselves.
Just try making a bulleted list. Many clients collapse it down to one line.
You don't have to put me down and talk to me like I'm an idiot, merely because I disagree with you.
yeah, goddamn vibe coded clients
i'm glad you do write parsers
i'll agree with what you are saying since the only thing you can trust the clients to do is not screw up the spaces and punctuation, and usually they will put a correct nostr:entity
