[bug/rml] [/] posten

[Mentalist]

Vaagheidje waar ik tegenaan liep .

Probeer het volgende : post "[/]" dikgedrukt (zonder html ja ).

Nee, probeer maar niet, lukt je niet . Als je het tussen norml tags zet sluit je namelijk direct de norml tag weer af.. Niet handig. "[/]" als afsluiting voor norml uitschakelen zou het moeten fixen denk ik

[ Voor 195% gewijzigd door Mentalist op 17-03-2005 23:27 ]

[Remy]

Wat W3ird_N3rd probeert te vertellen is dit:

<W3ird_N3rd> en als je dan wil uitleggen aan een user dat je [img]blabla[/img] kan gebruiken om een plaatje te posten?
<W3ird_N3rd> *[img]blabla[/]
<W3ird_N3rd> dan zeg je : "dan type je dit : [img]blabla[/]
<W3ird_N3rd> en dat gaat dan dus de mist in
[Remy] gewoon zeggen: [/] moet niet gelden voor [norml] en voor [code]
[Remy] dan kan chem er wat mee

[Mentalist]

En dan blijkt het voorbeeld nog te werken ook.. Maar op voorwaarde dat er een tag in je code tussen de norml tags staat. Vage shit.

[img]blabla![/]

blabla[/]

Bij het 2de voorbeeld zie je dus "[/norml]" staan, dat was het probleem. Raar dat ie dus tot op zekere hoogte toch zit te parsen tussen norml tags.. Althans.. Hij ziet bij de eerste dus dat er wel een andere tag voor de [./.] staat en parsed [./.] dan niet als afsluiting voor norml.

Vage shit.

[Superdeboer]

W3ird_N3rd schreef op donderdag 17 maart 2005 @ 21:24:
Bij het 2de voorbeeld zie je dus "[/norml]" staan, dat was het probleem. Raar dat ie dus tot op zekere hoogte toch zit te parsen tussen norml tags.. Althans.. Hij ziet bij de eerste dus dat er wel een andere tag voor de [./.] staat en parsed [./.] dan niet als afsluiting voor norml.

Dat komt omdat er in het eerste voorbeeld sprake is van een correcte nesting van toegestane tags, in het tweede voorbeeld is er eigenlijk niet eens nesting... en dus wordt norml al afgesloten voordat de parser bij [/norml] aankomt.

Eigenlijk ben ik er niet zo'n groot voorstander van wanneer [/] niet meer als afsluiting voor bepaalde tags geaccepteerd wordt. Problemen met nesting moeten door een user zelf voorkomen worden IMO. En anderzijds komt het vaker voor dat iemand 'gewoon' een norml- of code-tag af wil sluiten met [/], dan dat de situatie ontstaat die jij hierboven in het tweede voorbeeld schetst.

En wees eerlijk, hoe vaak komt het voor dat [/] tussen norml-tags in komt te staan, zónder een bijbehorende openingstag? Als er geen openingstag bij gevonden kan worden, dan hoef je [/] niet eens tussen norml-tags te zetten, want dan wordt-ie toch niet geparst.

[Mentalist]

Superdeboer schreef op donderdag 17 maart 2005 @ 21:33:
Eigenlijk ben ik er niet zo'n groot voorstander van wanneer [ RÂÂÂÂH, dat sloot de quote-tag ook al af /] niet meer als afsluiting voor bepaalde tags geaccepteerd wordt. Problemen met nesting moeten door een user zelf voorkomen worden IMO. En anderzijds komt het vaker voor dat iemand 'gewoon' een norml- of code-tag af wil sluiten met [ Damnit, hier ook al! /], dan dat de situatie ontstaat die jij hierboven in het tweede voorbeeld schetst.

Persoonlijk ben ik van die hele [./.] geen voorstander, wat is er mis met netjes code afsluiten? Tja, meer werk, maar ik gebruik [./.] dus zelf nooit

Zie ook de rant in de quote die ik er net bij heb gezet

