[bug] spaties na [code] tag

[Maasluip]

Als je na een [code] tag een aantal spaties zet, worden die spaties bij het weergeven van het bericht weggefilterd. Maar in de code staan ze nog wel.
Staan de spaties aan het begin van de regel maar niet na een [code] tag, dan worden ze wel weergegeven

Zie hier:

code:

          10 spaties na een code tag
          10 spaties na een newline

Oh ja, en is er een mogelijkheid om [code] te escapen binnen een [code] blok? Ik heb geen mogelijkheid gevonden om dat te maken. Zie hieronder:
[code] Ik wil

code:

 schrijven

[crisp]

Ik heb lokaal de trimming aangepast van 'both' naar 'outer'

Oh ja, en is er een mogelijkheid om [code] te escapen binnen een [code] blok? Ik heb geen mogelijkheid gevonden om dat te maken.

Daar is niet echt een mogelijkheid voor, maar ik sta open voor suggesties

[Dirk]

In

code:

 \[code]

Het escape character gewoon niet weergeven?

[Maasluip]

crisp schreef op dinsdag 14 oktober 2008 @ 10:28:
Ik heb lokaal de trimming aangepast van 'both' naar 'outer'

Jij begrijpt natuurlijk wel wat je zelf zegt?

[...]

Daar is niet echt een mogelijkheid voor, maar ik sta open voor suggesties

Met /me DirkW. Of in de parsing de voorste tag als begintag zien en de rest negeren (wat toch al gebeurt als je geen endtag zet)

[crisp]

Dirk schreef op dinsdag 14 oktober 2008 @ 10:56:
In

code:

 \[code]

Het escape character gewoon niet weergeven?

Dat is niet handig aangezien de letterlijke sequence \\[ veel voorkomt in code (reguliere expressies), dus tag-escaping aanzetten binnen [code] is geen optie. Je moet eigenlijk iets hebben waardoor de tokeniser het niet als een tag herkent en we het binnen de [code]-tag parsefunctie kunnen rechtbreien; denk aan iets als:

code:

[~code]

of misschien nog ietsje exotischer om false positives te voorkomen...

[crisp]

Maasluip schreef op dinsdag 14 oktober 2008 @ 11:03:
[...]

Jij begrijpt natuurlijk wel wat je zelf zegt?

I hope so

[...]
Met /me DirkW. Of in de parsing de voorste tag als begintag zien en de rest negeren (wat toch al gebeurt als je geen endtag zet)

Nee, tag-matching rules aanpassen levert alleen weer andere combo's op waar het dan weer 'fout' gaat. Feit is dat het ambigu is dus je moet die ambiguiteit oplossen dmv syntax, geen algorithmes aanpassen (wat ueberhaupt geen sinecure is).

[.oisyn]

crisp schreef op dinsdag 14 oktober 2008 @ 10:28:
Ik heb lokaal de trimming aangepast van 'both' naar 'outer'

Had je dat niet eerder al eens gedaan? [bug] code-tag lijnt eerste regel niet uit

crisp schreef op dinsdag 14 oktober 2008 @ 11:09:

code:

[~Verwijderd]

of misschien nog ietsje exotischer om false positives te voorkomen...

~ is extreem onhandig, dat is een unary operator in heel veel talen, wat iets als @Verwijderd dus valid maakt Maar kun je [norml] daar niet gewoon hergebruiken?

code:

... \[norml]\[code][/norml] ...

Momenteel werkt dat niet, maar wellicht wel met wat aanpassingen. En als je dan [norml] wilt schrijven dan kan dat gewoon zonder eind-tag. En als je evt. verderop nog een [/] gebruikt, dan moet je maar iets als \[no[norml]rml[/]] in elkaar frutselen

[moto-moi]

volgens mij gaat het ook niet werken als je een parser wilt laten zien, want dan gaat het weer fout bij [norml] enzo

Wat we wel zouden kunnen doen is het encoden van de opening of sluittag bij norml, dan merkt de parser de tag niet op gok ik

[.oisyn]

moto-moi schreef op donderdag 16 oktober 2008 @ 08:47:
volgens mij gaat het ook niet werken als je een parser wilt laten zien, want dan gaat het weer fout bij [norml] enzo

Nee hoor, dat zei ik dus in de laatset alinea.

[code] [norml] [code] kan norml laten zien
[code] [no[norml]rml[/]] .. [/norml] [/code] kan [norml] .. [/norml] laten zien.
......................^^^^ hier wordt een tag opgebroken door er een geldige tag tussen te zetten zodat hij niet wordt herkend

Mooi is anders bij die laatste, maar het kán wel en het lijkt me duidelijk dat norml een uitzondering is.

[ Voor 12% gewijzigd door .oisyn op 16-10-2008 10:41 ]