diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index 048daa6..02fa448 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.10.2","generation_timestamp":"2024-04-16T23:06:33","documenter_version":"1.3.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.10.3","generation_timestamp":"2024-06-01T20:24:21","documenter_version":"1.3.0"}} \ No newline at end of file diff --git a/dev/changelog/index.html b/dev/changelog/index.html index 3600ffd..0bd9d69 100644 --- a/dev/changelog/index.html +++ b/dev/changelog/index.html @@ -1,3 +1,3 @@ 9. Changelog · Literate.jl

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.18.0 - 2024-04-17

Added

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.

+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

    Deprecated

    v2.8 - 2021-01-19

    Added

    v2.7 - 2021-09-12

    Added

    v2.6 - 2020-08-15

    Added

    v2.5 - 2020-05-14

    Changed

    v2.4 - 2020-04-23

    Added

    v2.3 - 2020-03-03

    Added

    v2.2 - 2019-11-26

    Added

    v2.1 - 2019-10-30

    Added

    v2.0 - 2019-07-19

    Added

    Changed

    v1.1 - 2019-04-05

    Added

    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 775c7d3..5e38b91 100644 --- a/dev/customprocessing/index.html +++ b/dev/customprocessing/index.html @@ -26,4 +26,4 @@ include("file2.jl")

    Let's say we have saved this fi 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 32b7f58..4545e36 100644 --- a/dev/documenter/index.html +++ b/dev/documenter/index.html @@ -11,4 +11,4 @@ EditURL = "$(relpath(inputfile, outputdir))" \int f dx $$
  • Whereas Documenter requires HTML blocks to be escaped
    ```@raw html
     <tag>...</tag>
    -```
    the output to a notebook markdown cell will be raw HTML
    <tag>...</tag>
  • Literate.script:

    +```the output to a notebook markdown cell will be raw HTML
    <tag>...</tag>

    Literate.script:

    diff --git a/dev/fileformat/index.html b/dev/fileformat/index.html index 714684a..adffe8c 100644 --- a/dev/fileformat/index.html +++ b/dev/fileformat/index.html @@ -29,4 +29,4 @@ blah blah blah #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:

    +@test result == expected_result #src

    2.3. Default replacements

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

    diff --git a/dev/generated/example.ipynb b/dev/generated/example.ipynb index a9e2b67..73ac246 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": {}, @@ -529,11 +529,11 @@ "file_extension": ".jl", "mimetype": "application/julia", "name": "julia", - "version": "1.10.2" + "version": "1.10.3" }, "kernelspec": { "name": "julia-1.10", - "display_name": "Julia 1.10.2", + "display_name": "Julia 1.10.3", "language": "julia" } }, diff --git a/dev/generated/example/d840a48e.svg b/dev/generated/example/ebce968b.svg similarity index 92% rename from dev/generated/example/d840a48e.svg rename to dev/generated/example/ebce968b.svg index a86e834..cb56812 100644 --- a/dev/generated/example/d840a48e.svg +++ b/dev/generated/example/ebce968b.svg @@ -1,46 +1,46 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/generated/example/index.html b/dev/generated/example/index.html index 58a07d0..f3db83a 100644 --- a/dev/generated/example/index.html +++ b/dev/generated/example/index.html @@ -13,7 +13,7 @@ foo()

    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 3ad980d..57ffea6 100644 --- a/dev/generated/name/index.html +++ b/dev/generated/name/index.html @@ -1,2 +1,2 @@ -Rational numbers · Literate.jl

    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

    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/generated/notebook.ipynb b/dev/generated/notebook.ipynb index 5c4e676..063956a 100644 --- a/dev/generated/notebook.ipynb +++ b/dev/generated/notebook.ipynb @@ -87,11 +87,11 @@ "file_extension": ".jl", "mimetype": "application/julia", "name": "julia", - "version": "1.10.2" + "version": "1.10.3" }, "kernelspec": { "name": "julia-1.10", - "display_name": "Julia 1.10.2", + "display_name": "Julia 1.10.3", "language": "julia" } }, diff --git a/dev/index.html b/dev/index.html index 3fce426..ced6f72 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -1. Introduction · Literate.jl

    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

    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/outputformats/index.html b/dev/outputformats/index.html index cd269f7..d14c392 100644 --- a/dev/outputformats/index.html +++ b/dev/outputformats/index.html @@ -42,10 +42,10 @@ x = 1//3 ```` ```` 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.markdownFunction
    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.markdownFunction
      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.notebookFunction
      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.notebookFunction
    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
     
     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.scriptFunction
    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_CONFIGURATIONConstant
    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.scriptFunction
    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_CONFIGURATIONConstant
    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 05022d2..ef136a0 100644 --- a/dev/pipeline/index.html +++ b/dev/pipeline/index.html @@ -29,4 +29,4 @@ x = 1 // 3 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 4b8a0d1..dad4b06 100644 --- a/dev/reference/index.html +++ b/dev/reference/index.html @@ -1,2 +1,2 @@ -Reference · Literate.jl

    Reference

    LiterateModule
    Literate

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

    source
    +Reference · Literate.jl

    Reference

    LiterateModule
    Literate

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

    source
    diff --git a/dev/tips/index.html b/dev/tips/index.html index 124b3ed..09dba66 100644 --- a/dev/tips/index.html +++ b/dev/tips/index.html @@ -27,4 +27,4 @@ Literate.notebook("example.jl", "tmp/"; preprocess = nb_note 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