[bug] Geneste tag niet goed geparsed

[Lustucru]

Lui als ik ben, tikte ik voorheen iets als:
[ot] Lees eens onze [faq=registerfaq] asjeblief [/]
ipv
[ot] Lees eens onze [faq=registerfaq] asjeblief [/ot]

en dat parst ie zó:

[ot] Lees eens onze asjeblief

ipv

offtopic:
Lees eens onze Registratievoorwaarden / korte FAQ asjeblief

Waar dat ie nu die onderstreping vandaan haalt?

[MsG]

Is dat niet standaard bij een link?

[crisp]

Da's geen bug an sich aangezien de [faq]-tag ook als singleton gebruikt mag worden (dat wil zeggen: zonder endtag, de parser haalt dan zelf de faq-titel op en zet er [/faq] achter).
Wat er echter gebeurd is dat de parser de [/] ziet als endtag voor [faq] en dan blijft [ot] over zonder endtag, en die is niet optioneel

[ Voor 11% gewijzigd door crisp op 18-01-2008 00:30 ]

[Lustucru]

MsG schreef op vrijdag 18 januari 2008 @ 00:27:
Is dat niet standaard bij een link?

Lange en vermoeiende dag achter de rug

crisp schreef op vrijdag 18 januari 2008 @ 00:29:

Dat snap ik en had ik eigenlijk zelf ook wél moeten kunnen verzinnen, maar vergis ik me nu dat hij voorheen die singletons wel goed parste als ze genest waren?

[ Voor 24% gewijzigd door Lustucru op 18-01-2008 01:09 ]

[DizzyWeb]

Lijkt me sterk, de parser kan moeilijk weten waar die end tag bij hoort. De meest logische keuse is de laatst geopende tag en dais de faq tag. Of vergis ik me nu?

[crisp]

DizzyWeb schreef op vrijdag 18 januari 2008 @ 01:10:
Lijkt me sterk, de parser kan moeilijk weten waar die end tag bij hoort. De meest logische keuse is de laatst geopende tag en dais de faq tag. Of vergis ik me nu?

Het is ambigu. In eerste instantie zal de parser bij het tegenkomen van de [/] een aanname moeten maken over [faq] - is die bedoelt als singleton of als starttag en wordt hij nu afgesloten?
Uiteindelijk zit je dan nog wel met een unmatched [ot] opentag; op basis daarvan zou een parser kunnen besluiten om dan toch maar een andere aanname te maken mbt die mogelijke singleton, maar dat betekent dat je dan vanaf de [ot]-tag weer helemaal opnieuw een tree moet gaan opbouwen.

Op het moment dat het niet om een enkele mogelijke singleton gaat maar om meerdere, en dan ook nog eens in een dieper geneste tree, dan heb je al gauw een n! probleem en is de parser uiteindelijk uren bezig om een tree te vinden waarbij zoveel mogelijk tags toch gematched kunnen worden

[Verwijderd]

Of je laat de parser eerst de singletons fixen voordat je de tree gaat opbouwen.

[TheZeroorez]

De [faq=x] wordt afaik vrijwel altijd als singleton gebruikt ja, omdat de parser er 'dan wel' een goede tag van maakt, je hoeft immers alleen maar de locaties in te tikken als je 'm singleton gebruikt, en die titel wordt exact overgenomen (net als bij message-links, topic-links en ms-links ).

Dat n! probleem is alleen wel een 'klein' probleempje dan ja

[Voutloos]

Verwijderd schreef op vrijdag 18 januari 2008 @ 03:04:
Of je laat de parser eerst de singletons fixen voordat je de tree gaat opbouwen.

Crisp legt juist net uit dat het niet triviaal te vervangen is omdat de input vaak ambigu is.

[crisp]

Verwijderd schreef op vrijdag 18 januari 2008 @ 03:04:
Of je laat de parser eerst de singletons fixen voordat je de tree gaat opbouwen.

Dan nog moet de parser helderziend zijn

Kortom: not fixable. Bij dergelijke 'parser'-problemen is het devies gewoon om meer expliciet te zijn in het afsluiten van de tags die problemen geven. Onze FP parser gaat wel iets beter om met singletons en optionele end-tags (bv list-items), maar ik moet nog testen wat hij in deze situatie zou doen (ws hetzelfde als React ).