En wees eerlijk, hoe vaak komt het voor dat [ BLAAAT /] tussen norml-tags in komt te staan, zónder een bijbehorende openingstag? Als er geen openingstag bij gevonden kan worden, dan hoef je [ Wiehehieieie! /] niet eens tussen norml-tags te zetten, want dan wordt-ie toch niet geparst.

Hoevaak het voorkomt? Niet veel blijkbaar, maar iets voor ik dit topic opende liep ik ertegenaan hiermee :

edit:
Damn Koffie, die [./.] sloot de quote-tag af

Hier sloot [ / ] dus de norml-tag af. En zonder norml sluit ie de edit-tag af. Maargoed, het boeit dus eigenlijk ook niet, komt verder eigenlijk toch nooit voor..

[ Voor 11% gewijzigd door Mentalist op 17-03-2005 21:46 ]

[Rataplan]

* Rataplan wijst op [ en ].

That is: &#91; en &#93;

[ Voor 15% gewijzigd door Rataplan op 17-03-2005 21:47 . Reden: valt nog niet mee, om dat React voor de gek te houden :) ]

[Superdeboer]

^^ Nah... dit is dan toch wel een vies side-effect...

Als ik dus gewoon [/] (ja nu effe met HTML... ) post in een post, dan beëindigt dat ook de quote-tag wanneer ik door een ander gequote wordt...

But then again... hoe vaak zou dat voorkomen? Ik denk nog steeds, minder vaak dan dat ik gewoon tags af wil sluiten met [/] zónder dat daar rare dingen in staan.

[Mentalist]

En zoals je net zag, het gaat dus eigenlijk alleen mis met topics als deze, als je over [./.] als afsluiting wil praten.. Maar als je norml niet meer af zou kunnen sluiten met [./.] zou je ook dat probleem niet hebben omdat je die losse [./.] dan tussen norml-tags kan zetten. Maar het komt dus idd bijna niet voor. Maar als 't voorkomt is het op zich wel irritant.

Rataplan schreef op donderdag 17 maart 2005 @ 21:46:
* Rataplan wijst op [ en ].

That is: &#91; en &#93;

Hmm, ja, dat is wel een mogelijke "oplossing". Het komt op mij meer over als een workaround, maar het werkt idd wel.

[Rataplan]

W3ird_N3rd schreef op donderdag 17 maart 2005 @ 21:50:
Hmm, ja, dat is wel een mogelijke "oplossing". Het komt op mij meer over als een workaround, maar het werkt idd wel.

Feit is dat je een feature hebt (de [/]) die in zeldzame gevallen (het bespreken van tags, fouten in de rml van een post) een ongewenst bij-effect heeft. Je kan het oplossen door norml en code voortaan "volledig" af te laten sluiten; maar dat is ook een workaround (want ook dan vraag je extra inzet/voorkennis van users). Ik vermoed overigens dat heel wat posts dan niet meer correct geparsed worden, en dat vind ik nog een stuk erger. Ik zeg dus: lekker laten zoals het is.

[Superdeboer]

Dat ben ik met je eens * Rataplan . Als je dat bijvoorbeeld uit zou zetten dan zou de RML-FAQ een stuk onduidelijker worden... want hoe leg je dat nou uit: dit trucje werkt hier wel... maaaaar hier niet, want dat is een beetje lastig als je het over [/] als afsluiting wilt gaan hebben.

Ik denk ook dat je beter naar een workaround kunt zoeken in het zeldzamere geval wat * Superdeboer nu tegenkwam, dan heel veel mensen dwingen om in heel veel gevallen naar workarounds te grijpen.

[Mentalist]

Vroeger was alles beter, toen moesten we tags nog gewoon netjes afsluiten

Maargoed, zo geschiedde het, [/] bestaat en aanpassingen daaraan zullen teveel gevolgen hebben. Dat begrijp ik.

Delete topic dan maar?

[moto-moi]

ehmm..
[norml] betekend NIET parsen die rml tags die ik ertussen paste.

En als 'ie dat dus /wel/ gaat doen, ookal is de [/] een shortcut, tsja, da's toch echt een bug hoor

[crisp]

Dit dus: [norml][img]...[/][/norml] ?

