` block, you can put this construction wherever you like and locally style your text. + +### LaTeX and Maths + +Essentially three things are imitated from LaTeX + +1. you can introduce definitions using `\newcommand` +1. you can use hyper-references with `\eqref`, `\cite`, ... +1. you can show nice maths (via KaTeX) + +The definitions can be introduced in the page or in the `config.md` (in which case they're available everywhere as opposed to just in that page). +For instance, the commands `\scal` and `\R` are defined in the config file (see `src/config.md`) and can directly be used whereas the command `\E` is defined below (and therefore only available on this page): + +\newcommand{\E}[1]{\mathbb E\left[#1\right]} + +Now we can write something like + +$$ \varphi(\E{X}) \le \E{\varphi(X)}. \label{equation blah} $$ + +since we've given it the label `\label{equation blah}`, we can refer it like so: \eqref{equation blah} which can be convenient for pages that are math-heavy. + +In a similar vein you can cite references that would be at the bottom of the page: \citep{noether15, bezanson17}. + +**Note**: the LaTeX commands you define can also incorporate standard markdown (though not in a math environment) so for instance let's define a silly `\bolditalic` command. + +\newcommand{\bolditalic}[1]{_**!#1**_} + +and use it \bolditalic{here for example}. + +Here's another quick one, a command to change the color: + +\newcommand{\col}[2]{~~~#2~~~} + +This is \col{blue}{in blue} or \col{#bf37bc}{in #bf37bc}. + +### A quick note on whitespaces + +For most commands you will use `#k` to refer to the $k$-th argument as in LaTeX. +In order to reduce headaches, this forcibly introduces a whitespace on the left of whatever is inserted which, usually, changes nothing visible (e.g. in a math settings). +However there _may be_ situations where you do not want this to happen and you know that the insertion will not clash with anything else. +In that case, you should simply use `!#k` which will not introduce that whitespace. +It's probably easier to see this in action: + +\newcommand{\pathwith}[1]{`/usr/local/bin/#1`} +\newcommand{\pathwithout}[1]{`/usr/local/bin/!#1`} + +* with: \pathwith{script.jl}, there's a whitespace you don't want 🚫 +* without: \pathwithout{script.jl} here there isn't ✅ + +### Raw HTML + +You can include raw HTML by just surrounding a block with `~~~`. +Not much more to add. +This may be useful for local custom layouts like having a photo next to a text in a specific way. + +~~~ +

+ Marine iguanas are truly splendid creatures. They're found on the Gálapagos islands, have skin that basically acts as a solar panel, can swim and may have the ability to adapt their body size depending on whether there's food or not. +

+ Evolution is cool. +

