Anthony Ciccarello

@pgonzal I'm not sure I understand your question but the code you have looks good to me. My main question is where should the example tag block end? Would it...

@kiliancs That seems to me like something that should stay in the example code and not be handled by the documentation tool. Interesting idea though. ```typescript /** * @example *...

I think it makes sense to leave it as a generic text block. That is how it is currently handled in typedoc. Making it special has been requested in TypeStrong/typedoc#1045...

Here is how TypeDoc parses the example. _(note: this was edited to reflect what TypeDoc actually does)_ 1. Is considered a comment on the file (since there is no declaration...

After testing out my expectations, you can see that TypeDoc only pays attention to comments that begin with `/**`. This causes a potential problem when commenting out lines like [5]...

Yes, the tslint use case seem significant. I don't think TSDoc should do anything too tslint specific though. How else could you avoid messing with documentation by commenting out a...

I think I'm leaning towards requiring whitespace aftwards to prevent documentation shifting to the next variable. While I often write my properties in a tight group, those groupings already get...

@octogonz I'm curious if you have thought any more about file level doc comments? In TypeStrong/typedoc#603 users have noted that they expect the first comment of the file to be...

TypeDoc takes the second approach. There are some special case situations where parsing needs to be markdown aware (e.g. code blocks) but most of the parsing can be passed to...

@yume-chan It would be great to simplify the comment parsing. However, I think it may be surprising to JavaScript developers familiar with JSDoc to not support `{@link}` tags. I would...