Parser te gretig met shortclose in mono/code/pre/spoiler/cmd

[Wiethoofd]

PHP:

/* hoort zonder \ voor de shortclose */
function foo($bar) {
    return $bar.'\[/]';
}

Random functie met een shortclose er in breekt het code-blok, haal de \ weg en vanaf daar wordt de rest plain text. Ongeacht single/double quotes er omheen wordt de voluit geschreven [/code] tag niet meegenomen.

Reproduceerbaar met de mono, pre, spoiler en cmd en vast allerlei andere tags.

PHP:

function foo($bar) {
    return $bar.'

';
}[/code]

function foo($bar) {
return $bar.'';
}[/mono]

function foo($bar) {
	return $bar.'

';
}[/cmd]

spoiler:

function foo($bar) {
return $bar.'

';
}[/spoiler]

function foo($bar) {
	return $bar.'

';
}[/pre]

[crisp]

Dus feitelijk zeg je dat de parser meer waarde moet hechten aan een full-close tag dan aan een short-close tag?

Ik hoef je hopelijk niet uit te leggen dat dat niet bepaald triviaal is. De parser probeert zo snel mogelijk een tree op te bouwen en dan wil je niet halverwege die fase weer gedeeltelijk opnieuw moeten beginnen omdat een stray end tag mogelijk toch bedoelt was als de èchte end tag, en die eerder geparsede [/] misschien toch niet bedoelt was als end tag...

In andere woorden: de situatie die je schetst is op z'n minst ambigueus, en dan kies ik liever voor de simpelere en snellere oplossing.

[Wiethoofd]

Maar kijken naar de gebruikte tag en als er een shortclose tussen quotes gevonden wordt deze negeren moet toch kunnen?

Het waarde hechten aan een full close zou triviaal zijn als je alleen correct genestte tags zou parsen (van buiten naar binnen werken).

Jammer dat tussen [code] tags een [norml] niet geparsed wordt, al staat alle UBB er nu wel correct.

PHP:

function foo($bar) {
 return $bar.'[norml][/][/norml]';
}

[crisp]

Wiethoofd schreef op dinsdag 19 juni 2012 @ 10:43:
Maar kijken naar de gebruikte tag en als er een shortclose tussen quotes gevonden wordt deze negeren moet toch kunnen?

Dus feitelijk een tweede mechanisme om tags te kunnen escapen? Lijkt me nogal overdreven, en bovendien maakt het de 'taal' weer minder overzichtelijk.

Het waarde hechten aan een full close zou triviaal zijn als je alleen correct genestte tags zou parsen (van buiten naar binnen werken).

Dat is dus niet triviaal. Op het moment dat de parser bezig is met een [code]-tag parsen en hij komt een [/] tegen dan kan hij niet anders dan op dat moment aannemen dat dat de close tag is voor de eerder geziene [code]-tag. Als hij dan later toch weer een [/code] tegenkomt dan negeert hij deze want de [code]-tag was al afgesloten.

Als je wilt dat deze dan toch verwerkt wordt dan moet de parser dus gaan kijken of er daarvoor geen andere tags verwerkt zijn (de laatste node in de tree moet dus de eerder afgelosten [code]-tag zijn), vervolgens moet hij terugrollen naar het punt waarop hij de [/]-tag geparsed heeft, deze als 'literal' beschouwen en vervolgens opnieuw gaan parsen. Dat is iets dat je in een parser zo min mogelijk wilt doen (back tracking).

Jammer dat tussen [code] tags een [norml] niet geparsed wordt, al staat alle UBB er nu wel correct.

PHP:

function foo($bar) {
 return $bar.'[norml][/][/norml]';
}

Da's natuurlijk ook by design; een [code]-blok parsed geen enkele tag behalve een close-tag voor het blok zelf. In het begin hadden we het zo gedaan dat [code] niet met een short-close tag kon worden afgesloten, maar dat wekte ook weer verwarring bij gebruikers.

[BtM909]

crisp, is het wellicht wel mogelijk:

PHP:

/* hoort zonder \ voor de shortclose */
function foo($bar) {
    return $bar.'\[/]';
}

