From 3034b80c8543c26a522421df1aab65e7289644bf Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Tue, 16 Apr 2024 00:08:32 +0000 Subject: [PATCH] build based on 65e8796 --- dev/.documenter-siteinfo.json | 2 +- dev/changelog/index.html | 3 + dev/customprocessing/index.html | 4 +- dev/documenter/index.html | 4 +- dev/fileformat/index.html | 4 +- dev/generated/example.ipynb | 128 +++++++++--------- .../example/{15a07bbc.svg => 54f1ad7c.svg} | 64 ++++----- dev/generated/example/index.html | 6 +- dev/generated/name/index.html | 2 +- dev/index.html | 2 +- dev/objects.inv | Bin 1324 -> 2314 bytes dev/outputformats/index.html | 8 +- dev/pipeline/index.html | 4 +- dev/reference/index.html | 2 +- dev/search_index.js | 2 +- dev/tips/index.html | 4 +- 16 files changed, 121 insertions(+), 118 deletions(-) create mode 100644 dev/changelog/index.html rename dev/generated/example/{15a07bbc.svg => 54f1ad7c.svg} (92%) diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index 9a197423..c0be44e9 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.10.2","generation_timestamp":"2024-04-14T12:08:54","documenter_version":"1.3.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.10.2","generation_timestamp":"2024-04-16T00:08:27","documenter_version":"1.3.0"}} \ No newline at end of file diff --git a/dev/changelog/index.html b/dev/changelog/index.html new file mode 100644 index 00000000..322ea3f2 --- /dev/null +++ b/dev/changelog/index.html @@ -0,0 +1,3 @@ + +9. Changelog · Literate.jl
GitHub

9. Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

v2.17.0 - 2024-04-14

