Incorrect handling of the @ symbol in the preformatted text.

[canonic-epicure]

If the preformatted text in the docs includes @ symbol (commonly used in decorators):

 * Note, that due to this [issue](https://github.com/Microsoft/TypeScript/issues/7342), if you use decorators in your mixin class,
 * the declaration needs to be slightly more verbose (can not use compact notation for the arrow functions):
 *
 *     class Mixin2 extends Mixin(
 *         [ Mixin1 ],
 *         (base : AnyConstructor<Mixin1, typeof Mixin1>) => {
 *             class Mixin2 extends base {
 *                 @decorator
 *                 prop2 : string
 *             }
 *             return Mixin2
 *         }
 *     ){}
 *

The generated docs looks like this:

[canonic-epicure]

Surprisingly when importing the external md file with [[include:BasicFeatures.md]] the result is correct:

[Gerrit0]

That works because importing files happens after parsing for tags.

Workaround: Use backtick code fences instead of indentation for code blocks. We do have correct handling for fenced code blocks - https://github.com/TypeStrong/typedoc/blob/master/src/lib/converter/factories/comment.ts#L191

[canonic-epicure]

Thanks for the info!

[canonic-epicure]

Worked well. I guess I'll keep this issue opened for the info can be discovered by others.

[Gerrit0]

The fix I put in for this is utterly insufficient.... it assumes everything indented with 4 spaces is code.... which isn't valid if you have a list and put some text on the next line.

/**
 * Text
 * -    List item
 * -    Another list item
 *      This isn't code, but TypeDoc thinks it is
 */

With 0.23, I plan to drop support for indentation based code blocks in TypeDoc's parser. This matches with how TSDoc plans to handle code blocks, and how the vast majority of code is included in the wild (at least based on my manual polling of several projects). Markdown is an incredibly complex language. Trying to support all of these edge cases seems like a bad idea.