[rml] escaped tag wordt niet als tag behandeld

[crisp]

code:

\[quote="[b]hoi[/b]"]hoi\[/quote]

geeft:
[quote="[b]hoi[/b]"]hoi[/quote]

kortom: de tag wordt als gewone text behandeld en niet als tag die vervolgens ongeparsed wordt weergegeven.

En de ~ heeft een geheime verdubbelaar:

code:

~~~[drie keer een ~ teken]

[ACM]

De eerste lijkt me correct?

code:

"[b]hoi[/b]"

wordt toch ook "hoi"?
Waarom zou een eventuele escaped [ ergens ervoor ineens een andere betekenis geven aan een stuk tekst erna? Imho escape je niet de tag, maar de [ zodat het niet als tagstart gezien wordt. Dus elke tag binnen zo'n stuk code moet je apart escapen, of natuurlijk gewoon met norml-omsluiten
Want wat moet je dan met:

code:

\[ en verder tikken, waarna ik hier "[b]bold[/b]" wil en hier loos een ]

Of deze:

code:

\[quote][b][message=27521814,noline]crisp schreef op zaterdag 17 februari 2007 @ 23:15[/message]:[/b]
[code]\[quote="[b]hoi[/b]"]hoi\[/quote][/code]
geeft:
\[quote="[b]hoi[/b]"]hoi\[/quote]

kortom: de tag wordt als gewone text behandeld en niet als tag die vervolgens ongeparsed wordt weergegeven.

En de ~ heeft een geheime verdubbelaar:
[code]~~~~~~[drie keer een ~ teken][/code]

;)
\[/quote]

Wat moet dat dan doen?

En ook nog een html-voorbeeld om te illustreren wat de \\[ eigenlijk betekent, ruwweg hetzelfde als < natuurlijk:

HTML:

&lt;a href="<b>bla</b>"&gt;

En moet dus uiteindelijk dit worden:
<a href="bla">

Of moet dat volgens jou dit worden:
<a href="<b>bla</b>">

[ Voor 71% gewijzigd door ACM op 18-02-2007 11:20 ]

[crisp]

ACM schreef op zondag 18 februari 2007 @ 11:09:
[...]
Waarom zou een eventuele escaped [ ergens ervoor ineens een andere betekenis geven aan een stuk tekst erna? Imho escape je niet de tag, maar de [ zodat het niet als tagstart gezien wordt. Dus elke tag binnen zo'n stuk code moet je apart escapen, of natuurlijk gewoon met norml-omsluiten

uhm, het heet tag-escaping, niet character-escaping.

Want wat moet je dan met:

code:

\[ en verder tikken, waarna ik hier "[b]bold[/b]" wil en hier loos een ]

Dat zal door de tokeniser niet als tag gezien worden, wellicht wel als je die spatie na de [ weglaat tenzij de tokeniser ook checked op tagname (wat meestal niet het geval is - dat is een taak van de parser).

[...]
En ook nog een html-voorbeeld om te illustreren wat de \\[ eigenlijk betekent, ruwweg hetzelfde als &lt; natuurlijk:

uhm, nee. Je HTML-voorbeeld is duidelijk een geval van character-escaping. Dat hebben we in RML ook: je kan daar immers ook een entity gebruiken ipv de [.
Verder staat HTML geen unencoded < en > toe binnen een attribute-value itt RML die wel [ en ] toestaat binnen een quoted attribute-value.

[crisp]

Een ander voorbeeld dan want dit geldt immers ook voor denied tags: stel een gebruiker heeft geen rechten voor de [quote]-tag en post toch dit:

code:

[quote="[b]hoi[/b]"]hoi[/quote]

wat verwacht je dan als output?

[moto-moi]

Volgens mij ben je een beetje aan het doordraven crisp
Verder, dat rml niet vergelijkbaar was met html wisten we toch al een tijdje?
En om heel eerlijk te zijn kan ik me niet voorstellen dat dit gedrag (fout of niet) veel problemen opgeleverd heeft tot nu toe, dus om het nu te veranderen lijkt me een zonde van de tijd van Parse of jou?

[crisp]

True, het zijn edge-cases, maar ik vraag me enerszijds gewoon af wat de juiste behavior zou moeten zijn

[moto-moi]

Default behavior hoort gewoon te zijn zoals jij het schets, maar ik kan me voorstellen dat kwa performance er is gekozen voor de huidige manier van parsen

[AtleX]

crisp schreef op zaterdag 17 februari 2007 @ 23:15:
En de ~ heeft een geheime verdubbelaar:

code:

~~~~~~[drie keer een ~ teken]

Was al bekend bij je: [bug]Onderstreepte tilde wordt dubbele tilde in quote

[ACM]

crisp schreef op zondag 18 februari 2007 @ 15:00:
uhm, het heet tag-escaping, niet character-escaping.

Mwoh, ik denk dat jij de naamgeving binnen de rml-parser wat verder doortrekt dan je aan de hand van de code al kan zien dat de functionaliteit is.

uhm, nee. Je HTML-voorbeeld is duidelijk een geval van character-escaping.

Uiteraard, want ik vind character escaping veel logischer. Sterker nog, ik ging er van uit dat het gebeuren in React dat ook is, dus vandaar dat ik dat als equivalent beschouwde.

Dat hebben we in RML ook: je kan daar immers ook een entity gebruiken ipv de [.

Je bedoelt een html-entity? Daar staat RML los van he? Dat het uiteindelijk toevallig een speciale betekenis heeft in de uiteindelijke html is eigenlijk niet relevant voor RML. Het gaat er om wat voor bijzondere dingen de RML-parser met de tekst doet. En er is vziw geen speciale RML-tag/code om een [ weer te geven, behalve dan dat ie hem in de meeste gevallen niet als tag-starter ziet en dus gewoon toont en dat je evt een \ er voor mag zetten om te voorkomen dat ie een speciale functie toebedacht zou kunnen krijgen door eventuele tekens er direct na.

[crisp]

ACM schreef op zondag 18 februari 2007 @ 16:25:
[...]

Mwoh, ik denk dat jij de naamgeving binnen de rml-parser wat verder doortrekt dan je aan de hand van de code al kan zien dat de functionaliteit is.

[...]

Uiteraard, want ik vind character escaping veel logischer. Sterker nog, ik ging er van uit dat het gebeuren in React dat ook is, dus vandaar dat ik dat als equivalent beschouwde.

Voor 'tag-escaping' zou je dat inderdaad zo kunnen beargumenteren, voor de interne 'tag-denying' gaat het imo echter niet meer op. Toch is dat op dezelfde manier geimplementeerd wat imo incorrect is.

[...]

Je bedoelt een html-entity? Daar staat RML los van he? Dat het uiteindelijk toevallig een speciale betekenis heeft in de uiteindelijke html is eigenlijk niet relevant voor RML. Het gaat er om wat voor bijzondere dingen de RML-parser met de tekst doet. En er is vziw geen speciale RML-tag/code om een [ weer te geven, behalve dan dat ie hem in de meeste gevallen niet als tag-starter ziet en dus gewoon toont en dat je evt een \ er voor mag zetten om te voorkomen dat ie een speciale functie toebedacht zou kunnen krijgen door eventuele tekens er direct na.

Het is in zoverre relevant dat een entity in RML niet als tag-delimiter wordt gezien, dus bereik je daarmee ongeveer hetzelfde. In die zin is dat wel equivalent aan &lt; in HTML.

moto-moi schreef op zondag 18 februari 2007 @ 15:50:
Default behavior hoort gewoon te zijn zoals jij het schets, maar ik kan me voorstellen dat kwa performance er is gekozen voor de huidige manier van parsen

Qua performance maakt het weinig uit of je escaped tags als tags parsed en een 'escaped'-flag meegeeft voor de parser of dat je het door de tokeniser meteen als text-token laat uitspugen.