Added

  • Literate can now output Quarto notebooks (markdown documents with the .qmd file extension) by passing flavor = Literate.QuartoFlavor() to Literate.markdown. This feature is marked as experimental since it has not been widely tested and the Quarto-specific syntax may change before Literate version 3 depending on what the community wants or needs. (#199, #200)

v2.16.1 - 2024-01-04

Fixed

  • Fix removal of Documenter-style @ref links spanning multiple lines. (#224, #233)

v2.16.0 - 2023-11-08

Added

  • "Soft" scoping rules (see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl) are now available for code execution (markdown and notebook output). This is enabled by default for Jupyter notebook output (to mimic how the IJulia kernel works), and disabled otherwise. Soft scope rules can be enabled/disabled with the softscope :: Bool configuration variable. (#227, #230)

Changed

  • The minimum Julia version requirement for Literate >= 2.16.0 is now 1.6.0 (from 1.0.0). (#230)

v2.15.1 - 2023-11-08

Fixed

  • Fix a bug where Literate.markdown with execute=true would (try to) output images in the wrong directory. This only occured when passing a relative output directory. (#228, #229)

v2.15.0 - 2023-09-05

Added

  • Documenter style @raw html blocks are automatically handled in Jupyter notebook output (similar to how Documenter style `math blocks are rewritten to $$ blocks). (#222, #223)

v2.14.2 - 2023-08-28

Fixed

  • Remove double newline in Literate.script output. (#221)

v2.14.1 - 2023-08-04

Fixed

  • Update generated EditURL to use a relative path instead and let Documenter figure out the remote repository. This is required for Documenter version 1, but works also on Documenter 0.27. (#219)

v2.14.0 - 2022-09-22

Changed

  • Image filenames resulting from executing markdown files (Literate.markdown(...; execute=true)) have changed from a number based on the hash of the source block to the format {name}-{blocknumber}.(svg|png|...). (#204, #205)

v2.13.4 - 2022-06-03

Fixed

  • Automatic head branch detection (introduced in version 2.11.0) caused a performance regression since the git remote show command takes ~1 second. For documentation builds with many literate files this caused significant slowdowns, which is particularly annoying when doing iterative buils with eg. LiveServer.jl. Literate now caches the remote head branch on a per-repo basis, so the 1 second delay should only be noticed on the first run of the first file in a repo. As noted in the changelog entry for 2.11.0 it is also possible to specify the head branch by passing the edit_commit keyword argument. Doing so will now completely skip the slow git command. (8054d26)

v2.13.3 - 2022-05-21

Fixed

  • Update remote HEAD branch detection to use addenv instead of setenv such that e.g. ssh-agent variables are available to the git command. Also set GIT_SSH_COMMAND='ssh -o "BatchMode yes"' to supress prompts when using ssh. (#197)

v2.13.2 - 2022-04-22

Fixed

  • Set current working directory for markdown execution to the output directory, just like notebook execution. (#195)
  • Set the apparent source file to the output file for markdown and notebook execution. (#195)

v2.13.1 - 2022-04-12

Fixed

  • Disable git terminal prompt when detecting remote HEAD branch. (#194)

v2.13.0 - 2022-02-18

Changed

  • "Markdown stdlib-style" inline math (e.g. ``f(x) = x^2``) is now replaced with "notebook style" math ($f(x) = x^2$) for notebook output. This is already the case for display math ($```math$). (#116, #190)

Fixed

  • Lines with trailing #hide are not shown in output of Markdown execution with Documenter flavor. (#166, #188)

v2.12.1 - 2022-02-10

Fixed

  • Make sure Markdown execution picks up new definitions of display methods (by running in the latest "world age"). (#187)

v2.12.0 - 2022-02-01

Changed

  • User input configurations can now be AbstractDicts instead of just Dicts. (#185, #186)

v2.11.0 - 2022-01-25

Added

  • Literate now tries to figure out the branch/commit that EditURL should point to automatically instead of always defaulting to "master". For typical setups the auto-detection should be sufficient, but you can also set it explicitly by passing edit_commit, for example edit_commit = "main". (#179, #184)

v2.10.0 - 2022-01-24

Added

  • Markdown execution now also support image/svg+xml. (#182, #183)

v2.9.4 - 2021-10-18

Fixed

  • Fix multiline comment support for \r\n line endings. (#171, #172)

v2.9.3 - 2021-09-01

Fixed

  • Fix named @examples from Literate.markdown to not contain spaces even if the source filename does. (#168, #169)

v2.9.2 - 2021-08-16

Fixed

  • Fix multiline comment support for \r\n line endings. (#165, #167)

v2.9.1 - 2021-07-30

Fixed

  • Automatic URLs from @__NBVIEWER_ROOT_URL__ and @__BINDER_ROOT_URL__ now follow the convention used in Documenter.jl to ignore build version information. (#162, #163)

v2.9.0 - 2021-07-09

Added

  • Added "Franklin flavored" markdown output for usage with Franklin. Enable by passing the flavor keyword argument:
    Literate.markdown(...; flavor = Literate.FranklinFlavor())
    (#146, #147, #156)
  • Added "Documenter flavored" markdown output as a replacement for documenter=true, and "CommonMark flavored" markdown output as a replacement for documenter=false. Enable by passing the flavor keyword argument:
    Literate.markdown(...; flavor = Literate.DocumenterFlavor())
+Literate.markdown(...; flavor = Literate.CommonMarkFlavor())
    (#159)
  • Added option to use multiline markdown strings (md""" ... """) as markdown sections. To enable, pass mdstrings=true. (#152, #149)

Changed

  • The default code fence for markdown output have been changed to 4 (instead of 3) backticks to allow input files with 3 backticks, which is common in e.g. docstrings or multiline Cmd. (#144, #145)
  • Replacement of Documenter-style @ref and @id elements are now removed unconditionally instead of conditionally based on the (now deprecated) documenter keyword argument. (#159)

Deprecated

  • The documenter keyword argument has been deprecated. For Literate.markdown the the replacement is to use flavor = Literate.DocumenterFlavor() or flavor = Literate.CommonMarkFlavor() as appropriate (see above). For Literate.notebook and Literate.script the option is now unused (see above regarding @ref and @id), and no replacement is necessary. (#159)

v2.8 - 2021-01-19

Added

  • Execution of notebooks now capture output of display(x) and display(mime, x) (ceff7a3).

v2.7 - 2021-09-12

Added

  • Multiline-style Julia comments (#= ... =#) can now be used for markdown input (dc409d0).

v2.6 - 2020-08-15

Added

  • New end-of-line token #hide which filters out the line after execution in Literate.markdown(...; execute=true) (6d1aec9).
  • Markdown execution now captures the text/markdown MIME (e08ca0a).

v2.5 - 2020-05-14

Changed

  • The output directory now defaults to pwd() (2ba316a).

v2.4 - 2020-04-23

Added

  • Markdown output can now be executed and the result included in the output by pasing execute=true to Literate.markdown. Currently captures the following MIMEs: text/plain, image/png, and image/jpeg (7e89fdb).

v2.3 - 2020-03-03

Added

  • Filter tokens #md, #nb, and #jl, as well as their negated counterparts, can now be placed at the end of lines (b0806ed).

v2.2 - 2019-11-26

Added

  • Configuration can now be passed as a config::Dict keyword argument to the generators (0f9e836).
  • Link macros now works when running on GitLab CI (4e71b15).
  • Literate now supports more configuration for e.g. URL's that @__REPO_ROOT_URL__ and friends expand to (4e71b15).

v2.1 - 2019-10-30

Added

  • Link macros now works when running on GitHub Actions (cf2b552).

v2.0 - 2019-07-19

Added

  • Negated filter tokens (#!nb, #!md and #!jl) are now supported (1d02868).
  • Notebook output now support cell metadata with the %%-format (0872a96).

Changed

  • BREAKING The link macros @__REPO_ROOT_URL__, @__NBVIEWER_ROOT_URL__ and @__BINDER_ROOT_URL__ no longer include a trailing / (7af5414).
  • BREAKING The (undocumented) feature of Documenter continued blocks now requires an explicit #+ chunk splitter (36e8c21).
  • The link macros @__REPO_ROOT_URL__, @__NBVIEWER_ROOT_URL__ now expands to correct paths when documentation is built with DocumentationGenerator.jl (7af5414).

v1.1 - 2019-04-05

Added

  • New link macro @__BINDER_ROOT_URL__ for linking to notebooks mybinder.org (fa64dcd).

v1.0 - 2019-03-06

First stable release of Literate.jl, see https://discourse.julialang.org/t/ann-literate-jl/10651 for release announcement.

diff --git a/dev/customprocessing/index.html b/dev/customprocessing/index.html index 841e078e..60f6321e 100644 --- a/dev/customprocessing/index.html +++ b/dev/customprocessing/index.html @@ -1,5 +1,5 @@ -5. Custom pre- and post-processing · Literate.jl
GitHub

5. Custom pre- and post-processing

Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.

All of the generators (Literate.markdown, Literate.notebook and Literate.script) accept preprocess and postprocess keyword arguments. The default "transformation" is the identity function. The input to the transformation functions is a String, and the output should be the transformed String.

preprocess is sent the raw input that is read from the source file (modulo the default line ending transformation). postprocess is given different things depending on the output: For markdown and script output postprocess is given the content String just before writing it to the output file, but for notebook output postprocess is given the dictionary representing the notebook, since, in general, this is more useful.

Example: Adding current date

As an example, lets say we want to splice the date of generation into the output. We could of course update our source file before generating the docs, but we could instead use a preprocess function that splices the date into the source for us. Consider the following source file:

# # Example
+5. Custom pre- and post-processing · Literate.jl
GitHub
5. Custom pre- and post-processing
Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.
All of the generators (Literate.markdown, Literate.notebook and Literate.script) accept preprocess and postprocess keyword arguments. The default "transformation" is the identity function. The input to the transformation functions is a String, and the output should be the transformed String.
preprocess is sent the raw input that is read from the source file (modulo the default line ending transformation). postprocess is given different things depending on the output: For markdown and script output postprocess is given the content String just before writing it to the output file, but for notebook output postprocess is given the dictionary representing the notebook, since, in general, this is more useful.
Example: Adding current date
As an example, lets say we want to splice the date of generation into the output. We could of course update our source file before generating the docs, but we could instead use a preprocess function that splices the date into the source for us. Consider the following source file:
# # Example
 # This example was generated DATEOFTODAY
 
 x = 1 // 3
where DATEOFTODAY is a placeholder, to make it easier for our preprocess function to find the location. Now, lets define the preprocess function, for example
function update_date(content)
@@ -26,4 +26,4 @@
     end
     return str
 end
(of course replace included with your respective files)
Finally, you simply pass this function to e.g. Literate.markdown as
Literate.markdown("examples.jl", "path/to/save/markdown";
-                  name = "markdown_file_name", preprocess = replace_includes)
and you will see that in the final output file (here markdown_file_name.md) the include statements are replaced with the actual code to be included!
This approach is used for generating the examples in the documentation of the TimeseriesPrediction.jl package. The  example files, included together in the  stexamples.jl file, are processed by literate via this make.jl  file to generate the markdown and code cells of the documentation.

+                  name = "markdown_file_name", preprocess = replace_includes)

and you will see that in the final output file (here markdown_file_name.md) the include statements are replaced with the actual code to be included!

This approach is used for generating the examples in the documentation of the TimeseriesPrediction.jl package. The example files, included together in the stexamples.jl file, are processed by literate via this make.jl file to generate the markdown and code cells of the documentation.

diff --git a/dev/documenter/index.html b/dev/documenter/index.html index 8f77f786..93555e8e 100644 --- a/dev/documenter/index.html +++ b/dev/documenter/index.html @@ -1,5 +1,5 @@ -6. Interaction with Documenter.jl · Literate.jl
GitHub

6. Interaction with Documenter.jl

Literate can be used for any purpose, it spits out regular markdown files, and notebooks. Typically, though, these files will be used to render documentation for your package. The generators (Literate.markdown, Literate.notebook and Literate.script) supports a keyword argument documenter that lets the generator perform some extra things, keeping in mind that the source code have been written with Documenter.jl in mind. So let's take a look at what will happen if we set documenter = true:

Literate.markdown:

Literate.script:

  • Documenter style @refs and @id will be removed. This means that you can use @ref and @id in the source file without them leaking to the script.
diff --git a/dev/fileformat/index.html b/dev/fileformat/index.html index 22bdde3d..ea0672ae 100644 --- a/dev/fileformat/index.html +++ b/dev/fileformat/index.html @@ -1,5 +1,5 @@ -2. File format · Literate.jl
GitHub

2. File format

The source file format for Literate is a regular, commented, julia (.jl) scripts. The idea is that the scripts also serve as documentation on their own and it is also simple to include them in the test-suite, with e.g. include, to make sure the examples stay up to date with other changes in your package.

2.1. Syntax

The basic syntax is simple:

  • lines starting with # are treated as markdown,
  • all other lines are treated as julia code.

Leading whitespace is allowed before #, but it will be removed when generating the output. Since #-lines are treated as markdown we can not use that for regular julia comments, for this you can instead use ##, which will render as # in the output.

Lets look at a simple example:

# # Rational numbers
+2. File format · Literate.jl
GitHub
2. File format
The source file format for Literate is a regular, commented, julia (.jl) scripts. The idea is that the scripts also serve as documentation on their own and it is also simple to include them in the test-suite, with e.g. include, to make sure the examples stay up to date with other changes in your package.
2.1. Syntax
The basic syntax is simple:
  • lines starting with # are treated as markdown,
  • all other lines are treated as julia code.
Leading whitespace is allowed before #, but it will be removed when generating the output. Since #-lines are treated as markdown we can not use that for regular julia comments, for this you can instead use ##, which will render as # in the output.
Lets look at a simple example:
# # Rational numbers
 #
 # In julia rational numbers can be constructed with the `//` operator.
 # Lets define two rational numbers, `x` and `y`:
@@ -29,4 +29,4 @@
 #md # Literate.notebook
 #md # Literate.script
 #md # ```
The lines in the example above would be filtered out in the preprocessing step, unless we are generating a markdown file. When generating a markdown file we would simply remove the leading #md from the lines. Beware that the space after the tag is also removed.
The #src token can also be placed at the end of a line. This is to make it possible to have code lines exclusive to the source code, and not just comment lines. For example, if the source file is included in the test suite we might want to add a @test at the end without this showing up in the outputs:
using Test                      #src
-@test result == expected_result #src
2.3. Default replacements
The following convenience "macros"/source placeholders are always expanded:
  • @__NAME__:
    expands to the name keyword argument to Literate.markdown, Literate.notebook and Literate.script (defaults to the filename of the input file).
  • @__REPO_ROOT_URL__:
    Can be used to link to files in the repository. For example @__REPO_ROOT_URL__/src/Literate.jl would link to the source of the Literate module. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.
  • @__NBVIEWER_ROOT_URL__:
    Can be used if you want a link that opens the generated notebook in http://nbviewer.jupyter.org/. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.
  • @__BINDER_ROOT_URL__:
    Can be used if you want a link that opens the generated notebook in https://mybinder.org/. For example, to add a binder-badge in e.g. the HTML output you can use:
    [![Binder](https://mybinder.org/badge_logo.svg)](@__BINDER_ROOT_URL__/path/to/notebook.inpynb)
    This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.

+@test result == expected_result #src

2.3. Default replacements

The following convenience "macros"/source placeholders are always expanded:

  • @__NAME__:

    expands to the name keyword argument to Literate.markdown, Literate.notebook and Literate.script (defaults to the filename of the input file).

  • @__REPO_ROOT_URL__:

    Can be used to link to files in the repository. For example @__REPO_ROOT_URL__/src/Literate.jl would link to the source of the Literate module. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.

  • @__NBVIEWER_ROOT_URL__:

    Can be used if you want a link that opens the generated notebook in http://nbviewer.jupyter.org/. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.

  • @__BINDER_ROOT_URL__:

    Can be used if you want a link that opens the generated notebook in https://mybinder.org/. For example, to add a binder-badge in e.g. the HTML output you can use:

    [![Binder](https://mybinder.org/badge_logo.svg)](@__BINDER_ROOT_URL__/path/to/notebook.inpynb)

    This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.

diff --git a/dev/generated/example.ipynb b/dev/generated/example.ipynb index 56498bf8..8c9860d5 100644 --- a/dev/generated/example.ipynb +++ b/dev/generated/example.ipynb @@ -278,97 +278,97 @@ "\n", "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", + "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", + "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n" + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n" ], "image/svg+xml": [ "\n", "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", + "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", + "\n", "\n", - " \n", + " \n", " \n", " \n", "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n", - "\n" + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n", + "\n" ] }, "metadata": {}, diff --git a/dev/generated/example/15a07bbc.svg b/dev/generated/example/54f1ad7c.svg similarity index 92% rename from dev/generated/example/15a07bbc.svg rename to dev/generated/example/54f1ad7c.svg index d3ad8c80..a6665d3b 100644 --- a/dev/generated/example/15a07bbc.svg +++ b/dev/generated/example/54f1ad7c.svg @@ -1,46 +1,46 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/generated/example/index.html b/dev/generated/example/index.html index c5400487..5ff55f53 100644 --- a/dev/generated/example/index.html +++ b/dev/generated/example/index.html @@ -1,5 +1,5 @@ -8. Example · Literate.jl
GitHub

8. Example

This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter has generated based on a markdown file generated with Literate. The corresponding notebook can be viewed in nbviewer here: example.ipynb, and opened in binder here: example.ipynb, and the plain script output can be found here: example.jl.

It is recommended to have the source file available when reading this, to better understand how the syntax in the source file corresponds to the output you are seeing.

Basic syntax

The basic syntax for Literate is simple, lines starting with # is interpreted as markdown, and all the other lines are interpreted as code. Here is some code:

x = 1//3
+8. Example · Literate.jl
GitHub
8. Example
 
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter has generated based on a markdown file generated with Literate. The corresponding notebook can be viewed in nbviewer here: example.ipynb, and opened in binder here: example.ipynb, and the plain script output can be found here: example.jl.
It is recommended to have the source file available when reading this, to better understand how the syntax in the source file corresponds to the output you are seeing.
Basic syntax
The basic syntax for Literate is simple, lines starting with # is interpreted as markdown, and all the other lines are interpreted as code. Here is some code:
x = 1//3
 y = 2//5
2//5
In markdown sections we can use markdown syntax. For example, we can write text in italic font, text in bold font and use links.
It is possible to filter out lines depending on the output using the #md, #nb, #jl and #src tags (see Filtering lines):
  • This line starts with #md and is thus only visible in the markdown output.
The source file is parsed in chunks of markdown and code. Starting a line with #- manually inserts a chunk break. For example, if we want to display the output of the following operations we may insert #- in between. These two code blocks will now end up in different @example-blocks in the markdown output, and two different notebook cells in the notebook output.
x + y
11//15
x * y
2//15
Output capturing
Code chunks are by default placed in Documenter @example blocks in the generated markdown. This means that the output will be captured in a block when Documenter is building the docs. In notebooks the output is captured in output cells, if the execute keyword argument is set to true. Output to stdout/stderr is also captured.
Note
Note that Documenter currently only displays output to stdout/stderr if there is no other result to show. Since the vector [1, 2, 3, 4] is returned from foo, the printing of "This string is printed to stdout." is hidden.
function foo()
     println("This string is printed to stdout.")
     return [1, 2, 3, 4]
@@ -13,7 +13,7 @@
 x = range(0, stop=6π, length=1000)
 y1 = sin.(x)
 y2 = cos.(x)
-plot(x, [y1, y2])
Example block output
Custom processing
It is possible to give Literate custom pre- and post-processing functions. For example, here we insert a placeholder value y = 321 in the source, and use a preprocessing function that replaces it with y = 321 in the rendered output.
x = 123
123
In this case the preprocessing function is defined by
function pre(s::String)
+plot(x, [y1, y2])
Example block output
Custom processing
It is possible to give Literate custom pre- and post-processing functions. For example, here we insert a placeholder value y = 321 in the source, and use a preprocessing function that replaces it with y = 321 in the rendered output.
x = 123
123
In this case the preprocessing function is defined by
function pre(s::String)
     s = replace(s, "x = 123" => "y = 321")
     return s
-end
pre (generic function with 1 method)
Documenter.jl interaction
In the source file it is possible to use Documenter.jl style references, such as @ref and @id. These will be filtered out in the notebook output. For example, here is a link, but it is only visible as a link if you are reading the markdown output. We can also use equations:
\[\int_\Omega \nabla v \cdot \nabla u\ \mathrm{d}\Omega = \int_\Omega v f\ \mathrm{d}\Omega\]
using Documenters math syntax. Documenters syntax is automatically changed to \begin{equation} ... \end{equation} in the notebook output to display correctly.
This page was generated using Literate.jl.

+end
pre (generic function with 1 method)

Documenter.jl interaction

In the source file it is possible to use Documenter.jl style references, such as @ref and @id. These will be filtered out in the notebook output. For example, here is a link, but it is only visible as a link if you are reading the markdown output. We can also use equations:

\[\int_\Omega \nabla v \cdot \nabla u\ \mathrm{d}\Omega = \int_\Omega v f\ \mathrm{d}\Omega\]

using Documenters math syntax. Documenters syntax is automatically changed to \begin{equation} ... \end{equation} in the notebook output to display correctly.

This page was generated using Literate.jl.

diff --git a/dev/generated/name/index.html b/dev/generated/name/index.html index 800f3aca..24e1145a 100644 --- a/dev/generated/name/index.html +++ b/dev/generated/name/index.html @@ -1,2 +1,2 @@ -Rational numbers · Literate.jl
GitHub

Rational numbers

In julia rational numbers can be constructed with the // operator. Lets define two rational numbers, x and y:

x = 1//3
1//3
y = 2//5
2//5

When adding x and y together we obtain a new rational number:

z = x + y
11//15
+Rational numbers · Literate.jl
GitHub

Rational numbers

In julia rational numbers can be constructed with the // operator. Lets define two rational numbers, x and y:

x = 1//3
1//3
y = 2//5
2//5

When adding x and y together we obtain a new rational number:

z = x + y
11//15
diff --git a/dev/index.html b/dev/index.html index 9ba20ea7..c432b6d7 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -1. Introduction · Literate.jl
GitHub

1. Introduction

Welcome to the documentation for Literate – a simplistic package for Literate Programming.

What?

Literate is a package that generates markdown pages (for e.g. Documenter.jl), and Jupyter notebooks, from the same source file. There is also an option to "clean" the source from all metadata, and produce a pure Julia script.

The main design goal is simplicity. It should be simple to use, and the syntax should be simple. In short, all you have to do is to write a commented julia script!

The public interface consists of three functions, all of which take the same script file as input, but generate different output:

  • Literate.markdown generates a markdown file. Code snippets can be executed and the results included in the output.
  • Literate.notebook generates a notebook. Code snippets can be executed and the results included in the output.
  • Literate.script generates a plain script file scrubbed from all metadata and special syntax.

Why?

Examples are (probably) the best way to showcase your awesome package, and examples are often the best way for a new user to learn how to use it. It is therefore important that the documentation of your package contains examples for users to read and study. However, people are different, and we all prefer different ways of trying out a new package. Some people want to RTFM, others want to explore the package interactively in, for example, a notebook, and some people want to study the source code. The aim of Literate is to make it easy to give the user all of these options, while still keeping maintenance to a minimum.

It is quite common that packages have "example notebooks" to showcase the package. Notebooks are great for showcasing a package, but they are not so great with version control, like git. The reason being that a notebook is a very "rich" format since it contains output and other metadata. Changes to the notebook thus result in large diffs, which makes it harder to review the actual changes.

It is also common that packages include examples in the documentation, for example by using Documenter.jl @example-blocks. This is also great, but it is not quite as interactive as a notebook, for the users who prefer that.

Literate tries to solve the problems above by creating the output as a part of the doc build. Literate generates the output based on a single source file which makes it easier to maintain, test, and keep the manual and your example notebooks in sync.

+1. Introduction · Literate.jl
GitHub

1. Introduction

Welcome to the documentation for Literate – a simplistic package for Literate Programming.

What?

Literate is a package that generates markdown pages (for e.g. Documenter.jl), and Jupyter notebooks, from the same source file. There is also an option to "clean" the source from all metadata, and produce a pure Julia script.

The main design goal is simplicity. It should be simple to use, and the syntax should be simple. In short, all you have to do is to write a commented julia script!

The public interface consists of three functions, all of which take the same script file as input, but generate different output:

  • Literate.markdown generates a markdown file. Code snippets can be executed and the results included in the output.
  • Literate.notebook generates a notebook. Code snippets can be executed and the results included in the output.
  • Literate.script generates a plain script file scrubbed from all metadata and special syntax.

Why?

Examples are (probably) the best way to showcase your awesome package, and examples are often the best way for a new user to learn how to use it. It is therefore important that the documentation of your package contains examples for users to read and study. However, people are different, and we all prefer different ways of trying out a new package. Some people want to RTFM, others want to explore the package interactively in, for example, a notebook, and some people want to study the source code. The aim of Literate is to make it easy to give the user all of these options, while still keeping maintenance to a minimum.

It is quite common that packages have "example notebooks" to showcase the package. Notebooks are great for showcasing a package, but they are not so great with version control, like git. The reason being that a notebook is a very "rich" format since it contains output and other metadata. Changes to the notebook thus result in large diffs, which makes it harder to review the actual changes.

It is also common that packages include examples in the documentation, for example by using Documenter.jl @example-blocks. This is also great, but it is not quite as interactive as a notebook, for the users who prefer that.

Literate tries to solve the problems above by creating the output as a part of the doc build. Literate generates the output based on a single source file which makes it easier to maintain, test, and keep the manual and your example notebooks in sync.

diff --git a/dev/objects.inv b/dev/objects.inv index 2f768c1d00acc20cc4db2538fae1a9ea32e42934..0e5ced08b22b601fedd91032de1cad6ab155ccfb 100644 GIT binary patch delta 2211 zcmV;U2weB93W^ete}A=FZEu`L5dOZuVx`zp>uNdR;C%Q?>&9`Fs!h@)RXCks|nSb!6$%=bJCuP@GT`N~; zY{|ic1q~efR#4R28j^HPTW+gcK6!L!xSfIAOT|k*w7hCqTe76)@J3eis;m`?nKgzu2I~kZ z+LlyGQ6)uQmc=H!??CrGoA%ZS9KgeY0Fmg%cJOd~TMQx^3>5JYINrQ?fCWT6ESbB8 zy_$*#V1NF2z(r*|Xe|^~o}nU2gI9A6UMYhE=6`xe7`!@#!7F31)GUZ zWw5|e?+A!Lfx$~-u+~CREr|Dg^2bBmem_+31=7x!x0Ll^!x>~}wo?;KLEqUib;S*b zM+wH>2)ZytqNPG2aLx%NS{fumUV|NoyuWpE4VVOI!G7-YEEaIf_-CGUM<9!}5|t}q z!GA@?N&3MzPsb9xLuJG%zxS~kQbZfG0&Z@@__r<_X^jPTcvf7M7dLn zMvAiKcV+p=uvcrc|M=m(y46q1OxDTN*Y0%FGU-FW~QZk8Z@;e{Z3=1lofled~Y5!MGBcbgirTrsMWsr{J<0$Tz}F! zNTT*VLBo`=Ry^KhN?03N`iy}+?qRpu~HcSfWSpVdi>J@6}r_F?e^na}C6?ut0 zDBU^Gv%Nv8oLe$`#yO_w?wnI~s53EXr7-EpN^f-vOj;RCvMarn#w1O5E{&Gz$YCu?Mp{NFgk%)d%yK@4Hh<9NDsCKHAvgIkZn8wxNJosC1iLDWbVMX^)yhtDT3!W( z5g~t?{nsVyU*G&t^Ub$c!_}<$J)ZTRlsxtGzy(=2EI4_($8$yA=$iUSw1KnIBBr)5 z%WhRp`8tKQ)R@AW=St5tk`j?9XXPhev*e*G9$8c6*)9y(r>({rN`I1~Bo&fWO7?rP z(fKi@Xdu+@Bn{H2HAA+je6F&{wjN{{h>7? zd3@cGNtv+&lN?u=j8r}322d=FCnHl230{@+=k;lkYSRFKVcDrREjmG$7MUhZ>mZ3H z=Oc~$+U0GACj*|n#eXfAex&`LH7$a}XzyT_pn3`6VtNUxme3QHnRz!fc^3_s>;=M8 z#5hp_s*`ME2{NW{{41Yq;A6z0r6yESn3{iv^ zUU{5w8APL~jO~gPqPCFUx|w54zrT&}p-G(Hx)Y2sefu^-XrZX~{i}=ZqpuoY0Q}Le z!&eQD<|T2uEsG4RxCY^`f`aZ2kgWZ3*k$#-g!%#i$N0v_5%F|&L-krv16r@pcY!nA zI_TXxI^tu1;C~cu9oTLi>5l;d%dL?}-t!Hwd6Ddt3AHB6dm6PZGry4tRFf_4A^pjI zEI7qC5`k&6wHAtMU6K0hf!l4>ib6pze(po60xpze(2L7d~ZboiQMc`jrRez7?LnX_P9C&$H#@fvI-j$kH zt(iAkSpuh-S0OLaSBYZuHBsg3%R<3Rtk0z6#~(MtkE;%r&Syt_V0Ce^#(Tq8)<;ug zjibCZT!@mu1&u)9bnacj>ro*6&$cp~zIKSQOGc_L$=hX98WT;{5jNgXR8bFvmG zU&}IMDl}_Xr!b3Pi9f;qCWRv@ccC8PyxEVwrbLONlZF00h2J8$*Bkm&Rf_njA`d)AKZ++){>-u>?Nn{BIfc^* zF6{rw4J(^`Q-8MNX{XS8`&eqc8D~WtYEEx?k+K+K(_=tmf-6C1ZQ(od4U2^(=-dhfSaPR$QBfsnTyjLw zk{7ac)N6cp$%p<73X}wk0*4}JGGB{_8qXiZHSlp9A%BTG0AeXgdnDeRT0`T8xL+Qb z`lE~7(`%EXCD8T^PLY4K$NFt|y}wK6_@p!s{;pYx)y2H&Uv(;&xqQl>d0g*Mqrekb zPrBd1cruiL#uG{Ss(yIQvuQj{1a0)7-SyD9RD31n6V-}ViU0XHe(87Ry1fqY;EH?{ z%B=aktACeVv1i)o!0V}cB>dttwODgB!EjzyB_K;pVAv88CDgWg>t#?Xxx*iCSopf}0QCWdx(4jZax-6pf*>p1Dg?A-#7qR0M2=h zo|ALFW_Yfi?{M1W_SlX0qvhIyAOsPXWHJ|8qAFd30@Z4T>8O|Sp!~4prgS~NG=Ev> zw0-M>_k{u%96@gRn&V>__b5^NWqk(i1eGP@k+{b-Fon9Zqfl1J8e=h+vi73`@{;fP z@E&SXhQ`FtedZb6(wcsZ--vBwkSS~()y#Md)`f7Rk;q&d{{_^@t<57ny b#c- -4. Output formats · Literate.jl
GitHub

4. Output formats

When the source is parsed, and has been processed it is time to render the output. We will consider the following source snippet:

# # Rational numbers
+4. Output formats · Literate.jl
GitHub
4. Output formats
When the source is parsed, and has been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
 #
 # In julia rational numbers can be constructed with the `//` operator.
 # Lets define two rational numbers, `x` and `y`:
@@ -42,10 +42,10 @@
 ````
 ````
 1//3
-````
In this example the output is just plain text. However, if the resulting value of the code block can be displayed as an image (image/png or image/jpeg), HTML (text/html) or markdown (text/markdown) Literate will include the richest representation of the output.
Note
Since Documenter executes and captures results of @example block it is not necessary to use execute=true for markdown output that is meant to be used as input to Documenter.
See the section about Configuration for more information about how to configure the behavior and resulting output of Literate.markdown.
Literate.markdown — Function
Literate.markdown(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)
Generate a markdown file from inputfile and write the result to the directory outputdir.
See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.
source
Markdown flavors
Literate can output markdown in different flavors. The flavor is specified using the flavor keyword argument. The following flavors are currently supported:
  • flavor = Literate.DocumenterFlavor(): this is the default flavor and the output is meant to be used as input to Documenter.jl.
  • flavor = Literate.CommonMarkFlavor(): this outputs markdown that has the flavor of the CommonMark specification.
  • flavor = Literate.FranklinFlavor(): this outputs markdown meant to be used as input to Franklin.jl.
  • flavor = Literate.QuartoFlavor(): this outputs markdown file (with file extension .qmd) meant to be used with Quarto CLI.
Quarto flavor
Experimental feature
Quarto markdown output is marked as and experimental feature since it has not been widely tested. Quarto-specific syntax may change before Literate version 3 depending on what the community wants and/or needs. If you use this flavor non-interactively (such as automatically building documentation) it is recommended to pin Literate to a good known version.
Quarto is an open-source scientific and technical publishing system, which can extend the range of output formats from your Literate.jl-formatted scripts. Literate.jl will produce a .qmd file, which can be used as input to Quarto CLI to produce a variety of output formats, including HTML, PDF, Word and RevealJS slides.
Literate + Quarto syntax tips
  • #(hashtag followed by a space) at the beginning of a line will be stripped and anything that follows will rendered as a markdown, e.g., # # Header level 1 in your script will be rendered as # Header level 1 in your .qmd file (ie, it will show as a header). Use this for adding the YAML header at the top or any Markdown blocks in the Quarto guide.
  • ##|(two hashtags followed by a pipe) at the beginning of a line will strip the first hashtag and interpret the remainder of the line as part of the code block. This is useful to provide Quarto commands in computation blocks, e.g., ##! echo: false would be rendered as #| echo: false and would tell Quarto not to "echo" the outputs of the execution (see Guide: Executions options for more commands).
  • Make sure to always provide the YAML header and specify IJulia kernel when executing the file by Quarto, e.g.,
    # ---
+````
    In this example the output is just plain text. However, if the resulting value of the code block can be displayed as an image (image/png or image/jpeg), HTML (text/html) or markdown (text/markdown) Literate will include the richest representation of the output.
    Note
    Since Documenter executes and captures results of @example block it is not necessary to use execute=true for markdown output that is meant to be used as input to Documenter.
    See the section about Configuration for more information about how to configure the behavior and resulting output of Literate.markdown.
    Literate.markdown — Function
    Literate.markdown(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)
    Generate a markdown file from inputfile and write the result to the directory outputdir.
    See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.
    source
    Markdown flavors
    Literate can output markdown in different flavors. The flavor is specified using the flavor keyword argument. The following flavors are currently supported:
    • flavor = Literate.DocumenterFlavor(): this is the default flavor and the output is meant to be used as input to Documenter.jl.
    • flavor = Literate.CommonMarkFlavor(): this outputs markdown that has the flavor of the CommonMark specification.
    • flavor = Literate.FranklinFlavor(): this outputs markdown meant to be used as input to Franklin.jl.
    • flavor = Literate.QuartoFlavor(): this outputs markdown file (with file extension .qmd) meant to be used with Quarto CLI.
    Quarto flavor
    Experimental feature
    Quarto markdown output is marked as and experimental feature since it has not been widely tested. Quarto-specific syntax may change before Literate version 3 depending on what the community wants and/or needs. If you use this flavor non-interactively (such as automatically building documentation) it is recommended to pin Literate to a good known version.
    Quarto is an open-source scientific and technical publishing system, which can extend the range of output formats from your Literate.jl-formatted scripts. Literate.jl will produce a .qmd file, which can be used as input to Quarto CLI to produce a variety of output formats, including HTML, PDF, Word and RevealJS slides.
    Literate + Quarto syntax tips
    • #(hashtag followed by a space) at the beginning of a line will be stripped and anything that follows will rendered as a markdown, e.g., # # Header level 1 in your script will be rendered as # Header level 1 in your .qmd file (ie, it will show as a header). Use this for adding the YAML header at the top or any Markdown blocks in the Quarto guide.
    • ##|(two hashtags followed by a pipe) at the beginning of a line will strip the first hashtag and interpret the remainder of the line as part of the code block. This is useful to provide Quarto commands in computation blocks, e.g., ##! echo: false would be rendered as #| echo: false and would tell Quarto not to "echo" the outputs of the execution (see Guide: Executions options for more commands).
    • Make sure to always provide the YAML header and specify IJulia kernel when executing the file by Quarto, e.g.,
      # ---
 # title: "My Report"
 # jupyter: julia-1.9
-# ---
      Notice how all lines are escaped with a # so Literate.jl knows to strip the hashtags and render it as markdown (see Authoring Tutorial for more examples)
    • If any markdown components (e.g. headers) are not rendering correctly in your Quarto outputs, make sure they are surrounded by empty lines (e.g., add an empty line before and after the header) to help Quarto parse them correctly
    Configuring Quarto for Julia code execution
    • Install Quarto CLI
    • Run quarto check to ensure all is installed correctly (you will need Python, Jupyter, and IJulia kernel, see Getting Started)
    Steps to create reports
    • Make sure you have the right header specifying which IJulia kernel to use (e.g. jupyter: julia-1.9), otherwise Quarto will use the default Python kernel.
    • Convert your Literate.jl script to a .qmd file, e.g.
      Literate.markdown("my_script.jl", flavor = Literate.QuartoFlavor())
    • Run Quarto CLI to produce your desired output format, e.g.
      quarto render my_script.qmd --to html
    4.2. Notebook output
    Notebook output is generated by Literate.notebook. The (default) notebook output of the source snippet can be seen here: notebook.ipynb.
    We note that lines starting with # are placed in markdown cells, and the code lines have been placed in code cells. By default the notebook is also executed and output cells populated. The current working directory is set to the specified output directory the notebook is executed.
    See the section about Configuration for how to configure the behavior and resulting output of Literate.notebook.
    Literate.notebook — Function
    Literate.notebook(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)
    Generate a notebook from inputfile and write the result to outputdir.
    See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.
    source
    Notebook metadata
    Jupyter notebook cells (both code cells and markdown cells) can contain metadata. This is enabled in Literate by the %% token, similar to Jupytext. The format is as follows
    %% optional ignored text [type] {optional metadata JSON}
    Cell metadata can, for example, be used for nbgrader and the reveal.js notebook extension RISE.
    The following would create a 3 slide deck with RISE:
    #nb # %% A slide [markdown] {"slideshow": {"slide_type": "slide"}}
+# ---
    Notice how all lines are escaped with a # so Literate.jl knows to strip the hashtags and render it as markdown (see Authoring Tutorial for more examples)
  • If any markdown components (e.g. headers) are not rendering correctly in your Quarto outputs, make sure they are surrounded by empty lines (e.g., add an empty line before and after the header) to help Quarto parse them correctly
Configuring Quarto for Julia code execution
  • Install Quarto CLI
  • Run quarto check to ensure all is installed correctly (you will need Python, Jupyter, and IJulia kernel, see Getting Started)
Steps to create reports
  • Make sure you have the right header specifying which IJulia kernel to use (e.g. jupyter: julia-1.9), otherwise Quarto will use the default Python kernel.
  • Convert your Literate.jl script to a .qmd file, e.g.
    Literate.markdown("my_script.jl", flavor = Literate.QuartoFlavor())
  • Run Quarto CLI to produce your desired output format, e.g.
    quarto render my_script.qmd --to html
4.2. Notebook output
Notebook output is generated by Literate.notebook. The (default) notebook output of the source snippet can be seen here: notebook.ipynb.
We note that lines starting with # are placed in markdown cells, and the code lines have been placed in code cells. By default the notebook is also executed and output cells populated. The current working directory is set to the specified output directory the notebook is executed.
See the section about Configuration for how to configure the behavior and resulting output of Literate.notebook.
Literate.notebook — Function
Literate.notebook(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)
Generate a notebook from inputfile and write the result to outputdir.
See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.
source
Notebook metadata
Jupyter notebook cells (both code cells and markdown cells) can contain metadata. This is enabled in Literate by the %% token, similar to Jupytext. The format is as follows
%% optional ignored text [type] {optional metadata JSON}
Cell metadata can, for example, be used for nbgrader and the reveal.js notebook extension RISE.
The following would create a 3 slide deck with RISE:
#nb # %% A slide [markdown] {"slideshow": {"slide_type": "slide"}}
 # # Some title
 #
 # We're using `#nb` so the metadata is only included in notebook output
@@ -59,4 +59,4 @@
 
 y = 2//5
 
-z = x + y
We note that lines starting with # are removed and only the code lines have been kept.
See the section about Configuration for how to configure the behavior and resulting output of Literate.script.
Literate.script — Function
Literate.script(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)
Generate a plain script file from inputfile and write the result to outputdir.
See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.
source
4.4. Configuration
The behavior of Literate.markdown, Literate.notebook and Literate.script can be configured by keyword arguments. There are two ways to do this; pass config::Dict as a keyword argument, or pass individual keyword arguments.
Configuration precedence
Individual keyword arguments take precedence over the config dictionary, so for e.g. Literate.markdown(...; config = Dict("name" => "hello"), name = "world") the resulting configuration for name will be "world". Both individual keyword arguments and the config dictionary take precedence over the default.
Available configurations with description and default values are given in the reference for Literate.DEFAULT_CONFIGURATION just below.
Literate.DEFAULT_CONFIGURATION — Constant
DEFAULT_CONFIGURATION
Default configuration for Literate.markdown, Literate.notebook and Literate.script which is used for everything not specified by the user. Configuration can be passed as individual keyword arguments or as a dictionary passed with the config keyword argument. See the manual section about Configuration for more information.
Available options:
  • name (default: filename(inputfile)): Name of the output file (excluding the file extension).
  • preprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.
  • postprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.
  • credit (default: true): Boolean for controlling the addition of This file was generated with Literate.jl ... to the bottom of the page. If you find Literate.jl useful then feel free to keep this.
  • keep_comments (default: false): When true, keeps markdown lines as comments in the output script. Only applicable for Literate.script.
  • execute (default: true for notebook, false for markdown): Whether to execute and capture the output. Only applicable for Literate.notebook and Literate.markdown.
  • codefence (default: "````@example $(name)" => "````" for DocumenterFlavor() and "````julia" => "````" otherwise): Pair containing opening and closing code fence for wrapping code blocks.
  • flavor (default: Literate.DocumenterFlavor()) Output flavor for markdown, see Markdown flavors. Only applicable for Literate.markdown.
  • devurl (default: "dev"): URL for "in-development" docs, see Documenter docs. Unused if repo_root_url/ nbviewer_root_url/binder_root_url are set.
  • softscope (default: true for Jupyter notebooks, false otherwise): enable/disable "soft" scoping rules when executing, see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl.
  • repo_root_url: URL to the root of the repository. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__REPO_ROOT_URL__.
  • nbviewer_root_url: URL to the root of the repository as seen on nbviewer. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__NBVIEWER_ROOT_URL__.
  • binder_root_url: URL to the root of the repository as seen on mybinder. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__BINDER_ROOT_URL__.
  • image_formats: A vector of (mime, ext) tuples, with the default Tuple{MIME, String}[(MIME type image/svg+xml, ".svg"), (MIME type image/png, ".png"), (MIME type image/jpeg, ".jpeg")]. Results which are showable with a MIME type are saved with the first match, with the corresponding extension.
source

+z = x + y

We note that lines starting with # are removed and only the code lines have been kept.

See the section about Configuration for how to configure the behavior and resulting output of Literate.script.

Literate.script — Function
Literate.script(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)

Generate a plain script file from inputfile and write the result to outputdir.

See the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.

source

4.4. Configuration

The behavior of Literate.markdown, Literate.notebook and Literate.script can be configured by keyword arguments. There are two ways to do this; pass config::Dict as a keyword argument, or pass individual keyword arguments.

Configuration precedence

Individual keyword arguments take precedence over the config dictionary, so for e.g. Literate.markdown(...; config = Dict("name" => "hello"), name = "world") the resulting configuration for name will be "world". Both individual keyword arguments and the config dictionary take precedence over the default.

Available configurations with description and default values are given in the reference for Literate.DEFAULT_CONFIGURATION just below.

Literate.DEFAULT_CONFIGURATION — Constant
DEFAULT_CONFIGURATION

Default configuration for Literate.markdown, Literate.notebook and Literate.script which is used for everything not specified by the user. Configuration can be passed as individual keyword arguments or as a dictionary passed with the config keyword argument. See the manual section about Configuration for more information.

Available options:

  • name (default: filename(inputfile)): Name of the output file (excluding the file extension).
  • preprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.
  • postprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.
  • credit (default: true): Boolean for controlling the addition of This file was generated with Literate.jl ... to the bottom of the page. If you find Literate.jl useful then feel free to keep this.
  • keep_comments (default: false): When true, keeps markdown lines as comments in the output script. Only applicable for Literate.script.
  • execute (default: true for notebook, false for markdown): Whether to execute and capture the output. Only applicable for Literate.notebook and Literate.markdown.
  • codefence (default: "````@example $(name)" => "````" for DocumenterFlavor() and "````julia" => "````" otherwise): Pair containing opening and closing code fence for wrapping code blocks.
  • flavor (default: Literate.DocumenterFlavor()) Output flavor for markdown, see Markdown flavors. Only applicable for Literate.markdown.
  • devurl (default: "dev"): URL for "in-development" docs, see Documenter docs. Unused if repo_root_url/ nbviewer_root_url/binder_root_url are set.
  • softscope (default: true for Jupyter notebooks, false otherwise): enable/disable "soft" scoping rules when executing, see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl.
  • repo_root_url: URL to the root of the repository. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__REPO_ROOT_URL__.
  • nbviewer_root_url: URL to the root of the repository as seen on nbviewer. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__NBVIEWER_ROOT_URL__.
  • binder_root_url: URL to the root of the repository as seen on mybinder. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__BINDER_ROOT_URL__.
  • image_formats: A vector of (mime, ext) tuples, with the default Tuple{MIME, String}[(MIME type image/svg+xml, ".svg"), (MIME type image/png, ".png"), (MIME type image/jpeg, ".jpeg")]. Results which are showable with a MIME type are saved with the first match, with the corresponding extension.
source
diff --git a/dev/pipeline/index.html b/dev/pipeline/index.html index ef2e8e19..f64a5a2f 100644 --- a/dev/pipeline/index.html +++ b/dev/pipeline/index.html @@ -1,5 +1,5 @@ -3. Processing pipeline · Literate.jl
GitHub

3. Processing pipeline

The generation of output follows the same pipeline for all output formats:

  1. Pre-processing
  2. Parsing
  3. Document generation
  4. Post-processing
  5. Writing to file

3.1. Pre-processing

The first step is pre-processing of the input file. The file is read to a String. The first processing step is to apply the user specified pre-processing function, see Custom pre- and post-processing.

The next step is to perform all of the built-in default replacements. CRLF style line endings ("\r\n") are replaced with LF line endings ("\n") to simplify internal processing. Next, line filtering is performed, see Filtering lines, meaning that lines starting with #md, #nb or #jl are handled (either just the token itself is removed, or the full line, depending on the output target). The last pre-processing step is to expand the convenience "macros" described in Default replacements is expanded.

3.2. Parsing

After the preprocessing the file is parsed. The first step is to categorize each line and mark them as either markdown or code according to the rules described in the Syntax section. Lets consider the example from the previous section with each line categorized:

# # Rational numbers                                                     <- markdown
+3. Processing pipeline · Literate.jl
GitHub
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
  1. Pre-processing
  2. Parsing
  3. Document generation
  4. Post-processing
  5. Writing to file
3.1. Pre-processing
The first step is pre-processing of the input file. The file is read to a String. The first processing step is to apply the user specified pre-processing function, see Custom pre- and post-processing.
The next step is to perform all of the built-in default replacements. CRLF style line endings ("\r\n") are replaced with LF line endings ("\n") to simplify internal processing. Next, line filtering is performed, see Filtering lines, meaning that lines starting with #md, #nb or #jl are handled (either just the token itself is removed, or the full line, depending on the output target). The last pre-processing step is to expand the convenience "macros" described in Default replacements is expanded.
3.2. Parsing
After the preprocessing the file is parsed. The first step is to categorize each line and mark them as either markdown or code according to the rules described in the Syntax section. Lets consider the example from the previous section with each line categorized:
# # Rational numbers                                                     <- markdown
 #                                                                        <- markdown
 # In julia rational numbers can be constructed with the `//` operator.   <- markdown
 # Lets define two rational numbers, `x` and `y`:                         <- markdown
@@ -29,4 +29,4 @@
 y = 2 // 5
Chunk #3:
When adding `x` and `y` together we obtain a new rational number:
Chunk #4:
z = x + y
It is then up to the Document generation step to decide how these chunks should be treated.
Custom control over chunk splits
Sometimes it is convenient to be able to manually control how the chunks are split. For example, if you want to split a block of code into two, such that they end up in two different @example blocks or notebook cells. The #- token can be used for this purpose. All lines starting with #- are used as "chunk-splitters":
x = 1 // 3
 y = 2 // 5
 #-
-z = x + y
The example above would result in two consecutive code-chunks.
Tip
The rest of the line, after #-, is discarded, so it is possible to use e.g. #------------- as a chunk splitter, which may make the source code more readable.
It is also possible to use #+ as a chunk splitter. The difference between #+ and #- is that #+ enables Documenter's "continued"-blocks, see the Documenter manual.
3.3. Document generation
After the parsing it is time to generate the output. What is done in this step is very different depending on the output target, and it is described in more detail in the Output format sections: Markdown output, Notebook output and Script output. Using the default settings, the following is happening:
  • Markdown output: markdown chunks are printed as-is, code chunks are put inside a code fence (defaults to @example-blocks),
  • Notebook output: markdown chunks are printed in markdown cells, code chunks are put in code cells,
  • Script output: markdown chunks are discarded, code chunks are printed as-is.
3.4. Post-processing
When the document is generated the user, again, has the option to hook-into the generation with a custom post-processing function. The reason is that one might want to change things that are only visible in the rendered document. See Custom pre- and post-processing.
3.5. Writing to file
The last step of the generation is writing to file. The result is written to $(outputdir)/$(name)(.md|.ipynb|.jl) where outputdir is the output directory supplied by the user (for example docs/generated), and name is a user supplied filename. It is recommended to add the output directory to .gitignore since the idea is that the generated documents will be generated as part of the build process rather than being files in the repo.

+z = x + y

The example above would result in two consecutive code-chunks.

Tip

The rest of the line, after #-, is discarded, so it is possible to use e.g. #------------- as a chunk splitter, which may make the source code more readable.

It is also possible to use #+ as a chunk splitter. The difference between #+ and #- is that #+ enables Documenter's "continued"-blocks, see the Documenter manual.

3.3. Document generation

After the parsing it is time to generate the output. What is done in this step is very different depending on the output target, and it is described in more detail in the Output format sections: Markdown output, Notebook output and Script output. Using the default settings, the following is happening:

  • Markdown output: markdown chunks are printed as-is, code chunks are put inside a code fence (defaults to @example-blocks),
  • Notebook output: markdown chunks are printed in markdown cells, code chunks are put in code cells,
  • Script output: markdown chunks are discarded, code chunks are printed as-is.

3.4. Post-processing

When the document is generated the user, again, has the option to hook-into the generation with a custom post-processing function. The reason is that one might want to change things that are only visible in the rendered document. See Custom pre- and post-processing.

3.5. Writing to file

The last step of the generation is writing to file. The result is written to $(outputdir)/$(name)(.md|.ipynb|.jl) where outputdir is the output directory supplied by the user (for example docs/generated), and name is a user supplied filename. It is recommended to add the output directory to .gitignore since the idea is that the generated documents will be generated as part of the build process rather than being files in the repo.

diff --git a/dev/reference/index.html b/dev/reference/index.html index 94a579f5..e80ecc3c 100644 --- a/dev/reference/index.html +++ b/dev/reference/index.html @@ -1,2 +1,2 @@ -Reference · Literate.jl
GitHub

Reference

Literate — Module
Literate

Julia package for Literate Programming. See https://fredrikekre.github.io/Literate.jl/ for documentation.

source
+Reference · Literate.jl
GitHub

Reference

Literate — Module
Literate

Julia package for Literate Programming. See https://fredrikekre.github.io/Literate.jl/ for documentation.

source
diff --git a/dev/search_index.js b/dev/search_index.js index b15cce39..a0547fd7 100644 --- a/dev/search_index.js +++ b/dev/search_index.js @@ -1,3 +1,3 @@ var documenterSearchIndex = {"docs": -[{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"EditURL = \"../outputformats.jl\"","category":"page"},{"location":"generated/name/#Rational-numbers","page":"Rational numbers","title":"Rational numbers","text":"","category":"section"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"In julia rational numbers can be constructed with the // operator. Lets define two rational numbers, x and y:","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"x = 1//3","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"y = 2//5","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"When adding x and y together we obtain a new rational number:","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"z = x + y","category":"page"},{"location":"pipeline/#Processing-pipeline","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The generation of output follows the same pipeline for all output formats:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Pre-processing\nParsing\nDocument generation\nPost-processing\nWriting to file","category":"page"},{"location":"pipeline/#Pre-processing","page":"3. Processing pipeline","title":"3.1. Pre-processing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The first step is pre-processing of the input file. The file is read to a String. The first processing step is to apply the user specified pre-processing function, see Custom pre- and post-processing.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The next step is to perform all of the built-in default replacements. CRLF style line endings (\"\\r\\n\") are replaced with LF line endings (\"\\n\") to simplify internal processing. Next, line filtering is performed, see Filtering lines, meaning that lines starting with #md, #nb or #jl are handled (either just the token itself is removed, or the full line, depending on the output target). The last pre-processing step is to expand the convenience \"macros\" described in Default replacements is expanded.","category":"page"},{"location":"pipeline/#Parsing","page":"3. Processing pipeline","title":"3.2. Parsing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"After the preprocessing the file is parsed. The first step is to categorize each line and mark them as either markdown or code according to the rules described in the Syntax section. Lets consider the example from the previous section with each line categorized:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# # Rational numbers <- markdown\n# <- markdown\n# In julia rational numbers can be constructed with the `//` operator. <- markdown\n# Lets define two rational numbers, `x` and `y`: <- markdown\n <- code\n## Define variable x and y <- code\nx = 1 // 3 <- code\ny = 2 // 5 <- code\n <- code\n# When adding `x` and `y` together we obtain a new rational number: <- markdown\n <- code\nz = x + y <- code","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"In the next step the lines are grouped into \"chunks\" of markdown and code. This is done by simply collecting adjacent lines of the same \"type\" into chunks:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# # Rational numbers ┐\n# │\n# In julia rational numbers can be constructed with the `//` operator. │ markdown\n# Lets define two rational numbers, `x` and `y`: ┘\n ┐\n## Define variable x and y │\nx = 1 // 3 │\ny = 2 // 5 │ code\n ┘\n# When adding `x` and `y` together we obtain a new rational number: ] markdown\n ┐\nz = x + y ┘ code","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"In the last parsing step all empty leading and trailing lines for each chunk are removed, but empty lines within the same block are kept. The leading # tokens are also removed from the markdown chunks. Finally we would end up with the following 4 chunks:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunks #1:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# Rational numbers\n\nIn julia rational numbers can be constructed with the `//` operator.\nLets define two rational numbers, `x` and `y`:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #2:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# Define variable x and y\nx = 1 // 3\ny = 2 // 5","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #3:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"When adding `x` and `y` together we obtain a new rational number:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #4:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"z = x + y","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"It is then up to the Document generation step to decide how these chunks should be treated.","category":"page"},{"location":"pipeline/#Custom-control-over-chunk-splits","page":"3. Processing pipeline","title":"Custom control over chunk splits","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Sometimes it is convenient to be able to manually control how the chunks are split. For example, if you want to split a block of code into two, such that they end up in two different @example blocks or notebook cells. The #- token can be used for this purpose. All lines starting with #- are used as \"chunk-splitters\":","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"x = 1 // 3\ny = 2 // 5\n#-\nz = x + y","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The example above would result in two consecutive code-chunks.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"tip: Tip\nThe rest of the line, after #-, is discarded, so it is possible to use e.g. #------------- as a chunk splitter, which may make the source code more readable.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"It is also possible to use #+ as a chunk splitter. The difference between #+ and #- is that #+ enables Documenter's \"continued\"-blocks, see the Documenter manual.","category":"page"},{"location":"pipeline/#Document-generation","page":"3. Processing pipeline","title":"3.3. Document generation","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"After the parsing it is time to generate the output. What is done in this step is very different depending on the output target, and it is described in more detail in the Output format sections: Markdown output, Notebook output and Script output. Using the default settings, the following is happening:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Markdown output: markdown chunks are printed as-is, code chunks are put inside a code fence (defaults to @example-blocks),\nNotebook output: markdown chunks are printed in markdown cells, code chunks are put in code cells,\nScript output: markdown chunks are discarded, code chunks are printed as-is.","category":"page"},{"location":"pipeline/#Post-processing","page":"3. Processing pipeline","title":"3.4. Post-processing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"When the document is generated the user, again, has the option to hook-into the generation with a custom post-processing function. The reason is that one might want to change things that are only visible in the rendered document. See Custom pre- and post-processing.","category":"page"},{"location":"pipeline/#Writing-to-file","page":"3. Processing pipeline","title":"3.5. Writing to file","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The last step of the generation is writing to file. The result is written to $(outputdir)/$(name)(.md|.ipynb|.jl) where outputdir is the output directory supplied by the user (for example docs/generated), and name is a user supplied filename. It is recommended to add the output directory to .gitignore since the idea is that the generated documents will be generated as part of the build process rather than being files in the repo.","category":"page"},{"location":"documenter/#Interaction-with-Documenter","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Literate can be used for any purpose, it spits out regular markdown files, and notebooks. Typically, though, these files will be used to render documentation for your package. The generators (Literate.markdown, Literate.notebook and Literate.script) supports a keyword argument documenter that lets the generator perform some extra things, keeping in mind that the source code have been written with Documenter.jl in mind. So let's take a look at what will happen if we set documenter = true:","category":"page"},{"location":"documenter/#[Literate.markdown](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.markdown:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"The default code fence will change from\n```julia\n# code\n```\nto Documenters @example blocks:\n```@examples $(name)\n# code\n```\nThe following @meta block will be added to the top of the markdown page, which redirects the \"Edit on GitHub\" link on the top of the page to the source file rather than the generated .md file:\n```@meta\nEditURL = \"$(relpath(inputfile, outputdir))\"\n```","category":"page"},{"location":"documenter/#[Literate.notebook](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.notebook:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Documenter style @refs and @id will be removed. This means that you can use @ref and @id in the source file without them leaking to the notebook.\nDocumenter style markdown math\n```math\n\\int f dx\n```\nis replaced with notebook compatible\n$$\n\\int f dx\n$$\nWhereas Documenter requires HTML blocks to be escaped\n```@raw html\n...\n```\nthe output to a notebook markdown cell will be raw HTML\n...","category":"page"},{"location":"documenter/#[Literate.script](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.script:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Documenter style @refs and @id will be removed. This means that you can use @ref and @id in the source file without them leaking to the script.","category":"page"},{"location":"customprocessing/#Custom-pre-and-post-processing","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"All of the generators (Literate.markdown, Literate.notebook and Literate.script) accept preprocess and postprocess keyword arguments. The default \"transformation\" is the identity function. The input to the transformation functions is a String, and the output should be the transformed String.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"preprocess is sent the raw input that is read from the source file (modulo the default line ending transformation). postprocess is given different things depending on the output: For markdown and script output postprocess is given the content String just before writing it to the output file, but for notebook output postprocess is given the dictionary representing the notebook, since, in general, this is more useful.","category":"page"},{"location":"customprocessing/#Example:-Adding-current-date","page":"5. Custom pre- and post-processing","title":"Example: Adding current date","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"As an example, lets say we want to splice the date of generation into the output. We could of course update our source file before generating the docs, but we could instead use a preprocess function that splices the date into the source for us. Consider the following source file:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"# # Example\n# This example was generated DATEOFTODAY\n\nx = 1 // 3","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"where DATEOFTODAY is a placeholder, to make it easier for our preprocess function to find the location. Now, lets define the preprocess function, for example","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"function update_date(content)\n content = replace(content, \"DATEOFTODAY\" => Date(now()))\n return content\nend","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"which would replace every occurrence of \"DATEOFTODAY\" with the current date. We would now simply give this function to the generator, for example:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Literate.markdown(\"input.jl\", \"outputdir\"; preprocess = update_date)","category":"page"},{"location":"customprocessing/#Example:-Replacing-include-calls-with-included-code","page":"5. Custom pre- and post-processing","title":"Example: Replacing include calls with included code","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Let's say that we have some individual example files file1, file2, ... etc. that are runnable and also following the style of Literate. These files could be for example used in the test suite of your package.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"We want to group them all into a single page in our documentation, but we do not want to copy paste the content of file1, ... for robustness: the files are included in the test suite and some changes may occur to them. We want these changes to also be reflected in the documentation.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"A very easy way to do this is using preprocess to interchange include statements with file content. First, create a runnable .jl following the format of Literate","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"# # Replace includes\n# This is an example to replace `include` calls with the actual file content.\n\ninclude(\"file1.jl\")\n\n# Cool, we just saw the result of the above code snippet. Here is one more:\n\ninclude(\"file2.jl\")","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Let's say we have saved this file as examples.jl. Then, you want to properly define a pre-processing function:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"function replace_includes(str)\n\n included = [\"file1.jl\", \"file2.jl\"]\n\n # Here the path loads the files from their proper directory,\n # which may not be the directory of the `examples.jl` file!\n path = \"directory/to/example/files/\"\n\n for ex in included\n content = read(path*ex, String)\n str = replace(str, \"include(\\\"$(ex)\\\")\" => content)\n end\n return str\nend","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"(of course replace included with your respective files)","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Finally, you simply pass this function to e.g. Literate.markdown as","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Literate.markdown(\"examples.jl\", \"path/to/save/markdown\";\n name = \"markdown_file_name\", preprocess = replace_includes)","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"and you will see that in the final output file (here markdown_file_name.md) the include statements are replaced with the actual code to be included!","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"This approach is used for generating the examples in the documentation of the TimeseriesPrediction.jl package. The example files, included together in the stexamples.jl file, are processed by literate via this make.jl file to generate the markdown and code cells of the documentation.","category":"page"},{"location":"outputformats/#Output-formats","page":"4. Output formats","title":"4. Output formats","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"When the source is parsed, and has been processed it is time to render the output. We will consider the following source snippet:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nMarkdown.parse(\"```julia\\n\" * rstrip(read(\"outputformats.jl\", String)) * \"\\n```\")","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"and see how this is rendered in each of the output formats.","category":"page"},{"location":"outputformats/#Markdown-output","page":"4. Output formats","title":"4.1. Markdown output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Markdown output is generated by Literate.markdown. There exist various \"flavors\" of markdown and Literate supports some different flavors, see Markdown flavors. The default flavor is Literate.DocumenterFlavor() and, as the name suggest, it generates markdown files meant to be used together with Documenter.jl. The output of the source snippet above is as follows:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nfile = joinpath(@__DIR__, \"../src/generated/name.md\")\nstr = \"`````markdown\\n\" * rstrip(read(file, String)) * \"\\n`````\"\nrm(file)\nMarkdown.parse(str)","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are printed as regular markdown, and the code lines have been wrapped in @example blocks. We also note that an @meta block have been added, that sets the EditURL variable. This is used by Documenter to redirect the \"Edit on GitHub\" link for the page, see Interaction with Documenter.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The @example blocks are wrapped in 4 consecutive backticks so as to allow for docstrings containing triple backticks, for example:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"\"\"\"\nThis function perform the following calculation:\n```math\n x_1 + x_2\n```\n\"\"\"\nf(x) = x[1] + x[2]","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"If your Julia code itself contains 4 consecutive backticks, you can use the keyword argument codefence to setup 5 backticks for code blocks, see Configuration.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"It possible to configure Literate.markdown to also evaluate code snippets, capture the result and include it in the output, by passing execute=true as a keyword argument. The result of the first code-block in the example above would then become","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"````julia\nx = 1//3\n````\n````\n1//3\n````","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"In this example the output is just plain text. However, if the resulting value of the code block can be displayed as an image (image/png or image/jpeg), HTML (text/html) or markdown (text/markdown) Literate will include the richest representation of the output.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"note: Note\nSince Documenter executes and captures results of @example block it is not necessary to use execute=true for markdown output that is meant to be used as input to Documenter.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for more information about how to configure the behavior and resulting output of Literate.markdown.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.markdown","category":"page"},{"location":"outputformats/#Literate.markdown","page":"4. Output formats","title":"Literate.markdown","text":"Literate.markdown(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a markdown file from inputfile and write the result to the directory outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Markdown-flavors","page":"4. Output formats","title":"Markdown flavors","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate can output markdown in different flavors. The flavor is specified using the flavor keyword argument. The following flavors are currently supported:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"flavor = Literate.DocumenterFlavor(): this is the default flavor and the output is meant to be used as input to Documenter.jl.\nflavor = Literate.CommonMarkFlavor(): this outputs markdown that has the flavor of the CommonMark specification.\nflavor = Literate.FranklinFlavor(): this outputs markdown meant to be used as input to Franklin.jl.\nflavor = Literate.QuartoFlavor(): this outputs markdown file (with file extension .qmd) meant to be used with Quarto CLI.","category":"page"},{"location":"outputformats/#Quarto-flavor","page":"4. Output formats","title":"Quarto flavor","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"warning: Experimental feature\nQuarto markdown output is marked as and experimental feature since it has not been widely tested. Quarto-specific syntax may change before Literate version 3 depending on what the community wants and/or needs. If you use this flavor non-interactively (such as automatically building documentation) it is recommended to pin Literate to a good known version.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Quarto is an open-source scientific and technical publishing system, which can extend the range of output formats from your Literate.jl-formatted scripts. Literate.jl will produce a .qmd file, which can be used as input to Quarto CLI to produce a variety of output formats, including HTML, PDF, Word and RevealJS slides.","category":"page"},{"location":"outputformats/#Literate-Quarto-syntax-tips","page":"4. Output formats","title":"Literate + Quarto syntax tips","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"#(hashtag followed by a space) at the beginning of a line will be stripped and anything that follows will rendered as a markdown, e.g., # # Header level 1 in your script will be rendered as # Header level 1 in your .qmd file (ie, it will show as a header). Use this for adding the YAML header at the top or any Markdown blocks in the Quarto guide.\n##|(two hashtags followed by a pipe) at the beginning of a line will strip the first hashtag and interpret the remainder of the line as part of the code block. This is useful to provide Quarto commands in computation blocks, e.g., ##! echo: false would be rendered as #| echo: false and would tell Quarto not to \"echo\" the outputs of the execution (see Guide: Executions options for more commands).\nMake sure to always provide the YAML header and specify IJulia kernel when executing the file by Quarto, e.g.,\n# ---\n# title: \"My Report\"\n# jupyter: julia-1.9\n# ---\nNotice how all lines are escaped with a # so Literate.jl knows to strip the hashtags and render it as markdown (see Authoring Tutorial for more examples)\nIf any markdown components (e.g. headers) are not rendering correctly in your Quarto outputs, make sure they are surrounded by empty lines (e.g., add an empty line before and after the header) to help Quarto parse them correctly","category":"page"},{"location":"outputformats/#Configuring-Quarto-for-Julia-code-execution","page":"4. Output formats","title":"Configuring Quarto for Julia code execution","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Install Quarto CLI\nRun quarto check to ensure all is installed correctly (you will need Python, Jupyter, and IJulia kernel, see Getting Started)","category":"page"},{"location":"outputformats/#Steps-to-create-reports","page":"4. Output formats","title":"Steps to create reports","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Make sure you have the right header specifying which IJulia kernel to use (e.g. jupyter: julia-1.9), otherwise Quarto will use the default Python kernel.\nConvert your Literate.jl script to a .qmd file, e.g.\nLiterate.markdown(\"my_script.jl\", flavor = Literate.QuartoFlavor())\nRun Quarto CLI to produce your desired output format, e.g.\nquarto render my_script.qmd --to html","category":"page"},{"location":"outputformats/#Notebook-output","page":"4. Output formats","title":"4.2. Notebook output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Notebook output is generated by Literate.notebook. The (default) notebook output of the source snippet can be seen here: notebook.ipynb.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are placed in markdown cells, and the code lines have been placed in code cells. By default the notebook is also executed and output cells populated. The current working directory is set to the specified output directory the notebook is executed.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for how to configure the behavior and resulting output of Literate.notebook.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.notebook","category":"page"},{"location":"outputformats/#Literate.notebook","page":"4. Output formats","title":"Literate.notebook","text":"Literate.notebook(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a notebook from inputfile and write the result to outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Notebook-metadata","page":"4. Output formats","title":"Notebook metadata","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Jupyter notebook cells (both code cells and markdown cells) can contain metadata. This is enabled in Literate by the %% token, similar to Jupytext. The format is as follows","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"%% optional ignored text [type] {optional metadata JSON}","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Cell metadata can, for example, be used for nbgrader and the reveal.js notebook extension RISE.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The following would create a 3 slide deck with RISE:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"#nb # %% A slide [markdown] {\"slideshow\": {\"slide_type\": \"slide\"}}\n# # Some title\n#\n# We're using `#nb` so the metadata is only included in notebook output\n\n#nb %% A slide [code] {\"slideshow\": {\"slide_type\": \"fragment\"}}\nx = 1//3\ny = 2//5\n\n#nb # %% A slide [markdown] {\"slideshow\": {\"slide_type\": \"subslide\"}}\n# For more information about RISE, see [the docs](https://rise.readthedocs.io/en/stable/usage.html)","category":"page"},{"location":"outputformats/#Script-output","page":"4. Output formats","title":"4.3. Script output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Script output is generated by Literate.script. The (default) script output of the source snippet above is as follows:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nfile = joinpath(@__DIR__, \"../src/generated/outputformats.jl\")\nstr = \"```julia\\n\" * rstrip(read(file, String)) * \"\\n```\"\nrm(file)\nMarkdown.parse(str)","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are removed and only the code lines have been kept.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for how to configure the behavior and resulting output of Literate.script.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.script","category":"page"},{"location":"outputformats/#Literate.script","page":"4. Output formats","title":"Literate.script","text":"Literate.script(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a plain script file from inputfile and write the result to outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Configuration","page":"4. Output formats","title":"4.4. Configuration","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The behavior of Literate.markdown, Literate.notebook and Literate.script can be configured by keyword arguments. There are two ways to do this; pass config::Dict as a keyword argument, or pass individual keyword arguments.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"note: Configuration precedence\nIndividual keyword arguments take precedence over the config dictionary, so for e.g. Literate.markdown(...; config = Dict(\"name\" => \"hello\"), name = \"world\") the resulting configuration for name will be \"world\". Both individual keyword arguments and the config dictionary take precedence over the default.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Available configurations with description and default values are given in the reference for Literate.DEFAULT_CONFIGURATION just below.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.DEFAULT_CONFIGURATION","category":"page"},{"location":"outputformats/#Literate.DEFAULT_CONFIGURATION","page":"4. Output formats","title":"Literate.DEFAULT_CONFIGURATION","text":"DEFAULT_CONFIGURATION\n\nDefault configuration for Literate.markdown, Literate.notebook and Literate.script which is used for everything not specified by the user. Configuration can be passed as individual keyword arguments or as a dictionary passed with the config keyword argument. See the manual section about Configuration for more information.\n\nAvailable options:\n\nname (default: filename(inputfile)): Name of the output file (excluding the file extension).\npreprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.\npostprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.\ncredit (default: true): Boolean for controlling the addition of This file was generated with Literate.jl ... to the bottom of the page. If you find Literate.jl useful then feel free to keep this.\nkeep_comments (default: false): When true, keeps markdown lines as comments in the output script. Only applicable for Literate.script.\nexecute (default: true for notebook, false for markdown): Whether to execute and capture the output. Only applicable for Literate.notebook and Literate.markdown.\ncodefence (default: \"````@example $(name)\" => \"````\" for DocumenterFlavor() and \"````julia\" => \"````\" otherwise): Pair containing opening and closing code fence for wrapping code blocks.\nflavor (default: Literate.DocumenterFlavor()) Output flavor for markdown, see Markdown flavors. Only applicable for Literate.markdown.\ndevurl (default: \"dev\"): URL for \"in-development\" docs, see Documenter docs. Unused if repo_root_url/ nbviewer_root_url/binder_root_url are set.\nsoftscope (default: true for Jupyter notebooks, false otherwise): enable/disable \"soft\" scoping rules when executing, see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl.\nrepo_root_url: URL to the root of the repository. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__REPO_ROOT_URL__.\nnbviewer_root_url: URL to the root of the repository as seen on nbviewer. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__NBVIEWER_ROOT_URL__.\nbinder_root_url: URL to the root of the repository as seen on mybinder. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__BINDER_ROOT_URL__.\nimage_formats: A vector of (mime, ext) tuples, with the default Tuple{MIME, String}[(MIME type image/svg+xml, \".svg\"), (MIME type image/png, \".png\"), (MIME type image/jpeg, \".jpeg\")]. Results which are showable with a MIME type are saved with the first match, with the corresponding extension.\n\n\n\n\n\n","category":"constant"},{"location":"reference/#Reference","page":"Reference","title":"Reference","text":"","category":"section"},{"location":"reference/","page":"Reference","title":"Reference","text":"Literate","category":"page"},{"location":"reference/#Literate","page":"Reference","title":"Literate","text":"Literate\n\nJulia package for Literate Programming. See https://fredrikekre.github.io/Literate.jl/ for documentation.\n\n\n\n\n\n","category":"module"},{"location":"fileformat/#File-format","page":"2. File format","title":"2. File format","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The source file format for Literate is a regular, commented, julia (.jl) scripts. The idea is that the scripts also serve as documentation on their own and it is also simple to include them in the test-suite, with e.g. include, to make sure the examples stay up to date with other changes in your package.","category":"page"},{"location":"fileformat/#Syntax","page":"2. File format","title":"2.1. Syntax","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The basic syntax is simple:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"lines starting with # are treated as markdown,\nall other lines are treated as julia code.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Leading whitespace is allowed before #, but it will be removed when generating the output. Since #-lines are treated as markdown we can not use that for regular julia comments, for this you can instead use ##, which will render as # in the output.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Lets look at a simple example:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# # Rational numbers\n#\n# In julia rational numbers can be constructed with the `//` operator.\n# Lets define two rational numbers, `x` and `y`:\n\n## Define variable x and y\nx = 1//3\ny = 2//5\n\n# When adding `x` and `y` together we obtain a new rational number:\n\nz = x + y","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"In the lines starting with # we can use regular markdown syntax, for example the # used for the heading and the backticks for formatting code. The other lines are regular julia code. We note a couple of things:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The script is valid julia, which means that we can include it and the example will run (for example in the test/runtests.jl script, to include the example in the test suite).\nThe script is \"self-explanatory\", i.e. the markdown lines works as comments and thus serve as good documentation on its own.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"For simple use this is all you need to know. The following additional special syntax can also be used:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md, #nb, #jl, #src: tags to filter lines, see Filtering lines,\n#- (#+): tag to manually control chunk-splits, see Custom control over chunk splits.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"There is also some default convenience replacements that will always be performed, see Default replacements.","category":"page"},{"location":"fileformat/#Multiline-comments-and-markdown-strings","page":"2. File format","title":"Multiline comments and markdown strings","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Literate version 2.7 adds support for Julia multiline comments for markdown input. All multiline comments in the input are rewritten to regular comments as part of the preprocessing step, before any other processing is performed. For Literate to recognize multiline comments it is required that the start token (#=) and end token (=#) are placed on their own lines. Note also that it is allowed to have more than one = in the tokens, for example","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#=\nThis multiline comment\nis treated as markdown.\n=#\n\n#=====================\nThis is also markdown.\n=====================#","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"is rewritten to","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# This multiline comment\n# is treated as markdown.\n\n# This is also markdown.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Similarly, Literate version 2.9 adds support for using literal markdown strings, md\"\"\" ... \"\"\", for the markdown sections, for example","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"md\"\"\"\n# Title\nblah blah blah\n\"\"\"","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"is rewritten to","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# # Title\n# blah blah blah","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"This is not enabled by default – it requires passing mdstrings=true. Literate.markdown/Literate.notebook/Literate.script.","category":"page"},{"location":"fileformat/#Filtering-lines","page":"2. File format","title":"2.2. Filtering lines","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"It is often useful to filter out lines in the source depending on the output format. For this purpose there are a number of \"tokens\" that can be used to mark the purpose of certain lines:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md: line exclusive to markdown output,\n#nb: line exclusive to notebook output,\n#jl: line exclusive to script output,\n#src: line exclusive to the source code and thus filtered out unconditionally.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Lines starting or ending with one of these tokens are filtered out in the preprocessing step. In addition, for markdown output, lines ending with #hide are filtered out similar to Documenter.jl.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"note: Difference between `#src` and `#hide`\n#src and #hide are quite similar. The only difference is that #src lines are filtered out before execution (if execute=true) and #hide lines are filtered out after execution.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"tip: Tip\nThe tokens can also be negated, for example a line starting with #!nb would be included in markdown and script output, but filtered out for notebook output.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Suppose, for example, that we want to include a docstring within a @docs block using Documenter. Obviously we don't want to include this in the notebook, since @docs is Documenter syntax that the notebook will not understand. This is a case where we can prepend #md to those lines:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md # ```@docs\n#md # Literate.markdown\n#md # Literate.notebook\n#md # Literate.script\n#md # ```","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The lines in the example above would be filtered out in the preprocessing step, unless we are generating a markdown file. When generating a markdown file we would simply remove the leading #md from the lines. Beware that the space after the tag is also removed.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The #src token can also be placed at the end of a line. This is to make it possible to have code lines exclusive to the source code, and not just comment lines. For example, if the source file is included in the test suite we might want to add a @test at the end without this showing up in the outputs:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"using Test #src\n@test result == expected_result #src","category":"page"},{"location":"fileformat/#Default-replacements","page":"2. File format","title":"2.3. Default replacements","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The following convenience \"macros\"/source placeholders are always expanded:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"@__NAME__:\nexpands to the name keyword argument to Literate.markdown, Literate.notebook and Literate.script (defaults to the filename of the input file).\n@__REPO_ROOT_URL__:\nCan be used to link to files in the repository. For example @__REPO_ROOT_URL__/src/Literate.jl would link to the source of the Literate module. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.\n@__NBVIEWER_ROOT_URL__:\nCan be used if you want a link that opens the generated notebook in http://nbviewer.jupyter.org/. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.\n@__BINDER_ROOT_URL__:\nCan be used if you want a link that opens the generated notebook in https://mybinder.org/. For example, to add a binder-badge in e.g. the HTML output you can use:\n[![Binder](https://mybinder.org/badge_logo.svg)](@__BINDER_ROOT_URL__/path/to/notebook.inpynb)\nThis variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.","category":"page"},{"location":"#Introduction","page":"1. Introduction","title":"1. Introduction","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Welcome to the documentation for Literate – a simplistic package for Literate Programming.","category":"page"},{"location":"#What?","page":"1. Introduction","title":"What?","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate is a package that generates markdown pages (for e.g. Documenter.jl), and Jupyter notebooks, from the same source file. There is also an option to \"clean\" the source from all metadata, and produce a pure Julia script.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"The main design goal is simplicity. It should be simple to use, and the syntax should be simple. In short, all you have to do is to write a commented julia script!","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"The public interface consists of three functions, all of which take the same script file as input, but generate different output:","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate.markdown generates a markdown file. Code snippets can be executed and the results included in the output.\nLiterate.notebook generates a notebook. Code snippets can be executed and the results included in the output.\nLiterate.script generates a plain script file scrubbed from all metadata and special syntax.","category":"page"},{"location":"#Why?","page":"1. Introduction","title":"Why?","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Examples are (probably) the best way to showcase your awesome package, and examples are often the best way for a new user to learn how to use it. It is therefore important that the documentation of your package contains examples for users to read and study. However, people are different, and we all prefer different ways of trying out a new package. Some people want to RTFM, others want to explore the package interactively in, for example, a notebook, and some people want to study the source code. The aim of Literate is to make it easy to give the user all of these options, while still keeping maintenance to a minimum.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"It is quite common that packages have \"example notebooks\" to showcase the package. Notebooks are great for showcasing a package, but they are not so great with version control, like git. The reason being that a notebook is a very \"rich\" format since it contains output and other metadata. Changes to the notebook thus result in large diffs, which makes it harder to review the actual changes.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"It is also common that packages include examples in the documentation, for example by using Documenter.jl @example-blocks. This is also great, but it is not quite as interactive as a notebook, for the users who prefer that.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate tries to solve the problems above by creating the output as a part of the doc build. Literate generates the output based on a single source file which makes it easier to maintain, test, and keep the manual and your example notebooks in sync.","category":"page"},{"location":"tips/#tips-and-tricks","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This section lists some tips and tricks that might be useful for using Literate.","category":"page"},{"location":"tips/#notebook-filesize","page":"7. Tips and tricks","title":"Filesize of generated notebooks","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"When Literate executes a notebook the return value, i.e. the result of the last Julia expression in each cell is captured. By default Literate generates multiple renderings of the result in different output formats or MIMEs, just like IJulia.jl does. All of these renderings are embedded in the notebook and it is up to the notebook frontend viewer to select the most appropriate format to show to the user.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"A common example is images, which can often be displayed in multiple formats, e.g. PNG (image/png), SVG (image/svg+xml) and HTML (text/html). As a result, the filesize of the generated notebook can become large.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"In order to remedy this you can use the clever Julia package DisplayAs to limit the output capabilities of an object. For example, to \"force\" an image to be captures as image/png only, you can use","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"import DisplayAs\nimg = plot(...)\nimg = DisplayAs.PNG(img)","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This can save some memory, since the image is never captured in e.g. SVG or HTML formats.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"note: Note\nIt is best to always let the object be showable as text/plain. This can be achieved by nested calls to DisplayAs output types. For example, to limit an image img to be showable as just image/png and text/plain you can useimg = plot(...)\nimg = DisplayAs.Text(DisplayAs.PNG(img))","category":"page"},{"location":"tips/#printing-tables-in-markdown","page":"7. Tips and tricks","title":"Printing tables in Markdown","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Tables that support the Tables.jl interface can be included in Markdown output with the lightweight package MarkdownTables.jl.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"using MarkdownTables\ntable = [(a = 1, b = 2), (a = 3, b = 4)]\ntable |> markdown_table()","category":"page"},{"location":"tips/#admonitions-md","page":"7. Tips and tricks","title":"Adding admonitions using compound line filtering","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Admonitions are a useful feature for drawing attention to particular elements of documentation. They are documented in Documenter.jl and an example of their use can be seen above in the blue 'note' box. Admonitions is a specific Julia markdown feature, and they are not recognized by either common mark or Jupyter notebooks. The md line filter can be used to make sure admonitions only show up in markdown output, for example:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"#md # !!! note \"Be aware!\"\n#md # This a note style admonition!","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"It is important to note that both #md and the second # are required. Literate.jl interprets the first #md as a markdown exclusive line, and then strips it out. The second # tells Literate.jl that the line should be parsed as markdown and not a Julia code block. If you only include #md and not the second # then it will be parsed into Julia example block in the final documentation and not an actual admonition.","category":"page"},{"location":"tips/#admonitions-compatibility","page":"7. Tips and tricks","title":"Custom parsing for markdown and notebook compatible admonitions","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"As mentioned above, admonitions are not compatible with Jupyter notebooks. (Though at time of writing this documentation, this is an open issue in Jupyter so may change in the future.) For now, we can write a custom preprocessor function so that admonitions are interpreted as quotes (with their own special formatting) in notebooks and proper admonitions in markdown. For the case of note admonitions, this can be written as follows:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"function md_note(str)\n str = replace(str, r\"^#note # (.*)$\"m => s\"\"\"\n # !!! note\n # \\1\"\"\")\n return str\nend\n\nfunction nb_note(str)\n str = replace(str, r\"^#note # (.*)$\"m => s\"\"\"\n # > *Note*\n # > \\1\"\"\")\n return str\nend\n\nusing Literate\n\nLiterate.markdown(\"example.jl\", \"tmp/\"; preprocess = md_note)\n\nLiterate.notebook(\"example.jl\", \"tmp/\"; preprocess = nb_note)","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This will allow us to turn the following source code in example.jl:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"#note # This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"into the correct admonition syntax in the markdown file generated:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"!!! note\n This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"and a quotation style formatting in the generated notebook cell:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"> *Note*\n> This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"which, in an actual notebook cell, will look similar to:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Note\nThis is a useful note.","category":"page"},{"location":"tips/#debug-execution","page":"7. Tips and tricks","title":"Debugging code execution","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"When Literate is executing code (i.e. when execute = true is set), it does so quietly. All the output gets captured and nothing gets printed into the terminal. This can make it tricky to know where things go wrong, e.g. when the execution stalls due to an infinite loop.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"To help debug this, Literate has an @debug statement that prints out each code block that is being executed. In general, to enable the printing of Literate's @debug statements, you can set the JULIA_DEBUG environment variable to \"Literate\".","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"The easiest way to do that is to set the variable in the Julia session before running Literate by doing","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"ENV[\"JULIA_DEBUG\"]=\"Literate\"","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Alternatively, you can also set the environment variable before starting the Julia session, e.g.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"$ JULIA_DEBUG=Literate julia","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"or by wrapping the Literate calls in an withenv block","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"withenv(\"JULIA_DEBUG\" => \"Literate\") do\n Literate.notebook(\"myscript.jl\"; execute=true)\nend","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"EditURL = \"../../../examples/example.jl\"","category":"page"},{"location":"generated/example/#**8.**-Example","page":"8. Example","title":"8. Example","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"(Image: ) (Image: )","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter has generated based on a markdown file generated with Literate. The corresponding notebook can be viewed in nbviewer here: example.ipynb, and opened in binder here: example.ipynb, and the plain script output can be found here: example.jl.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is recommended to have the source file available when reading this, to better understand how the syntax in the source file corresponds to the output you are seeing.","category":"page"},{"location":"generated/example/#Basic-syntax","page":"8. Example","title":"Basic syntax","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"The basic syntax for Literate is simple, lines starting with # is interpreted as markdown, and all the other lines are interpreted as code. Here is some code:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x = 1//3\ny = 2//5","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In markdown sections we can use markdown syntax. For example, we can write text in italic font, text in bold font and use links.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is possible to filter out lines depending on the output using the #md, #nb, #jl and #src tags (see Filtering lines):","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This line starts with #md and is thus only visible in the markdown output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"The source file is parsed in chunks of markdown and code. Starting a line with #- manually inserts a chunk break. For example, if we want to display the output of the following operations we may insert #- in between. These two code blocks will now end up in different @example-blocks in the markdown output, and two different notebook cells in the notebook output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x + y","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x * y","category":"page"},{"location":"generated/example/#Output-capturing","page":"8. Example","title":"Output capturing","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Code chunks are by default placed in Documenter @example blocks in the generated markdown. This means that the output will be captured in a block when Documenter is building the docs. In notebooks the output is captured in output cells, if the execute keyword argument is set to true. Output to stdout/stderr is also captured.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"note: Note\nNote that Documenter currently only displays output to stdout/stderr if there is no other result to show. Since the vector [1, 2, 3, 4] is returned from foo, the printing of \"This string is printed to stdout.\" is hidden.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"function foo()\n println(\"This string is printed to stdout.\")\n return [1, 2, 3, 4]\nend\n\nfoo()","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Just like in the REPL, outputs ending with a semicolon hides the output:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"1 + 1;\nnothing #hide","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Both Documenter's @example block and notebooks can display images. Here is an example where we generate a simple plot using the Plots.jl package","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"using Plots\nx = range(0, stop=6π, length=1000)\ny1 = sin.(x)\ny2 = cos.(x)\nplot(x, [y1, y2])","category":"page"},{"location":"generated/example/#Custom-processing","page":"8. Example","title":"Custom processing","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is possible to give Literate custom pre- and post-processing functions. For example, here we insert a placeholder value y = 321 in the source, and use a preprocessing function that replaces it with y = 321 in the rendered output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x = 123","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In this case the preprocessing function is defined by","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"function pre(s::String)\n s = replace(s, \"x = 123\" => \"y = 321\")\n return s\nend","category":"page"},{"location":"generated/example/#documenter-interaction","page":"8. Example","title":"Documenter.jl interaction","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In the source file it is possible to use Documenter.jl style references, such as @ref and @id. These will be filtered out in the notebook output. For example, here is a link, but it is only visible as a link if you are reading the markdown output. We can also use equations:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"int_Omega nabla v cdot nabla u mathrmdOmega = int_Omega v f mathrmdOmega","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"using Documenters math syntax. Documenters syntax is automatically changed to \\begin{equation} ... \\end{equation} in the notebook output to display correctly.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This page was generated using Literate.jl.","category":"page"}] +[{"location":"documenter/#Interaction-with-Documenter","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Literate can be used for any purpose, it spits out regular markdown files, and notebooks. Typically, though, these files will be used to render documentation for your package. The generators (Literate.markdown, Literate.notebook and Literate.script) supports a keyword argument documenter that lets the generator perform some extra things, keeping in mind that the source code have been written with Documenter.jl in mind. So let's take a look at what will happen if we set documenter = true:","category":"page"},{"location":"documenter/#[Literate.markdown](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.markdown:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"The default code fence will change from\n```julia\n# code\n```\nto Documenters @example blocks:\n```@examples $(name)\n# code\n```\nThe following @meta block will be added to the top of the markdown page, which redirects the \"Edit on GitHub\" link on the top of the page to the source file rather than the generated .md file:\n```@meta\nEditURL = \"$(relpath(inputfile, outputdir))\"\n```","category":"page"},{"location":"documenter/#[Literate.notebook](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.notebook:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Documenter style @refs and @id will be removed. This means that you can use @ref and @id in the source file without them leaking to the notebook.\nDocumenter style markdown math\n```math\n\\int f dx\n```\nis replaced with notebook compatible\n$$\n\\int f dx\n$$\nWhereas Documenter requires HTML blocks to be escaped\n```@raw html\n...\n```\nthe output to a notebook markdown cell will be raw HTML\n...","category":"page"},{"location":"documenter/#[Literate.script](@ref):","page":"6. Interaction with Documenter.jl","title":"Literate.script:","text":"","category":"section"},{"location":"documenter/","page":"6. Interaction with Documenter.jl","title":"6. Interaction with Documenter.jl","text":"Documenter style @refs and @id will be removed. This means that you can use @ref and @id in the source file without them leaking to the script.","category":"page"},{"location":"customprocessing/#Custom-pre-and-post-processing","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"All of the generators (Literate.markdown, Literate.notebook and Literate.script) accept preprocess and postprocess keyword arguments. The default \"transformation\" is the identity function. The input to the transformation functions is a String, and the output should be the transformed String.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"preprocess is sent the raw input that is read from the source file (modulo the default line ending transformation). postprocess is given different things depending on the output: For markdown and script output postprocess is given the content String just before writing it to the output file, but for notebook output postprocess is given the dictionary representing the notebook, since, in general, this is more useful.","category":"page"},{"location":"customprocessing/#Example:-Adding-current-date","page":"5. Custom pre- and post-processing","title":"Example: Adding current date","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"As an example, lets say we want to splice the date of generation into the output. We could of course update our source file before generating the docs, but we could instead use a preprocess function that splices the date into the source for us. Consider the following source file:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"# # Example\n# This example was generated DATEOFTODAY\n\nx = 1 // 3","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"where DATEOFTODAY is a placeholder, to make it easier for our preprocess function to find the location. Now, lets define the preprocess function, for example","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"function update_date(content)\n content = replace(content, \"DATEOFTODAY\" => Date(now()))\n return content\nend","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"which would replace every occurrence of \"DATEOFTODAY\" with the current date. We would now simply give this function to the generator, for example:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Literate.markdown(\"input.jl\", \"outputdir\"; preprocess = update_date)","category":"page"},{"location":"customprocessing/#Example:-Replacing-include-calls-with-included-code","page":"5. Custom pre- and post-processing","title":"Example: Replacing include calls with included code","text":"","category":"section"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Let's say that we have some individual example files file1, file2, ... etc. that are runnable and also following the style of Literate. These files could be for example used in the test suite of your package.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"We want to group them all into a single page in our documentation, but we do not want to copy paste the content of file1, ... for robustness: the files are included in the test suite and some changes may occur to them. We want these changes to also be reflected in the documentation.","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"A very easy way to do this is using preprocess to interchange include statements with file content. First, create a runnable .jl following the format of Literate","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"# # Replace includes\n# This is an example to replace `include` calls with the actual file content.\n\ninclude(\"file1.jl\")\n\n# Cool, we just saw the result of the above code snippet. Here is one more:\n\ninclude(\"file2.jl\")","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Let's say we have saved this file as examples.jl. Then, you want to properly define a pre-processing function:","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"function replace_includes(str)\n\n included = [\"file1.jl\", \"file2.jl\"]\n\n # Here the path loads the files from their proper directory,\n # which may not be the directory of the `examples.jl` file!\n path = \"directory/to/example/files/\"\n\n for ex in included\n content = read(path*ex, String)\n str = replace(str, \"include(\\\"$(ex)\\\")\" => content)\n end\n return str\nend","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"(of course replace included with your respective files)","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Finally, you simply pass this function to e.g. Literate.markdown as","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"Literate.markdown(\"examples.jl\", \"path/to/save/markdown\";\n name = \"markdown_file_name\", preprocess = replace_includes)","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"and you will see that in the final output file (here markdown_file_name.md) the include statements are replaced with the actual code to be included!","category":"page"},{"location":"customprocessing/","page":"5. Custom pre- and post-processing","title":"5. Custom pre- and post-processing","text":"This approach is used for generating the examples in the documentation of the TimeseriesPrediction.jl package. The example files, included together in the stexamples.jl file, are processed by literate via this make.jl file to generate the markdown and code cells of the documentation.","category":"page"},{"location":"tips/#tips-and-tricks","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This section lists some tips and tricks that might be useful for using Literate.","category":"page"},{"location":"tips/#notebook-filesize","page":"7. Tips and tricks","title":"Filesize of generated notebooks","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"When Literate executes a notebook the return value, i.e. the result of the last Julia expression in each cell is captured. By default Literate generates multiple renderings of the result in different output formats or MIMEs, just like IJulia.jl does. All of these renderings are embedded in the notebook and it is up to the notebook frontend viewer to select the most appropriate format to show to the user.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"A common example is images, which can often be displayed in multiple formats, e.g. PNG (image/png), SVG (image/svg+xml) and HTML (text/html). As a result, the filesize of the generated notebook can become large.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"In order to remedy this you can use the clever Julia package DisplayAs to limit the output capabilities of an object. For example, to \"force\" an image to be captures as image/png only, you can use","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"import DisplayAs\nimg = plot(...)\nimg = DisplayAs.PNG(img)","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This can save some memory, since the image is never captured in e.g. SVG or HTML formats.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"note: Note\nIt is best to always let the object be showable as text/plain. This can be achieved by nested calls to DisplayAs output types. For example, to limit an image img to be showable as just image/png and text/plain you can useimg = plot(...)\nimg = DisplayAs.Text(DisplayAs.PNG(img))","category":"page"},{"location":"tips/#printing-tables-in-markdown","page":"7. Tips and tricks","title":"Printing tables in Markdown","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Tables that support the Tables.jl interface can be included in Markdown output with the lightweight package MarkdownTables.jl.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"using MarkdownTables\ntable = [(a = 1, b = 2), (a = 3, b = 4)]\ntable |> markdown_table()","category":"page"},{"location":"tips/#admonitions-md","page":"7. Tips and tricks","title":"Adding admonitions using compound line filtering","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Admonitions are a useful feature for drawing attention to particular elements of documentation. They are documented in Documenter.jl and an example of their use can be seen above in the blue 'note' box. Admonitions is a specific Julia markdown feature, and they are not recognized by either common mark or Jupyter notebooks. The md line filter can be used to make sure admonitions only show up in markdown output, for example:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"#md # !!! note \"Be aware!\"\n#md # This a note style admonition!","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"It is important to note that both #md and the second # are required. Literate.jl interprets the first #md as a markdown exclusive line, and then strips it out. The second # tells Literate.jl that the line should be parsed as markdown and not a Julia code block. If you only include #md and not the second # then it will be parsed into Julia example block in the final documentation and not an actual admonition.","category":"page"},{"location":"tips/#admonitions-compatibility","page":"7. Tips and tricks","title":"Custom parsing for markdown and notebook compatible admonitions","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"As mentioned above, admonitions are not compatible with Jupyter notebooks. (Though at time of writing this documentation, this is an open issue in Jupyter so may change in the future.) For now, we can write a custom preprocessor function so that admonitions are interpreted as quotes (with their own special formatting) in notebooks and proper admonitions in markdown. For the case of note admonitions, this can be written as follows:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"function md_note(str)\n str = replace(str, r\"^#note # (.*)$\"m => s\"\"\"\n # !!! note\n # \\1\"\"\")\n return str\nend\n\nfunction nb_note(str)\n str = replace(str, r\"^#note # (.*)$\"m => s\"\"\"\n # > *Note*\n # > \\1\"\"\")\n return str\nend\n\nusing Literate\n\nLiterate.markdown(\"example.jl\", \"tmp/\"; preprocess = md_note)\n\nLiterate.notebook(\"example.jl\", \"tmp/\"; preprocess = nb_note)","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"This will allow us to turn the following source code in example.jl:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"#note # This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"into the correct admonition syntax in the markdown file generated:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"!!! note\n This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"and a quotation style formatting in the generated notebook cell:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"> *Note*\n> This is a useful note.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"which, in an actual notebook cell, will look similar to:","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Note\nThis is a useful note.","category":"page"},{"location":"tips/#debug-execution","page":"7. Tips and tricks","title":"Debugging code execution","text":"","category":"section"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"When Literate is executing code (i.e. when execute = true is set), it does so quietly. All the output gets captured and nothing gets printed into the terminal. This can make it tricky to know where things go wrong, e.g. when the execution stalls due to an infinite loop.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"To help debug this, Literate has an @debug statement that prints out each code block that is being executed. In general, to enable the printing of Literate's @debug statements, you can set the JULIA_DEBUG environment variable to \"Literate\".","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"The easiest way to do that is to set the variable in the Julia session before running Literate by doing","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"ENV[\"JULIA_DEBUG\"]=\"Literate\"","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"Alternatively, you can also set the environment variable before starting the Julia session, e.g.","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"$ JULIA_DEBUG=Literate julia","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"or by wrapping the Literate calls in an withenv block","category":"page"},{"location":"tips/","page":"7. Tips and tricks","title":"7. Tips and tricks","text":"withenv(\"JULIA_DEBUG\" => \"Literate\") do\n Literate.notebook(\"myscript.jl\"; execute=true)\nend","category":"page"},{"location":"pipeline/#Processing-pipeline","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The generation of output follows the same pipeline for all output formats:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Pre-processing\nParsing\nDocument generation\nPost-processing\nWriting to file","category":"page"},{"location":"pipeline/#Pre-processing","page":"3. Processing pipeline","title":"3.1. Pre-processing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The first step is pre-processing of the input file. The file is read to a String. The first processing step is to apply the user specified pre-processing function, see Custom pre- and post-processing.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The next step is to perform all of the built-in default replacements. CRLF style line endings (\"\\r\\n\") are replaced with LF line endings (\"\\n\") to simplify internal processing. Next, line filtering is performed, see Filtering lines, meaning that lines starting with #md, #nb or #jl are handled (either just the token itself is removed, or the full line, depending on the output target). The last pre-processing step is to expand the convenience \"macros\" described in Default replacements is expanded.","category":"page"},{"location":"pipeline/#Parsing","page":"3. Processing pipeline","title":"3.2. Parsing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"After the preprocessing the file is parsed. The first step is to categorize each line and mark them as either markdown or code according to the rules described in the Syntax section. Lets consider the example from the previous section with each line categorized:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# # Rational numbers <- markdown\n# <- markdown\n# In julia rational numbers can be constructed with the `//` operator. <- markdown\n# Lets define two rational numbers, `x` and `y`: <- markdown\n <- code\n## Define variable x and y <- code\nx = 1 // 3 <- code\ny = 2 // 5 <- code\n <- code\n# When adding `x` and `y` together we obtain a new rational number: <- markdown\n <- code\nz = x + y <- code","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"In the next step the lines are grouped into \"chunks\" of markdown and code. This is done by simply collecting adjacent lines of the same \"type\" into chunks:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# # Rational numbers ┐\n# │\n# In julia rational numbers can be constructed with the `//` operator. │ markdown\n# Lets define two rational numbers, `x` and `y`: ┘\n ┐\n## Define variable x and y │\nx = 1 // 3 │\ny = 2 // 5 │ code\n ┘\n# When adding `x` and `y` together we obtain a new rational number: ] markdown\n ┐\nz = x + y ┘ code","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"In the last parsing step all empty leading and trailing lines for each chunk are removed, but empty lines within the same block are kept. The leading # tokens are also removed from the markdown chunks. Finally we would end up with the following 4 chunks:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunks #1:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# Rational numbers\n\nIn julia rational numbers can be constructed with the `//` operator.\nLets define two rational numbers, `x` and `y`:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #2:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"# Define variable x and y\nx = 1 // 3\ny = 2 // 5","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #3:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"When adding `x` and `y` together we obtain a new rational number:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Chunk #4:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"z = x + y","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"It is then up to the Document generation step to decide how these chunks should be treated.","category":"page"},{"location":"pipeline/#Custom-control-over-chunk-splits","page":"3. Processing pipeline","title":"Custom control over chunk splits","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Sometimes it is convenient to be able to manually control how the chunks are split. For example, if you want to split a block of code into two, such that they end up in two different @example blocks or notebook cells. The #- token can be used for this purpose. All lines starting with #- are used as \"chunk-splitters\":","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"x = 1 // 3\ny = 2 // 5\n#-\nz = x + y","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The example above would result in two consecutive code-chunks.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"tip: Tip\nThe rest of the line, after #-, is discarded, so it is possible to use e.g. #------------- as a chunk splitter, which may make the source code more readable.","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"It is also possible to use #+ as a chunk splitter. The difference between #+ and #- is that #+ enables Documenter's \"continued\"-blocks, see the Documenter manual.","category":"page"},{"location":"pipeline/#Document-generation","page":"3. Processing pipeline","title":"3.3. Document generation","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"After the parsing it is time to generate the output. What is done in this step is very different depending on the output target, and it is described in more detail in the Output format sections: Markdown output, Notebook output and Script output. Using the default settings, the following is happening:","category":"page"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"Markdown output: markdown chunks are printed as-is, code chunks are put inside a code fence (defaults to @example-blocks),\nNotebook output: markdown chunks are printed in markdown cells, code chunks are put in code cells,\nScript output: markdown chunks are discarded, code chunks are printed as-is.","category":"page"},{"location":"pipeline/#Post-processing","page":"3. Processing pipeline","title":"3.4. Post-processing","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"When the document is generated the user, again, has the option to hook-into the generation with a custom post-processing function. The reason is that one might want to change things that are only visible in the rendered document. See Custom pre- and post-processing.","category":"page"},{"location":"pipeline/#Writing-to-file","page":"3. Processing pipeline","title":"3.5. Writing to file","text":"","category":"section"},{"location":"pipeline/","page":"3. Processing pipeline","title":"3. Processing pipeline","text":"The last step of the generation is writing to file. The result is written to $(outputdir)/$(name)(.md|.ipynb|.jl) where outputdir is the output directory supplied by the user (for example docs/generated), and name is a user supplied filename. It is recommended to add the output directory to .gitignore since the idea is that the generated documents will be generated as part of the build process rather than being files in the repo.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"EditURL = \"../../../examples/example.jl\"","category":"page"},{"location":"generated/example/#**8.**-Example","page":"8. Example","title":"8. Example","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"(Image: ) (Image: )","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter has generated based on a markdown file generated with Literate. The corresponding notebook can be viewed in nbviewer here: example.ipynb, and opened in binder here: example.ipynb, and the plain script output can be found here: example.jl.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is recommended to have the source file available when reading this, to better understand how the syntax in the source file corresponds to the output you are seeing.","category":"page"},{"location":"generated/example/#Basic-syntax","page":"8. Example","title":"Basic syntax","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"The basic syntax for Literate is simple, lines starting with # is interpreted as markdown, and all the other lines are interpreted as code. Here is some code:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x = 1//3\ny = 2//5","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In markdown sections we can use markdown syntax. For example, we can write text in italic font, text in bold font and use links.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is possible to filter out lines depending on the output using the #md, #nb, #jl and #src tags (see Filtering lines):","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This line starts with #md and is thus only visible in the markdown output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"The source file is parsed in chunks of markdown and code. Starting a line with #- manually inserts a chunk break. For example, if we want to display the output of the following operations we may insert #- in between. These two code blocks will now end up in different @example-blocks in the markdown output, and two different notebook cells in the notebook output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x + y","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x * y","category":"page"},{"location":"generated/example/#Output-capturing","page":"8. Example","title":"Output capturing","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Code chunks are by default placed in Documenter @example blocks in the generated markdown. This means that the output will be captured in a block when Documenter is building the docs. In notebooks the output is captured in output cells, if the execute keyword argument is set to true. Output to stdout/stderr is also captured.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"note: Note\nNote that Documenter currently only displays output to stdout/stderr if there is no other result to show. Since the vector [1, 2, 3, 4] is returned from foo, the printing of \"This string is printed to stdout.\" is hidden.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"function foo()\n println(\"This string is printed to stdout.\")\n return [1, 2, 3, 4]\nend\n\nfoo()","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Just like in the REPL, outputs ending with a semicolon hides the output:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"1 + 1;\nnothing #hide","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"Both Documenter's @example block and notebooks can display images. Here is an example where we generate a simple plot using the Plots.jl package","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"using Plots\nx = range(0, stop=6π, length=1000)\ny1 = sin.(x)\ny2 = cos.(x)\nplot(x, [y1, y2])","category":"page"},{"location":"generated/example/#Custom-processing","page":"8. Example","title":"Custom processing","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"It is possible to give Literate custom pre- and post-processing functions. For example, here we insert a placeholder value y = 321 in the source, and use a preprocessing function that replaces it with y = 321 in the rendered output.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"x = 123","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In this case the preprocessing function is defined by","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"function pre(s::String)\n s = replace(s, \"x = 123\" => \"y = 321\")\n return s\nend","category":"page"},{"location":"generated/example/#documenter-interaction","page":"8. Example","title":"Documenter.jl interaction","text":"","category":"section"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"In the source file it is possible to use Documenter.jl style references, such as @ref and @id. These will be filtered out in the notebook output. For example, here is a link, but it is only visible as a link if you are reading the markdown output. We can also use equations:","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"int_Omega nabla v cdot nabla u mathrmdOmega = int_Omega v f mathrmdOmega","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"using Documenters math syntax. Documenters syntax is automatically changed to \\begin{equation} ... \\end{equation} in the notebook output to display correctly.","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"","category":"page"},{"location":"generated/example/","page":"8. Example","title":"8. Example","text":"This page was generated using Literate.jl.","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"EditURL = \"../outputformats.jl\"","category":"page"},{"location":"generated/name/#Rational-numbers","page":"Rational numbers","title":"Rational numbers","text":"","category":"section"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"In julia rational numbers can be constructed with the // operator. Lets define two rational numbers, x and y:","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"x = 1//3","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"y = 2//5","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"When adding x and y together we obtain a new rational number:","category":"page"},{"location":"generated/name/","page":"Rational numbers","title":"Rational numbers","text":"z = x + y","category":"page"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"EditURL = \"https://github.com/fredrikekre/Literate.jl/blob/master/CHANGELOG.md\"","category":"page"},{"location":"changelog/#**9.**-Changelog","page":"9. Changelog","title":"9. Changelog","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"All notable changes to this project will be documented in this file.","category":"page"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.","category":"page"},{"location":"changelog/#[v2.17.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.17.0)-2024-04-14","page":"9. Changelog","title":"v2.17.0 - 2024-04-14","text":"","category":"section"},{"location":"changelog/#Added","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Literate can now output Quarto notebooks (markdown documents with the .qmd file extension) by passing flavor = Literate.QuartoFlavor() to Literate.markdown. This feature is marked as experimental since it has not been widely tested and the Quarto-specific syntax may change before Literate version 3 depending on what the community wants or needs. (#199, #200)","category":"page"},{"location":"changelog/#[v2.16.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.16.1)-2024-01-04","page":"9. Changelog","title":"v2.16.1 - 2024-01-04","text":"","category":"section"},{"location":"changelog/#Fixed","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Fix removal of Documenter-style @ref links spanning multiple lines. (#224, #233)","category":"page"},{"location":"changelog/#[v2.16.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.16.0)-2023-11-08","page":"9. Changelog","title":"v2.16.0 - 2023-11-08","text":"","category":"section"},{"location":"changelog/#Added-2","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"\"Soft\" scoping rules (see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl) are now available for code execution (markdown and notebook output). This is enabled by default for Jupyter notebook output (to mimic how the IJulia kernel works), and disabled otherwise. Soft scope rules can be enabled/disabled with the softscope :: Bool configuration variable. (#227, #230)","category":"page"},{"location":"changelog/#Changed","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"The minimum Julia version requirement for Literate >= 2.16.0 is now 1.6.0 (from 1.0.0). (#230)","category":"page"},{"location":"changelog/#[v2.15.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.15.1)-2023-11-08","page":"9. Changelog","title":"v2.15.1 - 2023-11-08","text":"","category":"section"},{"location":"changelog/#Fixed-2","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Fix a bug where Literate.markdown with execute=true would (try to) output images in the wrong directory. This only occured when passing a relative output directory. (#228, #229)","category":"page"},{"location":"changelog/#[v2.15.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.15.0)-2023-09-05","page":"9. Changelog","title":"v2.15.0 - 2023-09-05","text":"","category":"section"},{"location":"changelog/#Added-3","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Documenter style @raw html blocks are automatically handled in Jupyter notebook output (similar to how Documenter style `math blocks are rewritten to $$ blocks). (#222, #223)","category":"page"},{"location":"changelog/#[v2.14.2](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.14.2)-2023-08-28","page":"9. Changelog","title":"v2.14.2 - 2023-08-28","text":"","category":"section"},{"location":"changelog/#Fixed-3","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Remove double newline in Literate.script output. (#221)","category":"page"},{"location":"changelog/#[v2.14.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.14.1)-2023-08-04","page":"9. Changelog","title":"v2.14.1 - 2023-08-04","text":"","category":"section"},{"location":"changelog/#Fixed-4","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Update generated EditURL to use a relative path instead and let Documenter figure out the remote repository. This is required for Documenter version 1, but works also on Documenter 0.27. (#219)","category":"page"},{"location":"changelog/#[v2.14.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.14.0)-2022-09-22","page":"9. Changelog","title":"v2.14.0 - 2022-09-22","text":"","category":"section"},{"location":"changelog/#Changed-2","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Image filenames resulting from executing markdown files (Literate.markdown(...; execute=true)) have changed from a number based on the hash of the source block to the format {name}-{blocknumber}.(svg|png|...). (#204, #205)","category":"page"},{"location":"changelog/#[v2.13.4](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.13.4)-2022-06-03","page":"9. Changelog","title":"v2.13.4 - 2022-06-03","text":"","category":"section"},{"location":"changelog/#Fixed-5","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Automatic head branch detection (introduced in version 2.11.0) caused a performance regression since the git remote show command takes ~1 second. For documentation builds with many literate files this caused significant slowdowns, which is particularly annoying when doing iterative buils with eg. LiveServer.jl. Literate now caches the remote head branch on a per-repo basis, so the 1 second delay should only be noticed on the first run of the first file in a repo. As noted in the changelog entry for 2.11.0 it is also possible to specify the head branch by passing the edit_commit keyword argument. Doing so will now completely skip the slow git command. (8054d26)","category":"page"},{"location":"changelog/#[v2.13.3](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.13.3)-2022-05-21","page":"9. Changelog","title":"v2.13.3 - 2022-05-21","text":"","category":"section"},{"location":"changelog/#Fixed-6","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Update remote HEAD branch detection to use addenv instead of setenv such that e.g. ssh-agent variables are available to the git command. Also set GIT_SSH_COMMAND='ssh -o \"BatchMode yes\"' to supress prompts when using ssh. (#197)","category":"page"},{"location":"changelog/#[v2.13.2](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.13.2)-2022-04-22","page":"9. Changelog","title":"v2.13.2 - 2022-04-22","text":"","category":"section"},{"location":"changelog/#Fixed-7","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Set current working directory for markdown execution to the output directory, just like notebook execution. (#195)\nSet the apparent source file to the output file for markdown and notebook execution. (#195)","category":"page"},{"location":"changelog/#[v2.13.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.13.1)-2022-04-12","page":"9. Changelog","title":"v2.13.1 - 2022-04-12","text":"","category":"section"},{"location":"changelog/#Fixed-8","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Disable git terminal prompt when detecting remote HEAD branch. (#194)","category":"page"},{"location":"changelog/#[v2.13.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.13.0)-2022-02-18","page":"9. Changelog","title":"v2.13.0 - 2022-02-18","text":"","category":"section"},{"location":"changelog/#Changed-3","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"\"Markdown stdlib-style\" inline math (e.g. ``f(x) = x^2``) is now replaced with \"notebook style\" math ($f(x) = x^2$) for notebook output. This is already the case for display math (math). (#116, #190)","category":"page"},{"location":"changelog/#Fixed-9","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Lines with trailing #hide are not shown in output of Markdown execution with Documenter flavor. (#166, #188)","category":"page"},{"location":"changelog/#[v2.12.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.12.1)-2022-02-10","page":"9. Changelog","title":"v2.12.1 - 2022-02-10","text":"","category":"section"},{"location":"changelog/#Fixed-10","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Make sure Markdown execution picks up new definitions of display methods (by running in the latest \"world age\"). (#187)","category":"page"},{"location":"changelog/#[v2.12.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.12.0)-2022-02-01","page":"9. Changelog","title":"v2.12.0 - 2022-02-01","text":"","category":"section"},{"location":"changelog/#Changed-4","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"User input configurations can now be AbstractDicts instead of just Dicts. (#185, #186)","category":"page"},{"location":"changelog/#[v2.11.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.11.0)-2022-01-25","page":"9. Changelog","title":"v2.11.0 - 2022-01-25","text":"","category":"section"},{"location":"changelog/#Added-4","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Literate now tries to figure out the branch/commit that EditURL should point to automatically instead of always defaulting to \"master\". For typical setups the auto-detection should be sufficient, but you can also set it explicitly by passing edit_commit, for example edit_commit = \"main\". (#179, #184)","category":"page"},{"location":"changelog/#[v2.10.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.10.0)-2022-01-24","page":"9. Changelog","title":"v2.10.0 - 2022-01-24","text":"","category":"section"},{"location":"changelog/#Added-5","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Markdown execution now also support image/svg+xml. (#182, #183)","category":"page"},{"location":"changelog/#[v2.9.4](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.9.4)-2021-10-18","page":"9. Changelog","title":"v2.9.4 - 2021-10-18","text":"","category":"section"},{"location":"changelog/#Fixed-11","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Fix multiline comment support for \\r\\n line endings. (#171, #172)","category":"page"},{"location":"changelog/#[v2.9.3](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.9.3)-2021-09-01","page":"9. Changelog","title":"v2.9.3 - 2021-09-01","text":"","category":"section"},{"location":"changelog/#Fixed-12","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Fix named @examples from Literate.markdown to not contain spaces even if the source filename does. (#168, #169)","category":"page"},{"location":"changelog/#[v2.9.2](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.9.2)-2021-08-16","page":"9. Changelog","title":"v2.9.2 - 2021-08-16","text":"","category":"section"},{"location":"changelog/#Fixed-13","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Fix multiline comment support for \\r\\n line endings. (#165, #167)","category":"page"},{"location":"changelog/#[v2.9.1](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.9.1)-2021-07-30","page":"9. Changelog","title":"v2.9.1 - 2021-07-30","text":"","category":"section"},{"location":"changelog/#Fixed-14","page":"9. Changelog","title":"Fixed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Automatic URLs from @__NBVIEWER_ROOT_URL__ and @__BINDER_ROOT_URL__ now follow the convention used in Documenter.jl to ignore build version information. (#162, #163)","category":"page"},{"location":"changelog/#[v2.9.0](https://github.com/fredrikekre/Literate.jl/releases/tag/v2.9.0)-2021-07-09","page":"9. Changelog","title":"v2.9.0 - 2021-07-09","text":"","category":"section"},{"location":"changelog/#Added-6","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Added \"Franklin flavored\" markdown output for usage with Franklin. Enable by passing the flavor keyword argument:\nLiterate.markdown(...; flavor = Literate.FranklinFlavor())\n(#146, #147, #156)\nAdded \"Documenter flavored\" markdown output as a replacement for documenter=true, and \"CommonMark flavored\" markdown output as a replacement for documenter=false. Enable by passing the flavor keyword argument:\nLiterate.markdown(...; flavor = Literate.DocumenterFlavor())\nLiterate.markdown(...; flavor = Literate.CommonMarkFlavor())\n(#159)\nAdded option to use multiline markdown strings (md\"\"\" ... \"\"\") as markdown sections. To enable, pass mdstrings=true. (#152, #149)","category":"page"},{"location":"changelog/#Changed-5","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"The default code fence for markdown output have been changed to 4 (instead of 3) backticks to allow input files with 3 backticks, which is common in e.g. docstrings or multiline Cmd. (#144, #145)\nReplacement of Documenter-style @ref and @id elements are now removed unconditionally instead of conditionally based on the (now deprecated) documenter keyword argument. (#159)","category":"page"},{"location":"changelog/#Deprecated","page":"9. Changelog","title":"Deprecated","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"The documenter keyword argument has been deprecated. For Literate.markdown the the replacement is to use flavor = Literate.DocumenterFlavor() or flavor = Literate.CommonMarkFlavor() as appropriate (see above). For Literate.notebook and Literate.script the option is now unused (see above regarding @ref and @id), and no replacement is necessary. (#159)","category":"page"},{"location":"changelog/#v2.8-2021-01-19","page":"9. Changelog","title":"v2.8 - 2021-01-19","text":"","category":"section"},{"location":"changelog/#Added-7","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Execution of notebooks now capture output of display(x) and display(mime, x) (ceff7a3).","category":"page"},{"location":"changelog/#v2.7-2021-09-12","page":"9. Changelog","title":"v2.7 - 2021-09-12","text":"","category":"section"},{"location":"changelog/#Added-8","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Multiline-style Julia comments (#= ... =#) can now be used for markdown input (dc409d0).","category":"page"},{"location":"changelog/#v2.6-2020-08-15","page":"9. Changelog","title":"v2.6 - 2020-08-15","text":"","category":"section"},{"location":"changelog/#Added-9","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"New end-of-line token #hide which filters out the line after execution in Literate.markdown(...; execute=true) (6d1aec9).\nMarkdown execution now captures the text/markdown MIME (e08ca0a).","category":"page"},{"location":"changelog/#v2.5-2020-05-14","page":"9. Changelog","title":"v2.5 - 2020-05-14","text":"","category":"section"},{"location":"changelog/#Changed-6","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"The output directory now defaults to pwd() (2ba316a).","category":"page"},{"location":"changelog/#v2.4-2020-04-23","page":"9. Changelog","title":"v2.4 - 2020-04-23","text":"","category":"section"},{"location":"changelog/#Added-10","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Markdown output can now be executed and the result included in the output by pasing execute=true to Literate.markdown. Currently captures the following MIMEs: text/plain, image/png, and image/jpeg (7e89fdb).","category":"page"},{"location":"changelog/#v2.3-2020-03-03","page":"9. Changelog","title":"v2.3 - 2020-03-03","text":"","category":"section"},{"location":"changelog/#Added-11","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Filter tokens #md, #nb, and #jl, as well as their negated counterparts, can now be placed at the end of lines (b0806ed).","category":"page"},{"location":"changelog/#v2.2-2019-11-26","page":"9. Changelog","title":"v2.2 - 2019-11-26","text":"","category":"section"},{"location":"changelog/#Added-12","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Configuration can now be passed as a config::Dict keyword argument to the generators (0f9e836).\nLink macros now works when running on GitLab CI (4e71b15).\nLiterate now supports more configuration for e.g. URL's that @__REPO_ROOT_URL__ and friends expand to (4e71b15).","category":"page"},{"location":"changelog/#v2.1-2019-10-30","page":"9. Changelog","title":"v2.1 - 2019-10-30","text":"","category":"section"},{"location":"changelog/#Added-13","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Link macros now works when running on GitHub Actions (cf2b552).","category":"page"},{"location":"changelog/#v2.0-2019-07-19","page":"9. Changelog","title":"v2.0 - 2019-07-19","text":"","category":"section"},{"location":"changelog/#Added-14","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"Negated filter tokens (#!nb, #!md and #!jl) are now supported (1d02868).\nNotebook output now support cell metadata with the %%-format (0872a96).","category":"page"},{"location":"changelog/#Changed-7","page":"9. Changelog","title":"Changed","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"BREAKING The link macros @__REPO_ROOT_URL__, @__NBVIEWER_ROOT_URL__ and @__BINDER_ROOT_URL__ no longer include a trailing / (7af5414).\nBREAKING The (undocumented) feature of Documenter continued blocks now requires an explicit #+ chunk splitter (36e8c21).\nThe link macros @__REPO_ROOT_URL__, @__NBVIEWER_ROOT_URL__ now expands to correct paths when documentation is built with DocumentationGenerator.jl (7af5414).","category":"page"},{"location":"changelog/#v1.1-2019-04-05","page":"9. Changelog","title":"v1.1 - 2019-04-05","text":"","category":"section"},{"location":"changelog/#Added-15","page":"9. Changelog","title":"Added","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"New link macro @__BINDER_ROOT_URL__ for linking to notebooks mybinder.org (fa64dcd).","category":"page"},{"location":"changelog/#v1.0-2019-03-06","page":"9. Changelog","title":"v1.0 - 2019-03-06","text":"","category":"section"},{"location":"changelog/","page":"9. Changelog","title":"9. Changelog","text":"First stable release of Literate.jl, see https://discourse.julialang.org/t/ann-literate-jl/10651 for release announcement.","category":"page"},{"location":"outputformats/#Output-formats","page":"4. Output formats","title":"4. Output formats","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"When the source is parsed, and has been processed it is time to render the output. We will consider the following source snippet:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nMarkdown.parse(\"```julia\\n\" * rstrip(read(\"outputformats.jl\", String)) * \"\\n```\")","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"and see how this is rendered in each of the output formats.","category":"page"},{"location":"outputformats/#Markdown-output","page":"4. Output formats","title":"4.1. Markdown output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Markdown output is generated by Literate.markdown. There exist various \"flavors\" of markdown and Literate supports some different flavors, see Markdown flavors. The default flavor is Literate.DocumenterFlavor() and, as the name suggest, it generates markdown files meant to be used together with Documenter.jl. The output of the source snippet above is as follows:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nfile = joinpath(@__DIR__, \"../src/generated/name.md\")\nstr = \"`````markdown\\n\" * rstrip(read(file, String)) * \"\\n`````\"\nrm(file)\nMarkdown.parse(str)","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are printed as regular markdown, and the code lines have been wrapped in @example blocks. We also note that an @meta block have been added, that sets the EditURL variable. This is used by Documenter to redirect the \"Edit on GitHub\" link for the page, see Interaction with Documenter.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The @example blocks are wrapped in 4 consecutive backticks so as to allow for docstrings containing triple backticks, for example:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"\"\"\"\nThis function perform the following calculation:\n```math\n x_1 + x_2\n```\n\"\"\"\nf(x) = x[1] + x[2]","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"If your Julia code itself contains 4 consecutive backticks, you can use the keyword argument codefence to setup 5 backticks for code blocks, see Configuration.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"It possible to configure Literate.markdown to also evaluate code snippets, capture the result and include it in the output, by passing execute=true as a keyword argument. The result of the first code-block in the example above would then become","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"````julia\nx = 1//3\n````\n````\n1//3\n````","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"In this example the output is just plain text. However, if the resulting value of the code block can be displayed as an image (image/png or image/jpeg), HTML (text/html) or markdown (text/markdown) Literate will include the richest representation of the output.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"note: Note\nSince Documenter executes and captures results of @example block it is not necessary to use execute=true for markdown output that is meant to be used as input to Documenter.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for more information about how to configure the behavior and resulting output of Literate.markdown.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.markdown","category":"page"},{"location":"outputformats/#Literate.markdown","page":"4. Output formats","title":"Literate.markdown","text":"Literate.markdown(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a markdown file from inputfile and write the result to the directory outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Markdown-flavors","page":"4. Output formats","title":"Markdown flavors","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate can output markdown in different flavors. The flavor is specified using the flavor keyword argument. The following flavors are currently supported:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"flavor = Literate.DocumenterFlavor(): this is the default flavor and the output is meant to be used as input to Documenter.jl.\nflavor = Literate.CommonMarkFlavor(): this outputs markdown that has the flavor of the CommonMark specification.\nflavor = Literate.FranklinFlavor(): this outputs markdown meant to be used as input to Franklin.jl.\nflavor = Literate.QuartoFlavor(): this outputs markdown file (with file extension .qmd) meant to be used with Quarto CLI.","category":"page"},{"location":"outputformats/#Quarto-flavor","page":"4. Output formats","title":"Quarto flavor","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"warning: Experimental feature\nQuarto markdown output is marked as and experimental feature since it has not been widely tested. Quarto-specific syntax may change before Literate version 3 depending on what the community wants and/or needs. If you use this flavor non-interactively (such as automatically building documentation) it is recommended to pin Literate to a good known version.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Quarto is an open-source scientific and technical publishing system, which can extend the range of output formats from your Literate.jl-formatted scripts. Literate.jl will produce a .qmd file, which can be used as input to Quarto CLI to produce a variety of output formats, including HTML, PDF, Word and RevealJS slides.","category":"page"},{"location":"outputformats/#Literate-Quarto-syntax-tips","page":"4. Output formats","title":"Literate + Quarto syntax tips","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"#(hashtag followed by a space) at the beginning of a line will be stripped and anything that follows will rendered as a markdown, e.g., # # Header level 1 in your script will be rendered as # Header level 1 in your .qmd file (ie, it will show as a header). Use this for adding the YAML header at the top or any Markdown blocks in the Quarto guide.\n##|(two hashtags followed by a pipe) at the beginning of a line will strip the first hashtag and interpret the remainder of the line as part of the code block. This is useful to provide Quarto commands in computation blocks, e.g., ##! echo: false would be rendered as #| echo: false and would tell Quarto not to \"echo\" the outputs of the execution (see Guide: Executions options for more commands).\nMake sure to always provide the YAML header and specify IJulia kernel when executing the file by Quarto, e.g.,\n# ---\n# title: \"My Report\"\n# jupyter: julia-1.9\n# ---\nNotice how all lines are escaped with a # so Literate.jl knows to strip the hashtags and render it as markdown (see Authoring Tutorial for more examples)\nIf any markdown components (e.g. headers) are not rendering correctly in your Quarto outputs, make sure they are surrounded by empty lines (e.g., add an empty line before and after the header) to help Quarto parse them correctly","category":"page"},{"location":"outputformats/#Configuring-Quarto-for-Julia-code-execution","page":"4. Output formats","title":"Configuring Quarto for Julia code execution","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Install Quarto CLI\nRun quarto check to ensure all is installed correctly (you will need Python, Jupyter, and IJulia kernel, see Getting Started)","category":"page"},{"location":"outputformats/#Steps-to-create-reports","page":"4. Output formats","title":"Steps to create reports","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Make sure you have the right header specifying which IJulia kernel to use (e.g. jupyter: julia-1.9), otherwise Quarto will use the default Python kernel.\nConvert your Literate.jl script to a .qmd file, e.g.\nLiterate.markdown(\"my_script.jl\", flavor = Literate.QuartoFlavor())\nRun Quarto CLI to produce your desired output format, e.g.\nquarto render my_script.qmd --to html","category":"page"},{"location":"outputformats/#Notebook-output","page":"4. Output formats","title":"4.2. Notebook output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Notebook output is generated by Literate.notebook. The (default) notebook output of the source snippet can be seen here: notebook.ipynb.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are placed in markdown cells, and the code lines have been placed in code cells. By default the notebook is also executed and output cells populated. The current working directory is set to the specified output directory the notebook is executed.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for how to configure the behavior and resulting output of Literate.notebook.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.notebook","category":"page"},{"location":"outputformats/#Literate.notebook","page":"4. Output formats","title":"Literate.notebook","text":"Literate.notebook(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a notebook from inputfile and write the result to outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Notebook-metadata","page":"4. Output formats","title":"Notebook metadata","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Jupyter notebook cells (both code cells and markdown cells) can contain metadata. This is enabled in Literate by the %% token, similar to Jupytext. The format is as follows","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"%% optional ignored text [type] {optional metadata JSON}","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Cell metadata can, for example, be used for nbgrader and the reveal.js notebook extension RISE.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The following would create a 3 slide deck with RISE:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"#nb # %% A slide [markdown] {\"slideshow\": {\"slide_type\": \"slide\"}}\n# # Some title\n#\n# We're using `#nb` so the metadata is only included in notebook output\n\n#nb %% A slide [code] {\"slideshow\": {\"slide_type\": \"fragment\"}}\nx = 1//3\ny = 2//5\n\n#nb # %% A slide [markdown] {\"slideshow\": {\"slide_type\": \"subslide\"}}\n# For more information about RISE, see [the docs](https://rise.readthedocs.io/en/stable/usage.html)","category":"page"},{"location":"outputformats/#Script-output","page":"4. Output formats","title":"4.3. Script output","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Script output is generated by Literate.script. The (default) script output of the source snippet above is as follows:","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"import Markdown\nfile = joinpath(@__DIR__, \"../src/generated/outputformats.jl\")\nstr = \"```julia\\n\" * rstrip(read(file, String)) * \"\\n```\"\nrm(file)\nMarkdown.parse(str)","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"We note that lines starting with # are removed and only the code lines have been kept.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"See the section about Configuration for how to configure the behavior and resulting output of Literate.script.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.script","category":"page"},{"location":"outputformats/#Literate.script","page":"4. Output formats","title":"Literate.script","text":"Literate.script(inputfile, outputdir=pwd(); config::AbstractDict=Dict(), kwargs...)\n\nGenerate a plain script file from inputfile and write the result to outputdir.\n\nSee the manual section on Configuration for documentation of possible configuration with config and other keyword arguments.\n\n\n\n\n\n","category":"function"},{"location":"outputformats/#Configuration","page":"4. Output formats","title":"4.4. Configuration","text":"","category":"section"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"The behavior of Literate.markdown, Literate.notebook and Literate.script can be configured by keyword arguments. There are two ways to do this; pass config::Dict as a keyword argument, or pass individual keyword arguments.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"note: Configuration precedence\nIndividual keyword arguments take precedence over the config dictionary, so for e.g. Literate.markdown(...; config = Dict(\"name\" => \"hello\"), name = \"world\") the resulting configuration for name will be \"world\". Both individual keyword arguments and the config dictionary take precedence over the default.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Available configurations with description and default values are given in the reference for Literate.DEFAULT_CONFIGURATION just below.","category":"page"},{"location":"outputformats/","page":"4. Output formats","title":"4. Output formats","text":"Literate.DEFAULT_CONFIGURATION","category":"page"},{"location":"outputformats/#Literate.DEFAULT_CONFIGURATION","page":"4. Output formats","title":"Literate.DEFAULT_CONFIGURATION","text":"DEFAULT_CONFIGURATION\n\nDefault configuration for Literate.markdown, Literate.notebook and Literate.script which is used for everything not specified by the user. Configuration can be passed as individual keyword arguments or as a dictionary passed with the config keyword argument. See the manual section about Configuration for more information.\n\nAvailable options:\n\nname (default: filename(inputfile)): Name of the output file (excluding the file extension).\npreprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.\npostprocess (default: identity): Custom preprocessing function mapping a String to a String. See Custom pre- and post-processing.\ncredit (default: true): Boolean for controlling the addition of This file was generated with Literate.jl ... to the bottom of the page. If you find Literate.jl useful then feel free to keep this.\nkeep_comments (default: false): When true, keeps markdown lines as comments in the output script. Only applicable for Literate.script.\nexecute (default: true for notebook, false for markdown): Whether to execute and capture the output. Only applicable for Literate.notebook and Literate.markdown.\ncodefence (default: \"````@example $(name)\" => \"````\" for DocumenterFlavor() and \"````julia\" => \"````\" otherwise): Pair containing opening and closing code fence for wrapping code blocks.\nflavor (default: Literate.DocumenterFlavor()) Output flavor for markdown, see Markdown flavors. Only applicable for Literate.markdown.\ndevurl (default: \"dev\"): URL for \"in-development\" docs, see Documenter docs. Unused if repo_root_url/ nbviewer_root_url/binder_root_url are set.\nsoftscope (default: true for Jupyter notebooks, false otherwise): enable/disable \"soft\" scoping rules when executing, see e.g. https://github.com/JuliaLang/SoftGlobalScope.jl.\nrepo_root_url: URL to the root of the repository. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__REPO_ROOT_URL__.\nnbviewer_root_url: URL to the root of the repository as seen on nbviewer. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__NBVIEWER_ROOT_URL__.\nbinder_root_url: URL to the root of the repository as seen on mybinder. Determined automatically on Travis CI, GitHub Actions and GitLab CI. Used for @__BINDER_ROOT_URL__.\nimage_formats: A vector of (mime, ext) tuples, with the default Tuple{MIME, String}[(MIME type image/svg+xml, \".svg\"), (MIME type image/png, \".png\"), (MIME type image/jpeg, \".jpeg\")]. Results which are showable with a MIME type are saved with the first match, with the corresponding extension.\n\n\n\n\n\n","category":"constant"},{"location":"reference/#Reference","page":"Reference","title":"Reference","text":"","category":"section"},{"location":"reference/","page":"Reference","title":"Reference","text":"Literate","category":"page"},{"location":"reference/#Literate","page":"Reference","title":"Literate","text":"Literate\n\nJulia package for Literate Programming. See https://fredrikekre.github.io/Literate.jl/ for documentation.\n\n\n\n\n\n","category":"module"},{"location":"fileformat/#File-format","page":"2. File format","title":"2. File format","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The source file format for Literate is a regular, commented, julia (.jl) scripts. The idea is that the scripts also serve as documentation on their own and it is also simple to include them in the test-suite, with e.g. include, to make sure the examples stay up to date with other changes in your package.","category":"page"},{"location":"fileformat/#Syntax","page":"2. File format","title":"2.1. Syntax","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The basic syntax is simple:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"lines starting with # are treated as markdown,\nall other lines are treated as julia code.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Leading whitespace is allowed before #, but it will be removed when generating the output. Since #-lines are treated as markdown we can not use that for regular julia comments, for this you can instead use ##, which will render as # in the output.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Lets look at a simple example:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# # Rational numbers\n#\n# In julia rational numbers can be constructed with the `//` operator.\n# Lets define two rational numbers, `x` and `y`:\n\n## Define variable x and y\nx = 1//3\ny = 2//5\n\n# When adding `x` and `y` together we obtain a new rational number:\n\nz = x + y","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"In the lines starting with # we can use regular markdown syntax, for example the # used for the heading and the backticks for formatting code. The other lines are regular julia code. We note a couple of things:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The script is valid julia, which means that we can include it and the example will run (for example in the test/runtests.jl script, to include the example in the test suite).\nThe script is \"self-explanatory\", i.e. the markdown lines works as comments and thus serve as good documentation on its own.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"For simple use this is all you need to know. The following additional special syntax can also be used:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md, #nb, #jl, #src: tags to filter lines, see Filtering lines,\n#- (#+): tag to manually control chunk-splits, see Custom control over chunk splits.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"There is also some default convenience replacements that will always be performed, see Default replacements.","category":"page"},{"location":"fileformat/#Multiline-comments-and-markdown-strings","page":"2. File format","title":"Multiline comments and markdown strings","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Literate version 2.7 adds support for Julia multiline comments for markdown input. All multiline comments in the input are rewritten to regular comments as part of the preprocessing step, before any other processing is performed. For Literate to recognize multiline comments it is required that the start token (#=) and end token (=#) are placed on their own lines. Note also that it is allowed to have more than one = in the tokens, for example","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#=\nThis multiline comment\nis treated as markdown.\n=#\n\n#=====================\nThis is also markdown.\n=====================#","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"is rewritten to","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# This multiline comment\n# is treated as markdown.\n\n# This is also markdown.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Similarly, Literate version 2.9 adds support for using literal markdown strings, md\"\"\" ... \"\"\", for the markdown sections, for example","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"md\"\"\"\n# Title\nblah blah blah\n\"\"\"","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"is rewritten to","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"# # Title\n# blah blah blah","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"This is not enabled by default – it requires passing mdstrings=true. Literate.markdown/Literate.notebook/Literate.script.","category":"page"},{"location":"fileformat/#Filtering-lines","page":"2. File format","title":"2.2. Filtering lines","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"It is often useful to filter out lines in the source depending on the output format. For this purpose there are a number of \"tokens\" that can be used to mark the purpose of certain lines:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md: line exclusive to markdown output,\n#nb: line exclusive to notebook output,\n#jl: line exclusive to script output,\n#src: line exclusive to the source code and thus filtered out unconditionally.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Lines starting or ending with one of these tokens are filtered out in the preprocessing step. In addition, for markdown output, lines ending with #hide are filtered out similar to Documenter.jl.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"note: Difference between `#src` and `#hide`\n#src and #hide are quite similar. The only difference is that #src lines are filtered out before execution (if execute=true) and #hide lines are filtered out after execution.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"tip: Tip\nThe tokens can also be negated, for example a line starting with #!nb would be included in markdown and script output, but filtered out for notebook output.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"Suppose, for example, that we want to include a docstring within a @docs block using Documenter. Obviously we don't want to include this in the notebook, since @docs is Documenter syntax that the notebook will not understand. This is a case where we can prepend #md to those lines:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"#md # ```@docs\n#md # Literate.markdown\n#md # Literate.notebook\n#md # Literate.script\n#md # ```","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The lines in the example above would be filtered out in the preprocessing step, unless we are generating a markdown file. When generating a markdown file we would simply remove the leading #md from the lines. Beware that the space after the tag is also removed.","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The #src token can also be placed at the end of a line. This is to make it possible to have code lines exclusive to the source code, and not just comment lines. For example, if the source file is included in the test suite we might want to add a @test at the end without this showing up in the outputs:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"using Test #src\n@test result == expected_result #src","category":"page"},{"location":"fileformat/#Default-replacements","page":"2. File format","title":"2.3. Default replacements","text":"","category":"section"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"The following convenience \"macros\"/source placeholders are always expanded:","category":"page"},{"location":"fileformat/","page":"2. File format","title":"2. File format","text":"@__NAME__:\nexpands to the name keyword argument to Literate.markdown, Literate.notebook and Literate.script (defaults to the filename of the input file).\n@__REPO_ROOT_URL__:\nCan be used to link to files in the repository. For example @__REPO_ROOT_URL__/src/Literate.jl would link to the source of the Literate module. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.\n@__NBVIEWER_ROOT_URL__:\nCan be used if you want a link that opens the generated notebook in http://nbviewer.jupyter.org/. This variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.\n@__BINDER_ROOT_URL__:\nCan be used if you want a link that opens the generated notebook in https://mybinder.org/. For example, to add a binder-badge in e.g. the HTML output you can use:\n[![Binder](https://mybinder.org/badge_logo.svg)](@__BINDER_ROOT_URL__/path/to/notebook.inpynb)\nThis variable is automatically determined on Travis CI, GitHub Actions and GitLab CI, but can be configured, see Configuration.","category":"page"},{"location":"#Introduction","page":"1. Introduction","title":"1. Introduction","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Welcome to the documentation for Literate – a simplistic package for Literate Programming.","category":"page"},{"location":"#What?","page":"1. Introduction","title":"What?","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate is a package that generates markdown pages (for e.g. Documenter.jl), and Jupyter notebooks, from the same source file. There is also an option to \"clean\" the source from all metadata, and produce a pure Julia script.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"The main design goal is simplicity. It should be simple to use, and the syntax should be simple. In short, all you have to do is to write a commented julia script!","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"The public interface consists of three functions, all of which take the same script file as input, but generate different output:","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate.markdown generates a markdown file. Code snippets can be executed and the results included in the output.\nLiterate.notebook generates a notebook. Code snippets can be executed and the results included in the output.\nLiterate.script generates a plain script file scrubbed from all metadata and special syntax.","category":"page"},{"location":"#Why?","page":"1. Introduction","title":"Why?","text":"","category":"section"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Examples are (probably) the best way to showcase your awesome package, and examples are often the best way for a new user to learn how to use it. It is therefore important that the documentation of your package contains examples for users to read and study. However, people are different, and we all prefer different ways of trying out a new package. Some people want to RTFM, others want to explore the package interactively in, for example, a notebook, and some people want to study the source code. The aim of Literate is to make it easy to give the user all of these options, while still keeping maintenance to a minimum.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"It is quite common that packages have \"example notebooks\" to showcase the package. Notebooks are great for showcasing a package, but they are not so great with version control, like git. The reason being that a notebook is a very \"rich\" format since it contains output and other metadata. Changes to the notebook thus result in large diffs, which makes it harder to review the actual changes.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"It is also common that packages include examples in the documentation, for example by using Documenter.jl @example-blocks. This is also great, but it is not quite as interactive as a notebook, for the users who prefer that.","category":"page"},{"location":"","page":"1. Introduction","title":"1. Introduction","text":"Literate tries to solve the problems above by creating the output as a part of the doc build. Literate generates the output based on a single source file which makes it easier to maintain, test, and keep the manual and your example notebooks in sync.","category":"page"}] } diff --git a/dev/tips/index.html b/dev/tips/index.html index 25d909cb..9e1927f7 100644 --- a/dev/tips/index.html +++ b/dev/tips/index.html @@ -1,5 +1,5 @@ -7. Tips and tricks · Literate.jl
GitHub

7. Tips and tricks

This section lists some tips and tricks that might be useful for using Literate.

Filesize of generated notebooks

When Literate executes a notebook the return value, i.e. the result of the last Julia expression in each cell is captured. By default Literate generates multiple renderings of the result in different output formats or MIMEs, just like IJulia.jl does. All of these renderings are embedded in the notebook and it is up to the notebook frontend viewer to select the most appropriate format to show to the user.

A common example is images, which can often be displayed in multiple formats, e.g. PNG (image/png), SVG (image/svg+xml) and HTML (text/html). As a result, the filesize of the generated notebook can become large.

In order to remedy this you can use the clever Julia package DisplayAs to limit the output capabilities of an object. For example, to "force" an image to be captures as image/png only, you can use

import DisplayAs
+7. Tips and tricks · Literate.jl
GitHub
7. Tips and tricks
This section lists some tips and tricks that might be useful for using Literate.
Filesize of generated notebooks
When Literate executes a notebook the return value, i.e. the result of the last Julia expression in each cell is captured. By default Literate generates multiple renderings of the result in different output formats or MIMEs, just like IJulia.jl does. All of these renderings are embedded in the notebook and it is up to the notebook frontend viewer to select the most appropriate format to show to the user.
A common example is images, which can often be displayed in multiple formats, e.g. PNG (image/png), SVG (image/svg+xml) and HTML (text/html). As a result, the filesize of the generated notebook can become large.
In order to remedy this you can use the clever Julia package DisplayAs to limit the output capabilities of an object. For example, to "force" an image to be captures as image/png only, you can use
import DisplayAs
 img = plot(...)
 img = DisplayAs.PNG(img)
This can save some memory, since the image is never captured in e.g. SVG or HTML formats.
Note
It is best to always let the object be showable as text/plain. This can be achieved by nested calls to DisplayAs output types. For example, to limit an image img to be showable as just image/png and text/plain you can use
img = plot(...)
 img = DisplayAs.Text(DisplayAs.PNG(img))
Printing tables in Markdown
Tables that support the Tables.jl interface can be included in Markdown output with the lightweight package MarkdownTables.jl.
using MarkdownTables
@@ -27,4 +27,4 @@
     This is a useful note.
and a quotation style formatting in the generated notebook cell:
> *Note*
 > This is a useful note.
which, in an actual notebook cell, will look similar to:
Note
This is a useful note.
Debugging code execution
When Literate is executing code (i.e. when execute = true is set), it does so quietly. All the output gets captured and nothing gets printed into the terminal. This can make it tricky to know where things go wrong, e.g. when the execution stalls due to an infinite loop.
To help debug this, Literate has an @debug statement that prints out each code block that is being executed. In general, to enable the printing of Literate's @debug statements, you can set the JULIA_DEBUG environment variable to "Literate".
The easiest way to do that is to set the variable in the Julia session before running Literate by doing
ENV["JULIA_DEBUG"]="Literate"
Alternatively, you can also set the environment variable before starting the Julia session, e.g.
$ JULIA_DEBUG=Literate julia
or by wrapping the Literate calls in an withenv block
withenv("JULIA_DEBUG" => "Literate") do
     Literate.notebook("myscript.jl"; execute=true)
-end

+end