die [/] wel te escapen (in 't code-blok) zodat die backslash niet zichtbaar is?

[ Voor 4% gewijzigd door BtM909 op 19-06-2012 14:44 ]

[crisp]

BtM909 schreef op dinsdag 19 juni 2012 @ 14:43:
crisp, is het wellicht wel mogelijk:

PHP:

/* hoort zonder \ voor de shortclose */
function foo($bar) {
    return $bar.'\[/]';
}

die [/] wel te escapen (in 't code-blok) zodat die backslash niet zichtbaar is?

Maar als ik die \ nu letterlijk bedoel; da's niet heel erg far-fetched natuurlijk:

PHP:

$a = '[' + '/]';
preg_match('~\[/]~', $a, $m);
var_dump($m);

(test maar eens met of zonder \)

[BtM909]

crisp schreef op dinsdag 19 juni 2012 @ 15:44:
[...]

Maar als ik die \ nu letterlijk bedoel; da's niet heel erg far-fetched natuurlijk:

PHP:

$a = '[' + '/]';
preg_match('~\[/]~', $a, $m);
var_dump($m);

(test maar eens met of zonder \)

Ik heb niks gezegd

[Dirk]

In zo'n geval zou je toch de backslash zelf ook moeten escapen? Dus \\\[/] moeten schrijven om \[/] te krijgen?

[crisp]

Dirk schreef op dinsdag 19 juni 2012 @ 19:26:
In zo'n geval zou je toch de backslash zelf ook moeten escapen? Dus \\\[/] moeten schrijven om \[/] te krijgen?

Mja, dan maak je het eigenlijk alleen maar nodeloos ingewikkeld... Ik zie dan nog meer in een tag waarmee je de shortclose tag kan 'uitschakelen'; da's veel makkelijker te implementeren dan hetgeen hier nu wordt voorgesteld...

[Dirk]

Maar in een normale tekst escape je \ ook al met \\, of ligt dat met code-tags nog een stuk complexer?

[crisp]

Dirk schreef op dinsdag 19 juni 2012 @ 21:10:
Maar in een normale tekst escape je \ ook al met \\, of ligt dat met code-tags nog een stuk complexer?

Dat durf ik zo niet te zeggen; dan moet ik de parsercode voor induiken

[BtM909]

test [/] test

test \ test [/]

Ja dus althans dat is het escapen van een backslash voor een tag

[ Voor 35% gewijzigd door BtM909 op 20-06-2012 00:30 ]

[crisp]

Ik heb nog even gekeken en het lijkt er op dat het door een config-wijziging te fixen is.

Ik heb ook nog even gechecked met de frontpage parser (die o.a. voor tweakblogs wordt gebruikt en daar ook [code]-tags ondersteund), en daar werkt het al zo dat tag-escaping binnen [code]-tags gewoon werkt (omdat het in die parser ingebakken zit in de syntax en niet later als 'feature' is toegevoegd).

Uiteraard zou ik eea eerst nog goed moeten testen, maar ik voel er wel voor om dit in de forum-parser aan te passen - temeer omdat dat het gedrag tussen de FP-parser en forum-parser meer consistent maakt

[Vaan Banaan]

*BUMP*
Er wordt hier gespoken over shortclose, maar ik kom het met normale close ook tegen
[Bold], 1 backslash, spatie, [close bold]: \ OK
[Bold], 2 backslashes, spatie, [close bold]: \\ OK
[Bold], 1 backslash, [close bold]: [b][/b] parser doet ogen dicht en vingers in de oren?
[Bold], 2 backslashes, [close bold]: \ nom nom nom, backslash unescapen, nom nom nom
[Bold], 3 backslashes, [close bold]: [b]\[/b] combi van bovenstaande 2 tests

[crisp]

Uhm, wat gaat er dan fout volgens jou?

[BtM909]

offtopic:
grrrr crisp

Je maakt het wel heel ingewikkeld

Dit is wat je aantoont

[b]\ [/b] → \
[b]\\ [/b] → \\
[b]\[/b] → [b][/b]
[b]\[/b] → \
[b]\\[/b] → [b]\[/b]

Waarom kloppen de laatste drie niet volgens jou?

[Vaan Banaan]

Ik wordt er van, want als ik de backslashes tussen de UBB codes vervang door slashes is het resultaat anders.
[b]/ [/b] → /
[b]// [/b] → //
[b]/[/b] → /
[b]//[/b] → //
[b]///[/b] → ///

[Wiethoofd]

De \ kun je namelijk gebruiken om een ubb-tag (of een nieuwe \ ) te escapen, is wat simpeler en korter dan [norml][/norml] om je tag heen te moeten typen om hem te laten zien in je voorbeeld

[Vaan Banaan]

Agreed, kan dat dan ook bij Overzicht van UBB-codes gezet worden?
Ik ken het nu helegaar nie vinden, er wordt alleen over het escapen van quotes geschreven.
...Om een letterlijke quote op te nemen in een attribuut-waarde kan je deze escapen met behulp van een backward slash....
[abbr="Anders moet je \"escapen\""] bla [/abbr]
^{Ik moet inderdaad toegeven dat het erg handig is, met een gekopieerd stukje tekst zoals hierboven}

[crisp]

Staat toch in de faq: Overzicht van UBB-codes #escaping

[Vaan Banaan]

* Vaan Banaan gaat in een hoekje staan en zich schamen

[ Voor 15% gewijzigd door Vaan Banaan op 26-07-2012 01:51 ]