Hoe moet de parser nou weten dat de [/] bij de [img] hoorde en niet bij de [norml]?
Ja, als hij vervolgens ná de [/] alsnog een [/norml] tegenkomt zou hij kunnen denken "wacht even, misschien hoorde die [/] wel niet op de stack, even teruggaan en corrigeren" - maar dan krijg je dus wel een veel complexere en dus ook tragere parser...

Rule of thumb: als je gaat nesten gebruik dan full-closing-tags om ambiguiteiten te voorkomen. De parser is dom (one-way zonder backtrack) om maar 1 reden: snelheid.

[ Voor 26% gewijzigd door crisp op 17-03-2005 23:04 ]

[moto-moi]

crisp schreef op donderdag 17 maart 2005 @ 22:56:
Dit dus: [norml][img]...[/][/norml] ?
Hoe moet de parser nou weten dat de [/] bij de [img] hoorde en niet bij de [norml]?
Ja, als hij vervolgens ná de [/] alsnog een [/norml] tegenkomt zou hij kunnen denken "wacht even, misschien hoorde die [/] wel niet op de stack, even teruggaan en corrigeren" - maar dan krijg je dus wel een veel complexere en dus ook tragere parser...

Nou, volgens mij zat exact dezelfde bug in de code rml, en die is gefixed
Dus zoveel werk zal het niet zijn om het gewenste gedrag ook in [/] te implementeren

[G33rt]

Waarom maak je dan - zoals Remy al zegt - geen uitzondering voor [code] en [norml]? Als je de parser 'leert' dat die tags echt full moeten worden afgesloten zal een verdwaalde slash ertussen niets doen

[Harm]

crisp schreef op donderdag 17 maart 2005 @ 22:56:
Dit dus: [norml][img]...[/][/norml] ?

Hoe moet de parser nou weten dat de [/] bij de [img] hoorde en niet bij de [norml]?

De parser sluit toch de laatstgeopende tag als eerste af? IMHO is dan dus logisch dat de [img] wordt afgesloten door [/] en niet eerst de [norml]. De parser werkt toch op basis van last in first out? Of mis ik nu iets?

[crisp]

Harm schreef op donderdag 17 maart 2005 @ 23:09:
[...]
De parser sluit toch de laatstgeopende tag als eerste af? IMHO is dan dus logisch dat de [img]wordt afgesloten door[/] en niet eerst de [norml]. De parser werkt toch op basis van last in first out? Of mis ik nu iets?

Juist door de norml-tag wordt de img-tag geignored (dus niet op de stack gezet)

Maar inderdaad: afdwingen om bepaalde tags volledig af te sluiten kan dit probleem oplossen, maar dat moet dan wel in de FAQ duidelijk vermeld staan.

[Superdeboer]

crisp schreef op donderdag 17 maart 2005 @ 23:13:
Maar inderdaad: afdwingen om bepaalde tags volledig af te sluiten kan dit probleem oplossen, maar dat moet dan wel in de FAQ duidelijk vermeld staan.

En hoe gaat dat dan uitwerken wanneer oude berichten geherparst worden door het ophogen van de RML-versie?

[crisp]

Superdeboer schreef op vrijdag 18 maart 2005 @ 00:00:
[...]

En hoe gaat dat dan uitwerken wanneer oude berichten geherparst worden door het ophogen van de RML-versie?

Die gaan dan stuque

[Mentalist]

moto-moi schreef op donderdag 17 maart 2005 @ 23:05:
[...]

Nou, volgens mij zat exact dezelfde bug in de code rml, en die is gefixed

Vergissing van mij, ik was in de war gebracht omdat het wel werkt als er nog een openingstag aanwezig is..

_{[norml][img][/][/norml]}

[img][/]

_{[norml][/][/norml]}

[/]

_{[code][img][/][/code]}

code:

[img][/]

_{[code][/][/code]}

code:

[/code]

Code en norml doen dus gewoon hetzelfde.. Dat zal het sowieso een stuk moeilijker maken..

[crisp]

code en norml moeten af 1.9.4 met een volledige tag afgesloten gaan worden om dergelijke ambiguiteiten te voorkomen