Pete Gonzalez

When I started working on this, I realized that the emitter should probably support three separate modes: 1. **verbatim**: Emit the AST "as-is" without any reformatting. This would be used...

Also note that word-wrap probably cannot be applied to other sections such as `DocCodeSpan` or (in the future) markdown headings, unless we introduce a comment-wrapping operator like proposed in [RFC...

> I'd like to make a tool that, no matter how the input content is formatted, always produces the same standardized output. Lines wrapped, tags in the same order, newlines...

> In my opinion, the best thing to do is to parse out the TSDoc specific syntax (`@` tags and `{}` inlines, etc.) and trim the leading `*` from each...

We could address this by providing an escaping mechanism like `*\/`. We need to formalize escaping in TSDoc but I've been procrastinating it because the problem is very thorny due...

This problem is fairly difficult. Users have a very strong expectation that a fenced code block is reproduced literally. For example, suppose we choose `\` as our escape character. We...

I wonder if `*//*` could be used as an escape character. 🤭 That at least doesn't conflict with any possible expression inside a comment.

I thought of a possibly better solution to this problem! Suppose we have an API like this: ```ts function isDocComment(s: string): boolean { return /^\/\*.*\*\/$/.test(s); } ``` ...and we want...

> maybe it would be better to just reserve a special character sequence that _always_ (no matter where it is in a TSDoc comment) resolves to `*/`. Something like `&COMMENT_CLOSE;`...

> Is the only use case when you would ever use `+` for continuation when you have `*/` in a comment? It doesn't have to be a comment though; e.g....