<htmllang="en"><head><metacharset="UTF-8"/><metaname="viewport"content="width=device-width, initial-scale=1.0"/><title>5. Custom pre- and post-processing · Literate.jl</title><linkhref="https://cdnjs.cloudflare.com/ajax/libs/normalize/4.2.0/normalize.min.css"rel="stylesheet"type="text/css"/><linkhref="https://fonts.googleapis.com/css?family=Lato|Roboto+Mono"rel="stylesheet"type="text/css"/><linkhref="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css"rel="stylesheet"type="text/css"/><linkhref="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/default.min.css"rel="stylesheet"type="text/css"/><script>documenterBaseURL="."</script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.2.0/require.min.js"data-main="assets/documenter.js"></script><scriptsrc="siteinfo.js"></script><scriptsrc="../versions.js"></script><linkhref="assets/documenter.css"rel="stylesheet"type="text/css"/></head><body><navclass="toc"><ahref="index.html"><imgclass="logo"src="assets/logo.png"alt="Literate.jl logo"/></a><h1>Literate.jl</h1><selectid="version-selector"onChange="window.location.href=this.value"style="visibility: hidden"></select><formclass="search"id="search-form"action="search.html"><inputid="search-query"name="q"type="text"placeholder="Search docs"/></form><ul><li><aclass="toctext"href="index.html"><strong>1.</strong> Introduction</a></li><li><aclass="toctext"href="fileformat.html"><strong>2.</strong> File Format</a></li><li><aclass="toctext"href="pipeline.html"><strong>3.</strong> Processing pipeline</a></li><li><aclass="toctext"href="outputformats.html"><strong>4.</strong> Output Formats</a></li><liclass="current"><aclass="toctext"href="customprocessing.html"><strong>5.</strong> Custom pre- and post-processing</a><ulclass="internal"></ul></li><li><aclass="toctext"href="documenter.html"><strong>6.</strong> Interaction with Documenter.jl</a></li><li><aclass="toctext"href="generated/example.html"><strong>7.</strong> Example</a></li></ul></nav><articleid="docs"><header><nav><ul><li><ahref="customprocessing.html"><strong>5.</strong> Custom pre- and post-processing</a></li></ul><aclass="edit-page"href="https://github.com/fredrikekre/Literate.jl/blob/master/docs/src/customprocessing.md"><spanclass="fa"></span> Edit on GitHub</a></nav><hr/><divid="topbar"><span>5. Custom pre- and post-processing</span><aclass="fa fa-bars"href="#"></a></div></header><h1><aclass="nav-anchor"id="Custom-pre-and-post-processing-1"href="#Custom-pre-and-post-processing-1"><strong>5.</strong> Custom pre- and post-processing</a></h1><p>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 <ahref="fileformat.html#Filtering-Lines-1">line filtering</a> 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.</p><p>All of the generators (<ahref="outputformats.html#Literate.markdown"><code>Literate.markdown</code></a>, <ahref="outputformats.html#Literate.notebook"><code>Literate.notebook</code></a> and <ahref="outputformats.html#Literate.script"><code>Literate.script</code></a>) accepts <code>preprocess</code> and <code>postprocess</code> keyword arguments. The default "transformation" is the <code>identity</code> function. The input to the transformation functions is a <code>String</code>, and the output should be the transformed <code>String</code>.</p><p><code>preprocess</code> is sent the raw input that is read from the source file (<ahref="pipeline.html#Pre-processing-1">modulo the default line ending transformation</a>). <code>postprocess</code> is given different things depending on the output: For markdown and script output <code>postprocess</code> is given the content <code>String</code> just before writing it to the output file, but for notebook output <code>postprocess</code> is given the dictionary representing the notebook, since, in general, this is more useful.</p><p>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 <code>preprocess</code> function that splices the date into the source for us. Consider the following source file:</p><pre><codeclass="language-julia"># # Example
<htmllang="en"><head><metacharset="UTF-8"/><metaname="viewport"content="width=device-width, initial-scale=1.0"/><title>5. Custom pre- and post-processing · Literate.jl</title><linkhref="https://cdnjs.cloudflare.com/ajax/libs/normalize/4.2.0/normalize.min.css"rel="stylesheet"type="text/css"/><linkhref="https://fonts.googleapis.com/css?family=Lato|Roboto+Mono"rel="stylesheet"type="text/css"/><linkhref="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css"rel="stylesheet"type="text/css"/><linkhref="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/default.min.css"rel="stylesheet"type="text/css"/><script>documenterBaseURL="."</script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.2.0/require.min.js"data-main="assets/documenter.js"></script><scriptsrc="siteinfo.js"></script><scriptsrc="../versions.js"></script><linkhref="assets/documenter.css"rel="stylesheet"type="text/css"/></head><body><navclass="toc"><ahref="index.html"><imgclass="logo"src="assets/logo.png"alt="Literate.jl logo"/></a><h1>Literate.jl</h1><selectid="version-selector"onChange="window.location.href=this.value"style="visibility: hidden"></select><formclass="search"id="search-form"action="search.html"><inputid="search-query"name="q"type="text"placeholder="Search docs"/></form><ul><li><aclass="toctext"href="index.html"><strong>1.</strong> Introduction</a></li><li><aclass="toctext"href="fileformat.html"><strong>2.</strong> File Format</a></li><li><aclass="toctext"href="pipeline.html"><strong>3.</strong> Processing pipeline</a></li><li><aclass="toctext"href="outputformats.html"><strong>4.</strong> Output Formats</a></li><liclass="current"><aclass="toctext"href="customprocessing.html"><strong>5.</strong> Custom pre- and post-processing</a><ulclass="internal"></ul></li><li><aclass="toctext"href="documenter.html"><strong>6.</strong> Interaction with Documenter.jl</a></li><li><aclass="toctext"href="generated/example.html"><strong>7.</strong> Example</a></li></ul></nav><articleid="docs"><header><nav><ul><li><ahref="customprocessing.html"><strong>5.</strong> Custom pre- and post-processing</a></li></ul><aclass="edit-page"href="https://github.com/fredrikekre/Literate.jl/blob/master/docs/src/customprocessing.md"><spanclass="fa"></span> Edit on GitHub</a></nav><hr/><divid="topbar"><span>5. Custom pre- and post-processing</span><aclass="fa fa-bars"href="#"></a></div></header><h1><aclass="nav-anchor"id="Custom-pre-and-post-processing-1"href="#Custom-pre-and-post-processing-1"><strong>5.</strong> Custom pre- and post-processing</a></h1><p>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 <ahref="fileformat.html#Filtering-Lines-1">line filtering</a> 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.</p><p>All of the generators (<ahref="outputformats.html#Literate.markdown"><code>Literate.markdown</code></a>, <ahref="outputformats.html#Literate.notebook"><code>Literate.notebook</code></a> and <ahref="outputformats.html#Literate.script"><code>Literate.script</code></a>) accepts <code>preprocess</code> and <code>postprocess</code> keyword arguments. The default "transformation" is the <code>identity</code> function. The input to the transformation functions is a <code>String</code>, and the output should be the transformed <code>String</code>.</p><p><code>preprocess</code> is sent the raw input that is read from the source file (<ahref="pipeline.html#Pre-processing-1">modulo the default line ending transformation</a>). <code>postprocess</code> is given different things depending on the output: For markdown and script output <code>postprocess</code> is given the content <code>String</code> just before writing it to the output file, but for notebook output <code>postprocess</code> is given the dictionary representing the notebook, since, in general, this is more useful.</p><h3><aclass="nav-anchor"id="Example:-Adding-current-date-1"href="#Example:-Adding-current-date-1">Example: Adding current date</a></h3><p>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 <code>preprocess</code> function that splices the date into the source for us. Consider the following source file:</p><pre><codeclass="language-julia"># # Example
# This example was generated DATEOFTODAY
# This example was generated DATEOFTODAY
x = 1 // 3</code></pre><p>where <code>DATEOFTODAY</code> is a placeholder, to make it easier for our <code>preprocess</code> function to find the location. Now, lets define the <code>preprocess</code> function, for example</p><pre><codeclass="language-julia">function update_date(content)
x = 1 // 3</code></pre><p>where <code>DATEOFTODAY</code> is a placeholder, to make it easier for our <code>preprocess</code> function to find the location. Now, lets define the <code>preprocess</code> function, for example</p><pre><codeclass="language-julia">function update_date(content)
end</code></pre><p>which would replace every occurrence of <code>"DATEOFTODAY"</code> with the current date. We would now simply give this function to the generator, for example:</p><pre><codeclass="language-julia">Literate.markdown("input.jl", "outputdir"; preprocess = update_date)</code></pre><footer><hr/><aclass="previous"href="outputformats.html"><spanclass="direction">Previous</span><spanclass="title"><strong>4.</strong> Output Formats</span></a><aclass="next"href="documenter.html"><spanclass="direction">Next</span><spanclass="title"><strong>6.</strong> Interaction with Documenter.jl</span></a></footer></article></body></html>
end</code></pre><p>which would replace every occurrence of <code>"DATEOFTODAY"</code> with the current date. We would now simply give this function to the generator, for example:</p><pre><codeclass="language-julia">Literate.markdown("input.jl", "outputdir"; preprocess = update_date)</code></pre><h3><aclass="nav-anchor"id="Example:-Replacing-include-calls-with-included-code-1"href="#Example:-Replacing-include-calls-with-included-code-1">Example: Replacing <code>include</code> calls with included code</a></h3><p>Let's say that we have some individual example files <code>file1, file2, ...</code> etc. that are <em>runnable</em> and also following the style of Literate. These files could be for example used in the test suite of your package.</p><p>We want to group them all into a single page in our documentation, but we do not want to copy paste the content of <code>file1, ...</code> for robustness: the files are included in the test suite and some changes may occur to them. We want these changes to also be reflected in the documentation.</p><p>A very easy way to do this is using <code>preprocess</code> to interchange <code>include</code> statements with file content. First, create a runnable <code>.jl</code> following the format of Literate</p><pre><codeclass="language-julia"># # Replace includes
# This is an example to replace `include` calls with the actual file content.
include("file1.jl")
# Cool, we just saw the result of the above code snippet. Here is one more:
include("file2.jl")</code></pre><p>Let's say we have saved this file as <code>examples.jl</code>. Then, you want to properly define a pre-processing function:</p><pre><codeclass="language-julia">function replace_includes(str)
included = ["file1.jl", "file2.jl"]
# Here the path loads the files from their proper directory,
# which may not be the directory of the `examples.jl` file!
end</code></pre><p>(of course replace <code>included</code> with your respective files)</p><p>Finally, you simply pass this function to e.g. <ahref="outputformats.html#Literate.markdown"><code>Literate.markdown</code></a> as</p><pre><codeclass="language-julia">Literate.markdown("examples.jl", "path/to/save/markdown";
name = "markdown_file_name", preprocess = replace_includes)</code></pre><p>and you will see that in the final output file (here <code>markdown_file_name.md</code>) the <code>include</code> statements are replaced with the actual code to be included!</p><p>This approach is used for example in the documentation of the Julia package <ahref="https://github.com/JuliaDynamics/TimeseriesPrediction.jl"><code>TimeseriesPrediction</code></a>, see <ahref="https://github.com/JuliaDynamics/DynamicalSystems.jl/blob/master/docs/src/tsprediction/stexamples.jl">here</a> and <ahref="https://github.com/JuliaDynamics/DynamicalSystems.jl/blob/master/docs/make.jl#L11-L29">here for the generating script</a></p><footer><hr/><aclass="previous"href="outputformats.html"><spanclass="direction">Previous</span><spanclass="title"><strong>4.</strong> Output Formats</span></a><aclass="next"href="documenter.html"><spanclass="direction">Next</span><spanclass="title"><strong>6.</strong> Interaction with Documenter.jl</span></a></footer></article></body></html>
@ -213,7 +213,23 @@ var documenterSearchIndex = {"docs": [
"page":"5. Custom pre- and post-processing",
"page":"5. Custom pre- and post-processing",
"title":"5. Custom pre- and post-processing",
"title":"5. Custom pre- and post-processing",
"category":"section",
"category":"section",
"text":"Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.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.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\n# This example was generated DATEOFTODAY\n\nx = 1 // 3where DATEOFTODAY is a placeholder, to make it easier for our preprocess function to find the location. Now, lets define the preprocess function, for examplefunction update_date(content)\n content = replace(content, \"DATEOFTODAY\" => Date(now()))\n return content\nendwhich would replace every occurrence of \"DATEOFTODAY\" with the current date. We would now simply give this function to the generator, for example:Literate.markdown(\"input.jl\", \"outputdir\"; preprocess = update_date)"
"text":"Since all packages are different, and may have different demands on how to create a nice example for the documentation it is important that the package maintainer does not feel limited by the by default provided syntax that this package offers. While you can generally come a long way by utilizing line filtering there might be situations where you need to manually hook into the generation and change things. In Literate this is done by letting the user supply custom pre- and post-processing functions that may do transformation of the content.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."
"text":"As an example, lets say we want to splice the date of generation into the output. We could of course update our source file before generating the docs, but we could instead use a preprocess function that splices the date into the source for us. Consider the following source file:# # Example\n# This example was generated DATEOFTODAY\n\nx = 1 // 3where DATEOFTODAY is a placeholder, to make it easier for our preprocess function to find the location. Now, lets define the preprocess function, for examplefunction update_date(content)\n content = replace(content, \"DATEOFTODAY\" => Date(now()))\n return content\nendwhich would replace every occurrence of \"DATEOFTODAY\" with the current date. We would now simply give this function to the generator, for example:Literate.markdown(\"input.jl\", \"outputdir\"; preprocess = update_date)"
"title":"Example: Replacing include calls with included code",
"category":"section",
"text":"Let\'s say that we have some individual example files file1, file2, ... etc. that are runnable and also following the style of Literate. These files could be for example used in the test suite of your package.We want to group them all into a single page in our documentation, but we do not want to copy paste the content of file1, ... for robustness: the files are included in the test suite and some changes may occur to them. We want these changes to also be reflected in the documentation.A very easy way to do this is using preprocess to interchange include statements with file content. First, create a runnable .jl following the format of Literate# # Replace includes\n# This is an example to replace `include` calls with the actual file content.\n\ninclude(\"file1.jl\")\n\n# Cool, we just saw the result of the above code snippet. Here is one more:\n\ninclude(\"file2.jl\")Let\'s say we have saved this file as examples.jl. Then, you want to properly define a pre-processing function:function replace_includes(str)\n\n included = [\"file1.jl\", \"file2.jl\"]\n\n # Here the path loads the files from their proper directory,\n # which may not be the directory of the `examples.jl` file!\n path = \"directory/to/example/files/\"\n\n for ex in included\n content = read(path*ex, String)\n str = replace(str, \"include(\\\"$(ex)\\\")\" => content)\n end\n return str\nend(of course replace included with your respective files)Finally, you simply pass this function to e.g. Literate.markdown asLiterate.markdown(\"examples.jl\", \"path/to/save/markdown\";\n name = \"markdown_file_name\", preprocess = replace_includes)and you will see that in the final output file (here markdown_file_name.md) the include statements are replaced with the actual code to be included!This approach is used for example in the documentation of the Julia package TimeseriesPrediction, see here and here for the generating script"
autodocs
7 years ago