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) accepts 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
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) accepts 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)
diff --git a/v2.0.0/documenter/index.html b/v2.0.0/documenter/index.html
index 0178128..5616e90 100644
--- a/v2.0.0/documenter/index.html
+++ b/v2.0.0/documenter/index.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.0.0/fileformat/index.html b/v2.0.0/fileformat/index.html
index 9906e6e..26e071a 100644
--- a/v2.0.0/fileformat/index.html
+++ b/v2.0.0/fileformat/index.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl
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 do 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 is 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
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 do 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 is 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`:
diff --git a/v2.0.0/generated/example/index.html b/v2.0.0/generated/example/index.html
index 4ec2c51..54ee4b1 100644
--- a/v2.0.0/generated/example/index.html
+++ b/v2.0.0/generated/example/index.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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.
NoteNote 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]
@@ -21,7 +21,7 @@ plot(x, [y1, y2])
@@ -29,7 +29,7 @@ plot(x, [y1, y2])
@@ -37,64 +37,64 @@ plot(x, [y1, y2])
0
@@ -124,225 +124,225 @@ plot(x, [y1, y2])
1.0
y1
y2
diff --git a/v2.0.0/generated/name/index.html b/v2.0.0/generated/name/index.html
index 8957ba9..2bd4ddf 100644
--- a/v2.0.0/generated/name/index.html
+++ b/v2.0.0/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
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.0.0/pipeline/index.html b/v2.0.0/pipeline/index.html
index 9b0576a..c4a016d 100644
--- a/v2.0.0/pipeline/index.html
+++ b/v2.0.0/pipeline/index.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
diff --git a/v2.0.0/search/index.html b/v2.0.0/search/index.html
index 6d91a63..c9635ef 100644
--- a/v2.0.0/search/index.html
+++ b/v2.0.0/search/index.html
@@ -1,2 +1,2 @@
-Search · Literate.jl
Search
Number of results: loading...
Search · Literate.jl
Search
Number of results: loading...
5. Custom pre- and post-processing · Literate.jl
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) accepts 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
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) accepts 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)
diff --git a/v2.0.2/documenter/index.html b/v2.0.2/documenter/index.html
index 0178128..5616e90 100644
--- a/v2.0.2/documenter/index.html
+++ b/v2.0.2/documenter/index.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.0.2/fileformat/index.html b/v2.0.2/fileformat/index.html
index 3ff502e..effedf6 100644
--- a/v2.0.2/fileformat/index.html
+++ b/v2.0.2/fileformat/index.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl
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 do 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 is 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
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 do 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 is 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`:
diff --git a/v2.0.2/generated/example/index.html b/v2.0.2/generated/example/index.html
index a2b5147..908f42f 100644
--- a/v2.0.2/generated/example/index.html
+++ b/v2.0.2/generated/example/index.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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.
NoteNote 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]
@@ -21,7 +21,7 @@ plot(x, [y1, y2])
@@ -29,7 +29,7 @@ plot(x, [y1, y2])
@@ -37,64 +37,64 @@ plot(x, [y1, y2])
0
@@ -124,225 +124,225 @@ plot(x, [y1, y2])
1.0
y1
y2
diff --git a/v2.0.2/generated/name/index.html b/v2.0.2/generated/name/index.html
index 8957ba9..2bd4ddf 100644
--- a/v2.0.2/generated/name/index.html
+++ b/v2.0.2/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
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.0.2/pipeline/index.html b/v2.0.2/pipeline/index.html
index 20fa73b..2712f81 100644
--- a/v2.0.2/pipeline/index.html
+++ b/v2.0.2/pipeline/index.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
diff --git a/v2.0.2/search/index.html b/v2.0.2/search/index.html
index 6d91a63..c9635ef 100644
--- a/v2.0.2/search/index.html
+++ b/v2.0.2/search/index.html
@@ -1,2 +1,2 @@
-Search · Literate.jl
Search
Number of results: loading...
Search · Literate.jl
Search
Number of results: loading...
5. Custom pre- and post-processing · Literate.jl
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) accepts 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
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) accepts 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)
diff --git a/v2.0.3/documenter/index.html b/v2.0.3/documenter/index.html
index 5afaf52..4dd45f7 100644
--- a/v2.0.3/documenter/index.html
+++ b/v2.0.3/documenter/index.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.0.3/fileformat/index.html b/v2.0.3/fileformat/index.html
index 3ff502e..effedf6 100644
--- a/v2.0.3/fileformat/index.html
+++ b/v2.0.3/fileformat/index.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl
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 do 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 is 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
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 do 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 is 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`:
diff --git a/v2.0.3/generated/example/index.html b/v2.0.3/generated/example/index.html
index 1143892..eb97c46 100644
--- a/v2.0.3/generated/example/index.html
+++ b/v2.0.3/generated/example/index.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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.
NoteNote 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]
@@ -21,7 +21,7 @@ plot(x, [y1, y2])
@@ -29,7 +29,7 @@ plot(x, [y1, y2])
@@ -37,64 +37,64 @@ plot(x, [y1, y2])
0
@@ -124,225 +124,225 @@ plot(x, [y1, y2])
1.0
y1
y2
diff --git a/v2.0.3/generated/name/index.html b/v2.0.3/generated/name/index.html
index 8957ba9..2bd4ddf 100644
--- a/v2.0.3/generated/name/index.html
+++ b/v2.0.3/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
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.0.3/pipeline/index.html b/v2.0.3/pipeline/index.html
index 20fa73b..2712f81 100644
--- a/v2.0.3/pipeline/index.html
+++ b/v2.0.3/pipeline/index.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
diff --git a/v2.0.3/search/index.html b/v2.0.3/search/index.html
index 6d91a63..c9635ef 100644
--- a/v2.0.3/search/index.html
+++ b/v2.0.3/search/index.html
@@ -1,2 +1,2 @@
-Search · Literate.jl
Search
Number of results: loading...
Search · Literate.jl
Search
Number of results: loading...
5. Custom pre- and post-processing · Literate.jl
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) accepts 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
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) accepts 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)
diff --git a/v2.0.4/documenter/index.html b/v2.0.4/documenter/index.html
index 5afaf52..4dd45f7 100644
--- a/v2.0.4/documenter/index.html
+++ b/v2.0.4/documenter/index.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl
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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.0.4/fileformat/index.html b/v2.0.4/fileformat/index.html
index 3ff502e..effedf6 100644
--- a/v2.0.4/fileformat/index.html
+++ b/v2.0.4/fileformat/index.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl
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 do 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 is 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
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 do 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 is 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`:
diff --git a/v2.0.4/generated/example/index.html b/v2.0.4/generated/example/index.html
index 18e092c..b488ea0 100644
--- a/v2.0.4/generated/example/index.html
+++ b/v2.0.4/generated/example/index.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl
7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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.
NoteNote 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]
@@ -21,7 +21,7 @@ plot(x, [y1, y2])
@@ -29,7 +29,7 @@ plot(x, [y1, y2])
@@ -37,64 +37,64 @@ plot(x, [y1, y2])
0
@@ -124,225 +124,225 @@ plot(x, [y1, y2])
1.0
y1
y2
diff --git a/v2.0.4/generated/name/index.html b/v2.0.4/generated/name/index.html
index 8957ba9..2bd4ddf 100644
--- a/v2.0.4/generated/name/index.html
+++ b/v2.0.4/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
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl
4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.0.4/pipeline/index.html b/v2.0.4/pipeline/index.html
index 20fa73b..2712f81 100644
--- a/v2.0.4/pipeline/index.html
+++ b/v2.0.4/pipeline/index.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
diff --git a/v2.0.4/search/index.html b/v2.0.4/search/index.html
index 6d91a63..c9635ef 100644
--- a/v2.0.4/search/index.html
+++ b/v2.0.4/search/index.html
@@ -1,2 +1,2 @@
-Search · Literate.jl
Search
Number of results: loading...
Search · Literate.jl
Search
Number of results: loading...
5. Custom pre- and post-processing · Literate.jl 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) accepts 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 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) accepts 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)
diff --git a/v2.1.0/documenter.html b/v2.1.0/documenter.html
index 949b205..34cb052 100644
--- a/v2.1.0/documenter.html
+++ b/v2.1.0/documenter.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl 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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl 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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.1.0/fileformat.html b/v2.1.0/fileformat.html
index 51333d3..2ef3b97 100644
--- a/v2.1.0/fileformat.html
+++ b/v2.1.0/fileformat.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl 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 do 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 is 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 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 do 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 is 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`:
diff --git a/v2.1.0/generated/example.html b/v2.1.0/generated/example.html
index b3799e2..c86597c 100644
--- a/v2.1.0/generated/example.html
+++ b/v2.1.0/generated/example.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl 7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl 7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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]
@@ -37,64 +37,64 @@ M86.9921 1521.01 L2352.76 1521.01 L2352.76 47.2441 L86.9921 47.2441 Z
0
@@ -124,225 +124,225 @@ M86.9921 1521.01 L2352.76 1521.01 L2352.76 47.2441 L86.9921 47.2441 Z
1.0
y1
y2
diff --git a/v2.1.0/generated/name.html b/v2.1.0/generated/name.html
index 7fe76bd..ea2c1d5 100644
--- a/v2.1.0/generated/name.html
+++ b/v2.1.0/generated/name.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
Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
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
Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
4. Output Formats · Literate.jl 4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl 4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.1.0/pipeline.html b/v2.1.0/pipeline.html
index 05c347b..2afc761 100644
--- a/v2.1.0/pipeline.html
+++ b/v2.1.0/pipeline.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl 3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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 3. Processing pipeline
The generation of output follows the same pipeline for all output formats:
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
diff --git a/v2.1.0/search.html b/v2.1.0/search.html
index 9f43374..44dcd3e 100644
--- a/v2.1.0/search.html
+++ b/v2.1.0/search.html
@@ -1,2 +1,2 @@
-Search · Literate.jl Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
Search · Literate.jl Settings
This document was generated with Documenter.jl on Wednesday 30 October 2019. Using Julia version 1.2.0.
5. Custom pre- and post-processing · Literate.jl 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) accepts 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 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) accepts 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)
diff --git a/v2.1.1/documenter/index.html b/v2.1.1/documenter/index.html
index 6beb2a7..52ea7e8 100644
--- a/v2.1.1/documenter/index.html
+++ b/v2.1.1/documenter/index.html
@@ -1,5 +1,5 @@
-6. Interaction with Documenter.jl · Literate.jl 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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
+6. Interaction with Documenter.jl · Literate.jl 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 lets take a look at what will happen if we set documenter = true:
Literate.markdown:
- The default code fence will change from
```julia
# code
```
to Documenters @example blocks:```@examples $(name)
# code
diff --git a/v2.1.1/fileformat/index.html b/v2.1.1/fileformat/index.html
index a811af1..be0ed7b 100644
--- a/v2.1.1/fileformat/index.html
+++ b/v2.1.1/fileformat/index.html
@@ -1,5 +1,5 @@
-2. File Format · Literate.jl 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 do 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 is 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 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 do 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 is 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`:
diff --git a/v2.1.1/generated/example/index.html b/v2.1.1/generated/example/index.html
index 4ebbbc8..f881570 100644
--- a/v2.1.1/generated/example/index.html
+++ b/v2.1.1/generated/example/index.html
@@ -1,5 +1,5 @@
-7. Example · Literate.jl 7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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
+7. Example · Literate.jl 7. Example
This is an example generated with Literate based on this source file: example.jl. You are seeing the HTML-output which Documenter have 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]
@@ -37,64 +37,64 @@ M86.9921 1521.01 L2352.76 1521.01 L2352.76 47.2441 L86.9921 47.2441 Z
0
@@ -124,225 +124,225 @@ M86.9921 1521.01 L2352.76 1521.01 L2352.76 47.2441 L86.9921 47.2441 Z
1.0
y1
y2
diff --git a/v2.1.1/generated/name/index.html b/v2.1.1/generated/name/index.html
index b988393..a7e68c9 100644
--- a/v2.1.1/generated/name/index.html
+++ b/v2.1.1/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
Settings
This document was generated with Documenter.jl on Thursday 21 November 2019. Using Julia version 1.2.0.
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
Settings
This document was generated with Documenter.jl on Thursday 21 November 2019. Using Julia version 1.2.0.
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
Settings
This document was generated with Documenter.jl on Thursday 21 November 2019. Using Julia version 1.2.0.
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 mainly of three functions, all of which take the same script file as input, but generate different output:
Literate.markdown: generates a markdown fileLiterate.notebook: generates an (optionally executed) notebookLiterate.script: generates a plain script file, removing 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 wants to RTFM, others want to explore the package interactively in, for example, a notebook, and some people wants 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.
Settings
This document was generated with Documenter.jl on Thursday 21 November 2019. Using Julia version 1.2.0.
4. Output Formats · Literate.jl 4. Output Formats
When the source is parsed, and have been processed it is time to render the output. We will consider the following source snippet:
# # Rational numbers
+4. Output Formats · Literate.jl 4. Output Formats
When the source is parsed, and have 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`:
diff --git a/v2.1.1/pipeline/index.html b/v2.1.1/pipeline/index.html
index 295aa5a..0c7e327 100644
--- a/v2.1.1/pipeline/index.html
+++ b/v2.1.1/pipeline/index.html
@@ -1,5 +1,5 @@
-3. Processing pipeline · Literate.jl