[MGNLWIKI-17] backslashes are messed up Created: 26/Mar/08  Updated: 16/Sep/15  Resolved: 30/Jul/08

Status: Closed
Project: Wiki Markup Renderer (closed)
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by DOCU-49 backslashes missing in regex for upda... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

The following snippet can't be rendered, at least in a {code} block, and that's fairly annoying:

find repositories/ -name workspace.xml -exec \
sed -i .bak -E -e \
's/org\.apache\.jackrabbit\.core\.query\.([A-Za-z]+)Filter\
/org\.apache\.jackrabbit\.extractor\.\1Extractor/g' {} \;



 Comments   
Comment by Magnolia International [ 26/Mar/08 ]

This is due to the EscapeFilter (which is executed first).
Any combination of a backslash followed by a character is transformed into said character's html entity (and backslashe is removed). For example if a backslash is followed by a newline, the combination of (backslash and newline) is transformed into & # 1 0 ;

Comment by Magnolia International [ 26/Mar/08 ]

And somehow the MacroFilter seems to be responsible for further encoding the - and \s inside the {code} macro ...

Comment by Magnolia International [ 30/Jul/08 ]

It actually seems the only use case for the EscapeFilter would be to be able to print out {{

{foo}

}} litterally, without having the engine looking for a macro. If there's nothing else, it should be rewritten, and can be simplified.

Comment by Magnolia International [ 30/Jul/08 ]

Replaced radeox's EscapeFilter by a custom SimpleEscapeFilter which just does its job and is well tested.

The original one was encoding the & character though, maybe we'll need to reimplement that. (ignored it for now as it had some nasty side effects)

Comment by Michael Mühlebach [ 16/Sep/15 ]

This ticket was closed because former resolved tickets are deemed to be closed now. If this assumption is untrue in this particular case please feel free to reopen the ticket again.

Generated at Mon Feb 12 11:14:23 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.