+~~~ + +**Note 1**: again, entire such blocks can be made into latex-like commands via `\newcommand{\mynewblock}[1]{...}`. + +**Note 2**: whatever is in a raw HTML block is *not* further processed (so you can't have LaTeX in there for instance). A partial way around this is to use `@@...` blocks which *will* be recursively parsed. The following code gives the same result as above with the small difference that there is LaTeX being processed in the inner div. + +@@row +@@container +@@left ![](/assets/rndimg.jpg) @@ +@@ +Marine iguanas are **truly splendid** creatures. They're not found in equations like $\exp(-i\pi)+1$. But they're still quite cool. +~~~ +

+~~~ +@@ + +## Pages and structure + +Here are a few empty pages connecting to the menu links to show where files can go and the resulting paths. (It's probably best if you look at the source folder for this). + +* [menu 1](/menu1/) +* [menu 2](/menu2/) +* [menu 3](/menu3/) + +## References (not really) + +* \biblabel{noether15}{Noether (1915)} **Noether**, Körper und Systeme rationaler Funktionen, 1915. +* \biblabel{bezanson17}{Bezanson et al. (2017)} **Bezanson**, **Edelman**, **Karpinski** and **Shah**, [Julia: a fresh approach to numerical computing](https://julialang.org/research/julia-fresh-approach-BEKS.pdf), SIAM review 2017. + +## Header and Footer + +As you can see here at the bottom of the page, there is a footer which you may want on all pages but for instance you may want the date of last modification to be displayed. +In a fashion heavily inspired by [Hugo](https://gohugo.io), you can write things like + +```html +Last modified: {{ fill fd_mtime }}. +``` + +(cf. `src/_html_parts/page_foot.html`) which will then replace these braces with the content of a dictionary of variables at the key `fd_mtime`. +This dictionary of variables is accessed locally by pages through `@def varname = value` and globally through the `config.md` page via the same syntax. + +There's a few other such functions of the form `{{fname p₁ p₂}}` as well as support for conditional blocks. If you wander through the `src/_html_parts/` folder and its content, you should be able to see those in action. diff --git a/menu1.md b/menu1.md new file mode 100644 index 0000000..219f466 --- /dev/null +++ b/menu1.md @@ -0,0 +1,83 @@ +@def title = "Code blocks" +@def hascode = true +@def date = Date(2019, 3, 22) +@def rss = "A short description of the page which would serve as **blurb** in a `RSS` feed; you can use basic markdown here but the whole description string must be a single line (not a multiline string). Like this one for instance. Keep in mind that styling is minimal in RSS so for instance don't expect maths or fancy styling to work; images should be ok though: ![](https://upload.wikimedia.org/wikipedia/en/3/32/Rick_and_Morty_opening_credits.jpeg)" + +@def tags = ["syntax", "code"] + +# Working with code blocks + +\toc + +## Live evaluation of code blocks + +If you would like to show code as well as what the code outputs, you only need to specify where the script corresponding to the code block will be saved. + +Indeed, what happens is that the code block gets saved as a script which then gets executed. +This also allows for that block to not be re-executed every time you change something _else_ on the page. + +Here's a simple example (change values in `a` to see the results being live updated): + +```julia:./exdot.jl +using LinearAlgebra +a = [1, 2, 3, 3, 4, 5, 2, 2] +@show dot(a, a) +println(dot(a, a)) +``` + +You can now show what this would look like: + +\output{./exdot.jl} + +**Notes**: +* you don't have to specify the `.jl` (see below), +* you do need to explicitly use print statements or `@show` for things to show, so just leaving a variable at the end like you would in the REPL will show nothing, +* only Julia code blocks are supported at the moment, there may be a support for scripting languages like `R` or `python` in the future, +* the way you specify the path is important; see [the docs](https://tlienart.github.io/franklindocs/code/index.html#more_on_paths) for more info. If you don't care about how things are structured in your `/assets/` folder, just use `./scriptname.jl`. If you want things to be grouped, use `./group/scriptname.jl`. For more involved uses, see the docs. + +Lastly, it's important to realise that if you don't change the content of the code, then that code will only be executed _once_ even if you make multiple changes to the text around it. + +Here's another example, + +```julia:./code/ex2 +for i ∈ 1:5, j ∈ 1:5 + print(" ", rpad("*"^i,5), lpad("*"^(6-i),5), j==5 ? "\n" : " "^4) +end +``` + +which gives the (utterly useless): + +\output{./code/ex2} + +note the absence of `.jl`, it's inferred. + +You can also hide lines (that will be executed nonetheless): + +```julia:./code/ex3 +using Random +Random.seed!(1) # hide +@show randn(2) +``` + +\output{./code/ex3} + + +## Including scripts + +Another approach is to include the content of a script that has already been executed. +This can be an alternative to the description above if you'd like to only run the code once because it's particularly slow or because it's not Julia code. +For this you can use the `\input` command specifying which language it should be tagged as: + + +\input{julia}{/_assets/scripts/script1.jl} + + +these scripts can be run in such a way that their output is also saved to file, see `scripts/generate_results.jl` for instance, and you can then also input the results: + +\output{/_assets/scripts/script1.jl} + +which is convenient if you're presenting code. + +**Note**: paths specification matters, see [the docs](https://tlienart.github.io/franklindocs/code/index.html#more_on_paths) for details. + +Using this approach with the `generate_results.jl` file also makes sure that all the code on your website works and that all results match the code which makes maintenance easier. diff --git a/menu2.md b/menu2.md new file mode 100644 index 0000000..674b19a --- /dev/null +++ b/menu2.md @@ -0,0 +1,132 @@ +@def title = "More goodies" +@def hascode = true +@def rss = "A short description of the page which would serve as **blurb** in a `RSS` feed; you can use basic markdown here but the whole description string must be a single line (not a multiline string). Like this one for instance. Keep in mind that styling is minimal in RSS so for instance don't expect maths or fancy styling to work; images should be ok though: ![](https://upload.wikimedia.org/wikipedia/en/b/b0/Rick_and_Morty_characters.jpg)" +@def rss_title = "More goodies" +@def rss_pubdate = Date(2019, 5, 1) + +@def tags = ["syntax", "code", "image"] + +# More goodies + +\toc + +## More markdown support + +The Julia Markdown parser in Julia's stdlib is not exactly complete and Franklin strives to bring useful extensions that are either defined in standard specs such as Common Mark or that just seem like useful extensions. + +* indirect references for instance [like so] + +[like so]: http://existentialcomics.com/ + +or also for images + +![][some image] + +some people find that useful as it allows referring multiple times to the same link for instance. + +[some image]: https://upload.wikimedia.org/wikipedia/commons/9/90/Krul.svg + +* un-qualified code blocks and indented code blocks are allowed and are julia by default + + a = 1 + b = a+1 + +or + +``` +a = 1 +b = a+1 +``` + +you can specify the default language with `@def lang = "julia"`. +If you actually want a "plain" code block, qualify it as `plaintext` like + +```plaintext +so this is plain-text stuff. +``` + +## A bit more highlighting + +Extension of highlighting for `pkg` an `shell` mode in Julia: + +```julia-repl +(v1.4) pkg> add Franklin +shell> blah +julia> 1+1 +(Sandbox) pkg> resolve +``` + +you can tune the colouring in the CSS etc via the following classes: + +* `.hljs-meta` (for `julia>`) +* `.hljs-metas` (for `shell>`) +* `.hljs-metap` (for `...pkg>`) + +## More customisation + +Franklin, by design, gives you a lot of flexibility to define how you want stuff be done, this includes doing your own parsing/processing and your own HTML generation using Julia code. + +In order to do this, you can define two types of functions in a `utils.jl` file which will complement your `config.md` file: + +* `hfun_*` allow you to plug custom-generated HTML somewhere +* `lx_*` allow you to do custom parsing of markdown and generation of HTML + +The former (`hfun_*`) is most likely to be useful. + +### Custom "hfun" + +If you define a function `hfun_bar` in the `utils.jl` then you have access to a new template function `{{bar ...}}`. The parameters are passed as a list of strings, for instance variable names but it could just be strings as well. + +For instance: + +```julia +function hfun_bar(vname) + val = Meta.parse(vname[1]) + return round(sqrt(val), digits=2) +end +``` + +~~~ +.hf {background-color:black;color:white;font-weight:bold;} +~~~ + +Can be called with `{{bar 4}}`: **{{bar 4}}**. + +Usually you will want to pass variable name (either local or global) and collect their value via one of `locvar`, `globvar` or `pagevar` depending on your use case. +Let's have another toy example: + +```julia +function hfun_m1fill(vname) + var = vname[1] + return pagevar("menu1", var) +end +``` + +Which you can use like this `{{m1fill title}}`: **{{m1fill title}}**. Of course in this specific case you could also have used `{{fill title menu1}}`: **{{fill title menu1}}**. + +Of course these examples are not very useful, in practice you might want to use it to generate actual HTML in a specific way using Julia code. +For instance you can use it to customise how [tag pages look like](/menu3/#customising_tag_pages). + +A nice example of what you can do is in the [SymbolicUtils.jl manual](https://juliasymbolics.github.io/SymbolicUtils.jl/api/) where they use a `hfun_` to generate HTML encapsulating the content of code docstrings, in a way doing something similar to what Documenter does. See [how they defined it](https://github.com/JuliaSymbolics/SymbolicUtils.jl/blob/website/utils.jl). + +**Note**: the output **will not** be reprocessed by Franklin, if you want to generate markdown which should be processed by Franklin, then use `return fd2html(markdown, internal=true)` at the end. + +### Custom "lx" + +These commands will look the same as latex commands but what they do with their content is now entirely controlled by your code. +You can use this to do your own parsing of specific chunks of your content if you so desire. + +The definition of `lx_*` commands **must** look like this: + +```julia +function lx_baz(com, _) + # keep this first line + brace_content = Franklin.content(com.braces[1]) # input string + # do whatever you want here + return uppercase(brace_content) +end +``` + +You can call the above with `\baz{some string}`: \baz{some string}. + +**Note**: the output **will be** reprocessed by Franklin, if you want to avoid this, then escape the output by using `return "~~~" * s * "~~~"` and it will be plugged in as is in the HTML. diff --git a/menu3.md b/menu3.md new file mode 100644 index 0000000..d970cee --- /dev/null +++ b/menu3.md @@ -0,0 +1,99 @@ +@def title = "Menu 3" + +# Working with tags + +**Example**: + +* page with tag [`syntax`](/tag/syntax/) +* page with tag [`image`](/tag/image/) +* page with tag [`code`](/tag/code/) + +\toc + +## Indicating tags + +To mark a page with tags, add: + +```markdown +@def tags = ["tag1", "tag2"] +``` + +then that page, along with all others that have the tag `tag1` will be listed at `/tag/tag1/`. + +## Customising tag pages + +You can change how a `/tag/...` page looks like by modifying the `_layout/tag.html`. An important note is that you can **only** use **global** page variables (defined in `config.md`). + +There are three "exceptions": + +1. you can still use `{{ispage /tag/tagname/}} ... {{end}}` (or `{{isnotpage ...}}`) to have a different layout depending on the tag, +1. you can use the `fd_tag` variable which contains the name of the tag so `{{fill fd_tag}}` will input the tag string as is, +1. you can use `{{fill varname path/to/page}}` to exploit a page variable defined in a specific page. + +## Customising tag lists + +By default the tag list is very simple: it just collects all pages that match the tags and it shows them in a simple list by anti-chronological order (more recent at the top). + +You can customise this by defining your own `hfun_custom_taglist` function in the `utils.jl` file. The commented blueprint for the simple default setting is below and should give you an idea of how to write your own generator. + +Assuming you've defined such a function, don't forget to use `{{custom_taglist}}` in the `_layout/tag.html` instead of the default `{{taglist}}`. + +```julia +function hfun_custom_taglist()::String + # ----------------------------------------- + # Part1: Retrieve all pages associated with + # the tag & sort them + # ----------------------------------------- + # retrieve the tag string + tag = locvar(:fd_tag) + # recover the relative paths to all pages that have that + # tag, these are paths like /blog/page1 + rpaths = globvar("fd_tag_pages")[tag] + # you might want to sort these pages by chronological order + # you could also only show the most recent 5 etc... + sorter(p) = begin + # retrieve the "date" field of the page if defined, otherwise + # use the date of creation of the file + pvd = pagevar(p, :date) + if isnothing(pvd) + return Date(Dates.unix2datetime(stat(p * ".md").ctime)) + end + return pvd + end + sort!(rpaths, by=sorter, rev=true) + + # -------------------------------- + # Part2: Write the HTML to plug in + # -------------------------------- + # instantiate a buffer in which we will write the HTML + # to plug in the tag page + c = IOBuffer() + write(c, "...1...") + # go over all paths + for rpath in rpaths + # recover the url corresponding to the rpath + url = get_url(rpath) + # recover the title of the page if there is one defined, + # if there isn't, fallback on the path to the page + title = pagevar(rpath, "title") + if isnothing(title) + title = "/$rpath/" + end + # write some appropriate HTML + write(c, "...2...") + end + # finish the HTML + write(c, "...3...") + # return the HTML string + return String(take!(c)) +end +``` + +For instance the default uses: + +```html + +

... + +

$title

+``` diff --git a/utils.jl b/utils.jl new file mode 100644 index 0000000..c3fa6b1 --- /dev/null +++ b/utils.jl @@ -0,0 +1,16 @@ +function hfun_bar(vname) + val = Meta.parse(vname[1]) + return round(sqrt(val), digits=2) +end + +function hfun_m1fill(vname) + var = vname[1] + return pagevar("index", var) +end + +function lx_baz(com, _) + # keep this first line + brace_content = Franklin.content(com.braces[1]) # input string + # do whatever you want here + return uppercase(brace_content) +end

Tag: {{fill fd_tag}}