[RML] Bugje in RML-parser bij gebruik van HTML-entities

[Harm]

Ik maakte net deze post:

Zonder ­
Datgaanwedanmaareventestenalsjehetgoedvindt,wantikgeloofernogweinigvandat­­­welwerktzoalsjijzegtmaargoeddatzienwedusalsdezeregelafis.

Met ­­­
Datgaanwedanmaareventestenalsjehetgoedvindt,wantikgeloofernogweinigvanda­t­­welwerktzoalsjijzegtmaargoeddatzienwedusalsdezeregelafis.

Echter, als ik deze ga editen, dan verdwijnen de ­'s. Is dat bewust of is dat een bugje in de parser? Het is namelijk bepaald onhandig dat dit gebeurt IMHO. Waarschijnlijk is dit bewust, een ë wordt namelijk correct omgezet naar ë door de parser, maar dat gaat dus mis bij dit speciale teken.

[Harm]

En omdat bij het editen van bovenstaande post, het spul dus ook allemaal verdwijnt, ga ik het ding niet editen, en plaats ik het linkje naar de bewuste post maar hier: Harm in "Afbreekstreepjes: bewust of onbewust?" (RED).

[crisp]

Een losse ­­ is geparsed eigenlijk niets, behalve als het een woord afbreekt, dus dat is consistent met de ë die je geparsed terugziet.
Maar dit is inderdaad een probleem in React, je zou terug moeten zien wat je oorspronkelijk hebt ingevoerd (dus de entity en niet de geparsede entity).
Feit is dat zolang er op message-niveau niet kan worden aangegeven of een post als HTML geparsed moet worden of niet je altijd situaties overhoud waarbij het niet duidelijk is of iets als HTML bedoelt was of niet. Het automatisch omzetten van entities maakt het zelfs nog wat lastiger.

[ Voor 9% gewijzigd door crisp op 26-05-2005 14:53 ]

[crisp]

­ heeft volgens mij niet eens een karakter-equivalent, dus dat verklaart ook eea

[ Voor 3% gewijzigd door crisp op 09-02-2006 00:08 ]