Open ganicke opened 4 years ago
Adding the text from my earlier email:
This is a problem we’ve had for some time. This is related to recognizing text substrings in the editor as functions, methods, namespaces, variables, etc. Blocks are very deterministic as an actual BlockID is associated with each block. These refer directly to metadata which contains a help path for the documentation page.
When in JavaScript, MakeCode is using the Monoco editer which does provide some object info for cursor context. However, I don’t think we’re using that to retrieve associated metadata for the code under the cursor. Instead, an attempt is made to parse out a substring from the cursor location and then form a path from it to retrieve the help page. For example, when you hover over the “onChat()” portion of the string “player.onChat()”, the context help code builds a path using “on-chat” for the “onChat” substring and then backs up past the “.” for the namespace to discover “player”. These are combined with “/reference” to form the document path of “/reference” + “/player” + “/on-chat”.
This works for most, well maybe just some, of the code elements in text. So, not all help paths are resolved correctly with this technique especially for methods on objects returned from create-style functions: "mySprite.setPosition()". The name "mySprite" is not a namespace of course and can't be used to form a document path.
BTW, need a sidedocs
label for pxt: https://github.com/microsoft/pxt/labels/sidedocs.
Just wondering if you could fallback to a page that autogenerates based on the apis macro when a file is not found.
Transferring this issue from: https://github.com/microsoft/pxt-minecraft/issues/1878 RE: https://github.com/microsoft/pxt-minecraft/issues/1877
@Jaqster posted:
Right-clicking on some values/API's in typescript, and selecting Help opens side-docs pane, but doesn't load anything. If we don't have documentation, then we should hide the Help option in the context menu.