Message Boards Message Boards

5
|
6818 Views
|
5 Replies
|
15 Total Likes
View groups...
Share
Share this post:

DocumentationTools in version 13.0: creating documentation from usage

POSTED BY: Martijn Froeling
5 Replies
Posted 2 years ago

Brian, In the process of figuring out how to parse apart the original System` Symbols usage by using the function Information (and later WolframLanguageData) definitions I discovered many boxes formatting bugs (reported) and inconsistent handling of subscripts (v1 or v_1, and reported). Further, I have formally requested, that a function with several different usage definitions be returned as a list not a large text block that may or may not parse well into single usage statements. Generally, I see the meta-template:

fname[arguments] usagetext. fname[arguments] usagetext. etc...

and the sometimes problematic

fname[arguments] usagetext.\nusagetext. fname[arguments] usagetext.\nusagetext.

Parsing for ". " marker can be brittle since its 2 chars not a single unique glyph marker; ". " would need to be enforced when a definition is created and saved. Can the case be made, unless am missing something, for the following, as consistent even for code use (as long as the dev does not use ; in their usage definition), if a single text block is wanted:

fname[arguments] usagetext.;usagetext\nfname[arguments] usagetext.;nusagetext.

Further there is the parsing problems of this:

fname1[arguments] or fname2[arguments] usagetext.

Perhaps its better to do this which is easier to parse:

fname1[arguments] usagetext. fname2[arguments] usagetext.

If am misunderstanding anything, please inform me. :-)

Since definitions are at the core of any language, and at the heart of much of western intellectual thought for thousands of years, is there a formal style guide how to define usage correctly and can be easily parsed? Perhaps a definition checker possible using Wolfram's AI work? What makes up a robust, short, and clear usage definition?

Thanks for your help.

POSTED BY: Andrew Meit

Hi Martijn,

Thanks for bringing this to our attention. I'm managing development on DocumentationTools, so I'll make sure this gets fixed in a coming update. While fixing it, if there's a straightforward workaround, we'll attach it here so you don't have to wait for an official update.

Thanks again!

Hi Brian,

Thanks for the response!

If I may, I have two additional questions:

  1. Is there any possibility to expose the functions under the pallet to the frontend? I was trying to figure out how I can script the functionality of the "generate function pages" button. Since life is too short for clicking buttons :p... With the new documentation and build tools, I was hoping to have a script that can do an automated weekly build of my packets and automatically push them to git.
  2. Are there plans to convert the documentation to HTML which was (partly) possible with Workbench (with some fixes). That way the documentation can be integrated into my website as I currently do (QMRITools documentation) although being with a very outdated look.

Keep up te great work! Martijn

POSTED BY: Martijn Froeling

Sorry -- it took longer than I intended to get back to you.

In the near term, you can work around the usage formatting issue by not using newlines in the usage message. We're going to handle that in an update coming soon, but if you make the entire usage message on one line (simply put a space between the end of the first and start of the second template), it should do the right thing.

Re: your other questions, we've recently gotten other feedback about exposing the DocumentationTools functions for programmatic use; I'm considering it. Making them top-level functions comes with an implicit understanding that they're integrated with the language more widely among other things, and we weren't developing with that specifically in mind, so this might be a gradual process.

The documentation build code that is shipping with the desktop products is capable of building HTML pages already, believe it or not. The relevant function is PacletDocumentationBuild (https://reference.wolfram.com/language/PacletTools/ref/PacletDocumentationBuild.html), where you use:

Needs["PacletTools`"];PacletDocumentationBuild[paclet, outdir, "HTML"]

Hope this helps -- let us know if you have other issues!

This definitely helps! Will try it asap and let you know how things work out. Thanks for the feedback!

POSTED BY: Martijn Froeling
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract