Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Markdown lists. #178

Open
DylanVann opened this issue Aug 6, 2019 · 8 comments
Open

Markdown lists. #178

DylanVann opened this issue Aug 6, 2019 · 8 comments
Labels
octogonz-parser-backlog Items for @octogonz to consider during the next iteration on the parser

Comments

@DylanVann
Copy link

It would be useful to be able to include lists in doc comments:

/**
 * This module does:
 *
 * - A thing.
 * - Another thing.
 * - One more thing.
 */
@csr632
Copy link

csr632 commented Aug 27, 2019

image

How can monaco(vscode) render lists already?

@futagoza
Copy link

@csr632 It has a built-in JSDoc comment parser that puts the tag content through a markdown to HTML transformer. In fact, I'm pretty sure it has support for most markdown features.

@octogonz
Copy link
Collaborator

Right, Monaco's default styler implements a scanner that recognizes various constructs that are commonly found in JavaScript/TypeScript doc comments. Of course, other editors like WebStorm may parse these comments differently. Whereas TSDoc's goals include establishing a rigorous spec that would enable various tools to parse doc comments, and agree on the interpretation. (For example, is <!-- {@link X} --> a visible link or not? What about \{@link X}? What about <b>{@link X}</b>? Today different tools have very different opinions.)

@octogonz octogonz added the octogonz-parser-backlog Items for @octogonz to consider during the next iteration on the parser label Dec 9, 2019
@iansan5653
Copy link

Definitely agree with this - a common use case for me is documenting string union types, like this one:

/**
 * Open a file.
 * @param path - the path to the file.
 * @param mode - the file-opening mode to use. Possible values include:
 * 
 *  - `"w"` - basic 'write' mode; allows editing.
 *  - `"w+"` - advanced 'write' mode; allows editing and creates the file if it
 *    doesn't exist.
 *  - `"r"` - basic 'read' mode; allows reading but not editing.
 */
function openFile(path: string, mode: "w" | "w+" | "r"): string {
  //...
}

Of course, in many instances it might be better to use an enum and document each member, but sometimes that's too complex for a simple union, or the union might be pulled from something else (ie by using keyof).

@rbuckton
Copy link
Member

The problem I see currently is that the TSDoc emitter doesn't emit DocSoftBreak, so single-line breaks are removed:

    /**
     * Compares this value with another value:
     *
     * - A negative value indicates this value is lesser.  
     * - A positive value indicates this value is greater.  
     * - A zero value indicates this value is the same.  
     *
     * @param other The other value to compare against.
     * @returns A number indicating the relational comparison result.
     */

However the "docComment" written to the API json file looks like this:

"docComment": "/**\n * Compares this value with another value:\n *\n * - A negative value indicates this value is lesser. - A positive value indicates this value is greater. - A zero value indicates this value is the same.\n *\n * @param other - The other value to compare against.\n *\n * @returns A number indicating the relational comparison result.\n */\n",

which looks like the following after a round-trip through the TSDoc parser and emitter:

/**
 * Compares this value with another value:
 *
 * - A negative value indicates this value is lesser. - A positive value indicates this value is greater. - A zero value indicates this value is the same.
 *
 * @param other - The other value to compare against.
 *
 * @returns A number indicating the relational comparison result.
 */

@octogonz
Copy link
Collaborator

@rbuckton The word-wrapping is tracked by issue #200.

@rbuckton
Copy link
Member

From the linked issue, it seems the current behavior to trim insignificant whitespace is the culprit. The problem, as I see it, is that TSDoc's parser is making assumptions about what kind of whitespace is significant that is inconsistent with what Markdown considers to be insignificant whitespace.

@SomeHats
Copy link

For https://tldraw.dev, we solved this by patching tsdoc to have it emit softbreaks. We did this by preserving most of the transform that strips "insignificant" whitespace, but having it keep linebreaks. You could possibly also remove this transform entirely, especially for cases (like markdown) where whitespace actually is significant.

Patch here in case it's of use to anyone!

diff --git a/lib-commonjs/emitters/TSDocEmitter.js b/lib-commonjs/emitters/TSDocEmitter.js
index 36c607ac192810524ae28ce818d64652efedca98..41650ab83b6825d33b75fb86ec9b8eb0f0b5dfc7 100644
--- a/lib-commonjs/emitters/TSDocEmitter.js
+++ b/lib-commonjs/emitters/TSDocEmitter.js
@@ -278,6 +278,9 @@ var TSDocEmitter = /** @class */ (function () {
                 var docPlainText = docNode;
                 this._writeContent(docPlainText.text);
                 break;
+            case DocNode_1.DocNodeKind.SoftBreak:
+                this._ensureAtStartOfLine();
+                break;
         }
     };
     TSDocEmitter.prototype._renderInlineTag = function (docInlineTagBase, writeInlineTagContent) {
diff --git a/lib-commonjs/transforms/TrimSpacesTransform.js b/lib-commonjs/transforms/TrimSpacesTransform.js
index 8d8a92b9a2c97347c29094df7d0e2b23cdcdffaf..6c5946e3f9adb61e46ce1d7d39ab07ee81db923e 100644
--- a/lib-commonjs/transforms/TrimSpacesTransform.js
+++ b/lib-commonjs/transforms/TrimSpacesTransform.js
@@ -18,6 +18,25 @@ var TrimSpacesTransform = /** @class */ (function () {
         // We always trim leading whitespace for a paragraph.  This flag gets set to true
         // as soon as nonempty content is encountered.
         var finishedSkippingLeadingSpaces = false;
+
+        function pushAccumulatedText() {
+            const lines = accumulatedTextChunks.join('').split('\n')
+            for (let i = 0; i < lines.length; i++) {
+                const line = lines[i]
+                transformedNodes.push(new nodes_1.DocPlainText({
+                    configuration: docParagraph.configuration,
+                    text: line
+                }));
+                if (i < lines.length - 1) {
+                    transformedNodes.push(new nodes_1.DocSoftBreak({
+                        configuration: docParagraph.configuration
+                    }));
+                }
+            }
+            accumulatedTextChunks.length = 0;
+            accumulatedNodes.length = 0;
+        }
+
         for (var _i = 0, _a = docParagraph.nodes; _i < _a.length; _i++) {
             var node = _a[_i];
             switch (node.kind) {
@@ -44,9 +63,15 @@ var TrimSpacesTransform = /** @class */ (function () {
                     }
                     break;
                 case nodes_1.DocNodeKind.SoftBreak:
-                    if (finishedSkippingLeadingSpaces) {
-                        pendingSpace = true;
-                    }
+                    // by default, this transform strips out all soft-breaks and replaces them with
+                    // spaces where needed. because we're rendering to markdown and markdown is
+                    // whitespace-sensitive, we don't want to do this. instead, we accumulate the
+                    // soft-breaks and emit them as normal.
+                    
+                    // if (finishedSkippingLeadingSpaces) {
+                    // pendingSpace = true;
+                    // }
+                    accumulatedTextChunks.push('\n');
                     accumulatedNodes.push(node);
                     break;
                 default:
@@ -58,12 +83,7 @@ var TrimSpacesTransform = /** @class */ (function () {
                     if (accumulatedTextChunks.length > 0) {
                         // TODO: We should probably track the accumulatedNodes somehow, e.g. so we can map them back to the
                         // original excerpts.  But we need a developer scenario before we can design this API.
-                        transformedNodes.push(new nodes_1.DocPlainText({
-                            configuration: docParagraph.configuration,
-                            text: accumulatedTextChunks.join('')
-                        }));
-                        accumulatedTextChunks.length = 0;
-                        accumulatedNodes.length = 0;
+                        pushAccumulatedText()
                     }
                     transformedNodes.push(node);
                     finishedSkippingLeadingSpaces = true;
@@ -71,12 +91,7 @@ var TrimSpacesTransform = /** @class */ (function () {
         }
         // Push the accumulated text
         if (accumulatedTextChunks.length > 0) {
-            transformedNodes.push(new nodes_1.DocPlainText({
-                configuration: docParagraph.configuration,
-                text: accumulatedTextChunks.join('')
-            }));
-            accumulatedTextChunks.length = 0;
-            accumulatedNodes.length = 0;
+            pushAccumulatedText()
         }
         var transformedParagraph = new nodes_1.DocParagraph({
             configuration: docParagraph.configuration

github-merge-queue bot pushed a commit to tldraw/tldraw that referenced this issue May 23, 2024
We write our API docs in markdown embedded in tsdocs comments. vscode's
hover preview of these docs renders them as expected, but api-extract
treats whitespace as insignificant and strips out most newlines, which
breaks markdown lists. See microsoft/tsdoc#178
for details.

This PR patches tsdoc's emitter so that it preserves newlines. That way,
we can write markdown lists and have them picked up as expected by the
docs site markdown parser. I don't expect this to introduce other issues
with previously ignored line breaks and markdown is only sensitive to
linebreaks in certain scenarios (like lists) anyway.

(Extracted from bindings docs - #3812)

Before:
<img width="740" alt="Screenshot 2024-05-22 at 15 00 43"
src="https://github.com/tldraw/tldraw/assets/1489520/846f88b1-9480-48a6-9795-6a9f27ca242a">

After:
<img width="708" alt="Screenshot 2024-05-22 at 14 51 28"
src="https://github.com/tldraw/tldraw/assets/1489520/80c54b8e-4f74-45e7-9cba-0287175e9f97">


### Change Type

- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `bugfix` — Bug fix
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
octogonz-parser-backlog Items for @octogonz to consider during the next iteration on the parser
Projects
None yet
Development

No branches or pull requests

7 participants