| 584 | | TODO: describe rst markup style |
| 585 | | |
| 586 | | #. links, both kinds |
| 587 | | #. code blocks |
| 588 | | #. headers |
| | 584 | The *rst* markup style attempts to make its format definition similar to what someone would do normally for readability in a text document. For example, paragraphs are created by simply skipping a line:: |
| | 585 | |
| | 586 | ; Merges a string array into a single string separated by carriage |
| | 587 | ; return/linefeeds. |
| | 588 | ; |
| | 589 | ; Defaults to use just linefeed on UNIX platforms and both carriage returns |
| | 590 | ; and linefeeds on Windows platforms unless the UNIX or WINDOWS keywords are |
| | 591 | ; set to force a particular separator. |
| | 592 | |
| | 593 | There is other special syntax for some annotations that are common when documenting code. To place a block of code into the documentation, end a line with ``::``, skip a line, indent the block of code, and skip another line:: |
| | 594 | |
| | 595 | ; Set the decomposed mode, if available in the current graphics device i.e. |
| | 596 | ; equivalent to:: |
| | 597 | ; |
| | 598 | ; device, get_decomposed=oldDec |
| | 599 | ; device, decomposed=dec |
| | 600 | ; |
| | 601 | ; The main advantage of this routine is that it can be used with any graphics |
| | 602 | ; device; it will be ignored in devices which don't support it. |
| | 603 | |
| | 604 | Another common annotation is to place a link in the documentation. For example, to link "http://michaelgalloy.com" to the phrase "my website", simply do:: |
| | 605 | |
| | 606 | ; Check out `my website <http://michaelgalloy.com>`. |
| | 607 | |
| | 608 | But often, links are to other items in the documentation. For example, the comments for a routine, might briefly mention some of its keywords and it would be convenient to link to the documentation for these keywords. In this case, just put the method names in backticks like:: |
| | 609 | |
| | 610 | ; :Returns: |
| | 611 | ; Returns a triple as a `bytarr(3)` or `bytarr(3, n)` by default if a single |
| | 612 | ; color name or n color names are given. Returns a decomposed color index |
| | 613 | ; as a long or lonarr(n) if `INDEX` keyword is set. |
| | 614 | ; |
| | 615 | ; Returns a string array for the names if `NAMES` keyword is set. |
| | 616 | |
| | 617 | IDL will search for a name matching the quoted string and link to the closest one it finds. If the name is not found, as in ``bytarr(3)`` above, it will simply be displayed in a monospace space font as code. |
| | 618 | |
| | 619 | Different level headers can be added to comments, particularly useful for `.idldoc` files. Just underline with ``-``, ``=``, or ``~``. For example, the following beginning to an `.idldoc` file, creates a level 1 header "TxDAP API Introduction", with a level 2 header "Basic Use" immediately after:: |
| | 620 | |
| | 621 | TxDAP API Introduction |
| | 622 | ====================== |
| | 623 | |
| | 624 | Basic Use |
| | 625 | --------- |
| | 626 | |
| | 627 | The order of use of the underlining determines the level of the header: the first underlined header is assumed to be level 1. The second, unless it is the same as the first, is assumed to be level 2, etc. From then on, titles underlined with "=" are level 1 headers and those underlined with "-" are level 2 headers. |