Comment 4 for bug 585300

> The problem here is that there is no way to store this in wiki text
> cleanly unless it is escaped.
>

Then escape it. Escaping _all_ user data before it goes into SQL is standard practice, why should it be any different if the wiki/text file suffers from "wiki-formatting injection" attacks as well? Escaping data before storage is _not_ a problem.

I agree that it might be nice to have an _option_ to let the user enter wiki-formatted text for formatting, but in that case the text should be converted immediately.

> This is what the "verbatim" style is for. This
> is a design limitation of the wiki syntax.
>

There is no way for the user to know that certain strings cannot be represented in certain types of formatting. Nor should there be. Is this really a design limitation, or an oversight? It can easily be fixed by escaping input.

> Letting the user enter something like //foo// and not showing
> him the result immediately is not WYSIWYG any more.

That is part of the problem, yes. The other part is that there happen to be very valid strings of data that Zim cannot represent.

> For your use-case you should definitely use a verbatim block.

How can I then cut and paste lines to Zim? Verbatim works only on single lines, indentation is broken (I know that you are working on that) and has many other limitations. The only advantage is that it is a workaround to this issue. Instead, this issue should be fixed with escaping.

> The "dataloss" mention may be incorrect, because you should be
> able to "recover" your data from the txt files.

No, I've already manually removed the links as they were polluting my tree with pages that did not exist. The data is long gone.